Use case of LAN-Side NAT

Products

• VMware VeloCloud SD-WAN

Issue/Introduction

LAN-Side NAT Rules allow customer to NAT IP addresses in an unadvertised subnet to IP addresses in an advertised subnet. However, we can take advantage of the nature of LAN-side NAT to customize some NAT requirements. Consider below deployment. Spoke is the flow initiator, customer does not want server to see the real IP of client, they want Hub(receiver SD-WAN Edge) to perform the NAT to translate the source IP 10.0.1.25 to Hub's GE4 IP 172.16.3.2. In this case, both 192.168.111.0/24 and 10.0.1.0/24 are advertised to overlay so no routing issue should be considered.

On Spoke we don't need any additional config. On Hub we need to add below LAN-Side NAT config:

172.16.3.2 is the IP adderss of GE4. You can also translate to any IP within the same subnet of GE4. As Hub is flow responder, we need to reverse everything, the type must be "Destination", also we must put client IP 10.0.1.25 into "Outside Address" and expected NATed IP 172.16.3.2 into "Inside Address".

Environment

All supported VMware by Broadcom SD-WAN Edge versions

Resolution

In order to ensure proper functionality, it is imperative to implement the aforementioned rare scenario and configuration. These specific actions are crucial for achieving the desired operational state and ensuring that the system performs as intended in this exceptional scenario.

Additional Information

Test result

Spoke Side:

Capture:

Spoke and client are not aware the IP is NATed.

 

Hub side where LAN-Side NAT is configured:

Flow dump:

LAN-Side NAT dump:

Capture on GE4:

NAT dump: