WebMux performs the reverse proxy function for Microsoft Lync Server at the external edge where WebMux is always proxying as part of the load balancing operation.
To further explain the reverse proxy role. The 1-Arm Single Network configuration would normally cause the incoming TCP “SYN” packet from a client to go to the WebMux farm/Virtual IP (VIP) address, then to a farm server on the back end.
The server, “seeing” the client IP address would reply directly to the client with the TCP “SYN-ACK” and the client would not process it because it would be a SYN-ACK coming from an address it didn’t send a SYN to directly—BUT part of the WebMux Single Network operation uses SNAT (Source NAT, translating the original source) so the WebMux does a TCP negotiation with the client, replying to the SYN itself, as a SYN-ACK from the farm IP address, and then simultaneously sending a SYN to the back-end/server resource (likely a FE—or another WebMux farm in front of the FE servers) to set up that TCP session. The WebMux acts as a proxy to the back-end, in effect standing in as the client, so it is proxying.
The same is true if you look at the 2-arm NAT mode of operation but the focus is the IP layer instead of TCP. The NAT operation is at the IP layer so the WebMux does not terminate a TCP handshake but passes IP-layer traffic doing the destination IP address translation for each packet. The TLS server “sees” the actual client IP address and replies to that address via the WebMux as its default gateway. The client “thinks” it is talking to the WebMux but the WebMux proxies the destination at the IP layer.
This is the basic explanation of reverse proxy. If you intend to use the WebMux in an Edge-External configuration, as a reverse proxy, then you can simply set up two farms on the external IP address, port 80 (translating to 8080 at the back end) and 443 (translating to 4443). So you set up farms for 80 and 443 and when you add the servers you configure them to be listening on 8080 and 4443, respectively.