Source NAT for traffic from transport tunnel to service side

[AndyCole]

I'm working on a brownfield deployment, introducing SD-WAN into an existing infrastructure, with new links. Deploying an SD-WAN path alongside the legacy circuits, and moving clients onto the SD-WAN, they will be hitting the same servers in the DC, but over SD-WAN.

Without modifying the legacy network (which client doesn't want to consider) this will create an asymmetric routing situation, and as they have stateful firewalls deployed in part of these paths, dropped sessions.

One solution I'm looking at is to NAT the source addresses from remote users who have been moved onto SD-WAN, so the hosts in the DC can select the return path based on source addresses. This would NAT traffic as it leaves the tunnel, heading to the service side on the DC edge.

But, it seems the transport side NAT options are very limited in XE, certainly via the 20.6.3 GUI, only allowing 1:1 NAT of source host addresses.

vEdge seems to permit a source subnet to be entered (I've seen a CLI example of this), does XE CLI option support such an option? Transport side source NAT seems pretty limited on the XE platform, there isn't much on this in the documentation.

[Kanan Huseynli]

Hi,

as I understand, SD-WAN boxes will be in DC and client side, right? And some user traffic (somehow you will forward to client-side SD-WAN router) should be through overlay and returned via SD-WAN, while other users (not-migrated) should follow legacy path.

I didn't get reason for NAT. DC zone - subnets should be known by SD-WAN and legacy network - you can do it by just advertising them in both "cloud". Regarding, user subnets, advertise migrating users only in SD-WAN. Here, just one point is how to forward specific subnet traffic to SD-WAN only (considering LAN is the same for all user subnets). You can do with VRF-lite or policy-based routing.

Of course, I don't have enough information regarding LAN design, so constraints can be. If you still need NAT through SD-WAN, you can do service-side NAT (why you consider transport in NAT - it is also not understandable, please explain).

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/nat/nat-book-xe-sdwan/configure-nat.html#service-side-nat

[AndyCole]

Hi Kanan,

The issue I'm looking at occurs during the transition phase when we will have a situation where users traffic towards the DC gets moved onto SD-WAN. In the DC there will be a period where the route back to those users (network is too large with multiple stakeholders to simply take a "big bang" approach to changing all routing in one go) will still be via the legacy path. Both traffic paths have stateful firewalls, hence traffic in return direction will be dropped.

A simple solution in this situation is to apply NAT to the inbound (to DC) source addresses of users whose path to DC gets moved from legacy to SD-WAN. Routing is then setup to route back to that new source address. The NAT is only required for the duration away from the legacy network.

But the cEdge code only permits a 1:1 NAT in this direction.

For scale I'd be using NAT pools in traditional IOS/XE routers, or doing this NAT on firewalls, neither option is available to me though.

[Kanan Huseynli]

Hi,

To be honest, I still didn't get the reason, because you can do migration subnet by subnet, if possible give topology with example.

But in any case, cEdge supports service side NAT. It means that, if you have 192.168.10.0/24 on service side can be translated to 172.16.10.0/24 while traffic is sent in overlay (through SD-WAN tunnels). You can use this option which is available and supported. I've already shared the doc. Just read carefully, some configurations are CLI based.