Crazy about VMware SD-WAN

 Some weeks ago in Linked-In there were a discussion about NAT and IPv6 and one of the engineer meant that as the IPv6 standard does not define NAT and PAT,  using NAT and/or PAT on IPv6 is not a good way of implementation. Now VMware SD-WAN also has full IPv6 support in Underlay and Overlay it uses NAT and specifically SNAT also with IPv6 The implemented IPv6 NAT features are: Default NAT66 on VCG  DIA NAT66 at edge (Many-to-one) 1:1 NAT66 and Port Forwarding Policy NAT66 on Edge and VCG SNAT66 when forwarding to Internet-Underlay And in my opinion this is a valid and sound decision.   But let's look at possible alternative solutions to NAT in IPv6. The standard defines a kind of Souce Routing with the use of the  IPv6 Routing Header   to force traffic via specific intermediate hops.   Unfortunately that method outside a Provider Segment routing environment, where a slightly different Header is used, is a very bad idea from the security point of view....

 When teaching or discussing VMware SD-WAN features, even with some experienced People, when it comes to NAT, PAT and specific Policy NAT , then I often experience that unless needed no one takes care about that feature. So let me explain in this Blog Policy NAT from the SD-WAN aka Customer side. Let's start with the involved components. Partner Gateway A Partner Gateway connects Overlay Customer/Segment Traffic via Handoff Interface to per Customer/Segment separate connectivity using a mechanism known as VRF Lite.  But you can also use that mechanism to Handoff all customer traffic to the same destination However customers often use Private non-unique addresses in their SD-WAN environment.  In that case we need a Source-NAT (SNAT) mechanism to translate the Customer addresses to a unique routable address before reaching the shared destination network. But where is that SNAT address defined? A Service Provider typically will avoid custom specific NATting on its Provider ...

  If an Enterprise uses its own Orchestrator (VCO) the device is often placed inside the internal Datacenter (DC) network and has a private internal Eth0 address configured. Therfore the internet facing Firewall in the main Data Center will have a static 1:1 translation between the public IP address used by SD-WAN Edges and the private IP address used by the VCO. In my lab Edges are reaching the Orchestrator via 110.1.1.254 and the RO-230-IOL-Entry router will translate it to 10.8.1.254 the VCO address on Eth0. In such cases you need a specific additional system property set to make remote diagnostics to work  as you see you also need to set the network.portal.websocket.address Then Remote Diagnostic access from your browser using the internal private address and edges using the public address should work.