VMware SD WAN - multiple locations - LAN IP address space overlapping with NAT

     Different scenarios are possible in terms of routing, NAT-ing and IP overlapping setups using VMware Velocloud SD WAN technology in Customer environments.

    Recently I had an PoC with my Customer for the on-prem option with this VMware solution, where different use cases were interesting to show and demonstrate - one of them is something I would like to share and it relates to possibility of LAN-side NAT on Edge (branch) locations, with purpose to have IP overlapped on these setups. Next picture is showing typical Hub&Spoke setup where it can be possible to make this type of configuration:

Picture 1. VMware SD WAN lab on-prem environment

    Basically thing which needs to be accomplished is appropriate NAT solution for LANs on every branch Edge which are and needs to be the same ( in this example) - as it is shown on Picture 1.

    Honestly speaking, NAT is not one of so powerful things inside Velocloud SD WAN solution, if you compares it to traditional networking/CLI vendors, as a most often used and necessity setup.

    Hub&Spoke configuration inside Velocloud orchestrator is easily configured using Cloud VPN feature inside profiles - for A/A hub cluster and any specific edge:

Picture 2. Hub Cloud VPN configuration

Picture 3. Spoke (Edge) Cloud VPN configuration

    Per this VMware link https://kb.vmware.com/s/article/78156 this "LAN-Side NAT works at the VMware SD-WAN Edge level, meaning that traffic that is Source or Destination NAT'd with this feature will actually leave the Edge with configured IP changes as opposed to Business Policy NAT which takes effect on the Gateway."
This feature is totally SD WAN segment aware, does not introduce changes in Overlay routing, and in some scenarios may require additional static routing for NAT'd subnets and IPs.
It worths mentioning that different NAT options, like PAT (Port Address Translation) or 1:1 NAT, are supported.
    Regarding the configuration on any specific branch Edge in this scenario, this is required as an example on of them:

Picture 4. Edge LAN side NAT example config

    Let's make couple of explanations in logical manner, because most of them are easily understandable from picture 4:
- LAN side NAT is done per Edge branch location - this example is using PAT and NAT'd IP - only in case that destination is in subnet;
- static route is configured for this specific location and advertised inside Overlay

    Based on this configuration different options are available for multiple scenarios requirements from Customer perspective:
- traffic steering, in routing area, in terms of centralised policy forwarding all data through hub location, or
- forwarding only interesting traffic through overlay and hub reaching internal destinations and rest of Internet traffic directly (like in example above) - ie useful in per client VPN access from any location,
- making different interconnections between branch locations based on connectivity requirements.
Be aware that, even LAN side NAT is happening BEFORE stateful firewall, ORIGINAL source IP is used in the firewall lookup, for making your inspection rules.
    Basically, most of imaginable options for traffic routing are available and NAT can play crucial role for accomplishing them - including LAN side network overlapping, for whatever purpose and connectivity requirement someone have in front of them. And all of that with included security offered with VMware SD WAN solution in place 😉


Popular posts from this blog

NSX ALB (Avi) BGP scaling using ECMP and RHI

NSX ALB routing - multiple floating IP and BGP setup