Hello.
I have an ISR 1117 running IOS-XE 17.1 that has an IKEv2 tunnel to a hub site. The ISR is connected to 3 internal networks via L2 trunks and the ISR has an SVI for each network. All networks can be summarised to 10.0.0.0/24. The individual networks are 10.0.0.0/26 (VLAN 10), 10.0.0.64/26 (VLAN 11) and 10.0.0.0128/25 (VLAN 12) respectively.
The devices connected to these networks may not have default gateways and if they do, they will be pointing somewhere else other than this ISR, hence one requirement on the ISR is to source NAT traffic ingressing from the tunnel. As a result of this, the tunnel interface (tun0) is "nat inside" and the mentioned SVIs are all "nat outside".
So far, so good. But there is another requirement where the hub site has another tunnel with an overlap. Therefore the hub site has been configured with a route for to "dummy" network 10.1.0.0/24 down the tunnel to this ISR and the requirement is to destination NAT the network on the ISR, so traffic ingressing at tun0 for 10.1.0.0/24 is xlate'd to 10.0.0.0/24 (or the specific networks 10.1.0.N/x to 10.0.0.N/x), then source NAT needs to occur.
But I personally find IOS NAT confusing at the best of times and this has blown my mind. Is it even possible? The source NAT is all good but I can't wrap my head around the destination NAT. Because of order of operations, the ISR needs a route for the "dummy" network but this network doesn't really exist. And this is where I'm stuck.
Unfortunately I can't fix this at the hub site because of the order of operations at that end (a Palo Alto). If I destination NAT there, it does the route lookup on the post-NAT address which then means it's routed down the wrong tunnel due to the network overlap.
Snippet of the ISR config (some parts removed for brevity):
int tun0
! Tunnel to hub site
ip address 100.64.0.2 255.255.255.255
ip nat inside
tunnel source gi0/0/0
tunnel mode ipsec ipv4
int vl10
ip address 10.0.0.62 255.255.255.192
no ip redirects
no ip proxy-arp
ip nat outside
int vl11
ip address 10.0.0.102 255.255.255.192
no ip redirects
no ip proxy-arp
int vl12
ip nat outside
ip address 10.0.0.129 255.255.255.128
no ip redirects
no ip proxy-arp
ip nat outside
!
! Clients at hub site are within 192.168.0.0/24
ip route 192.168.0.0 255.255.255.0 tunnel0
!
! Also need to source NAT when the destination is the "dummy" network.
ip access-list extended NAT_TO_VL10
10 permit ip any 10.0.0.0 0.0.0.63
20 permit ip any 10.1.0.0 0.0.0.63
ip access-list extended NAT_TO_VL11
10 permit ip any 10.0.0.64 0.0.0.63
20 permit ip any 10.1.0.64 0.0.0.63
ip access-list extended NAT_TO_VL12
10 permit ip any 10.0.0.128 0.0.0.127
10 permit ip any 10.1.0.128 0.0.0.127
!
! Source PAT - this is working as expected.
! Remember that not all devices within these VLANs have a default gateway
! and those that do, are not using this ISR as their gateway.
ip nat inside source list NAT_TO_VL10 interface Vlan10 overload
ip nat inside source list NAT_TO_VL11 interface Vlan11 overload
ip nat inside source list NAT_TO_VL12 interface Vlan12 overload
!
! Now the troublesome part, the destination NAT network.
! Need to xlate destination 10.1.0.N/x to 10.0.0.N/x.
! But 10.1.0.A/x doesn't *really* exist here.
! The ISR needs to know it should be answering for 10.1.0.N/x, otherwise it'll send dest unreachable.
! Then xlate destination 10.1.0.N/x to 10.0.0.N/x.
! And then xlate source (see above).
