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. The mechanism is an equivalen

 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 Edge (PE)

 5.0.0.0 came around with a ton of exciting new features I was eager to test IPv6 (Dual Stack) in Underlay and Overlay  Better Gateway throughput Data loss prevention in SASE   However, new Version, new Bugs I first upgraded my company Orchestrator to 5.0.0.0 (after creating a snapshot to be able to roll back to 4.5). This worked quite well, only after going to all parts of the new UI I found out that I could not reach the "General Settings" in the new UI, but the content was perfectly visible in the old UI. Fortunately a 5.0.0.1 upgrade solved that problem. Another strange items, still in version 5.0.0.1 as well, is the fact that in the old and the new UI our Edges now are showing   0 % memory utilization ,  which is either an incredible efficient new code or simply a bug .   Next I tried IPv6 As my Internet provider at home still does not support IPv6, I used the new 5.0 IPv6 features to build IPv6 connectivity using the Dual Stack Overlay and the fact, that our Gateways