cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3388
Views
5
Helpful
15
Replies

Frontdoor VRF NAT IOSXE

bgoulet00
Level 1
Level 1

we have an iWAN infrastructure that uses frontdoor vrf on the internet interface.  the inside client devices can access the internet just fine but at one of our sites we have some internal services that we need to expose to the internet (public web pages, etc).  I have been playing for days trying various methods of route leaking and nat command combinations without any success.  from the research I've done it seems that nat from outside vrf to inside global is not support in IOSXE but i'm really hoping that is not the case.  the one test box I am working on at the moment is internal private IP 192.168.16.38 that I wish to expose to the internet as 209.133.x.y.  192.168.16.38 lives a couple hops downstream of the router.

 

USCYL1-F4-OR-01#show ip route 192.168.16.38
Routing entry for 192.168.16.0/24
Known via "ospf 1", distance 110, metric 21, type extern 1
Redistributing via nhrp, bgp 65100
Advertised by bgp 65100 match internal external 1 & 2 route-map SPOKE-OUT
Last update from 10.224.33.133 on GigabitEthernet0/0/0, 2w4d ago
Routing Descriptor Blocks:
* 10.224.33.133, from 10.224.33.133, 2w4d ago, via GigabitEthernet0/0/0
Route metric is 21, traffic share count is 1

 

vrf definition INET01
!
address-family ipv4
exit-address-family
!

interface GigabitEthernet0/0/1
description internet
bandwidth 500000
vrf forwarding INET01
ip address 209.133.x.b 255.255.255.224
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip access-group wan_hardening in
ip policy route-map INET-INTERNAL
service-policy output TRANSPORT-2-SHAPE-ONLY
hold-queue 4096 in
hold-queue 4096 out
end

!

interface GigabitEthernet0/0/0
ip address 10.224.33.134 255.255.255.252
ip nat inside
ip nbar protocol-discovery
negotiation auto
service-policy input MARKING
!

ip nat inside source static 192.168.16.38 209.133.x.y
ip nat inside source route-map NAT interface GigabitEthernet0/0/1 overload

!

ip route 0.0.0.0 0.0.0.0 209.133.x.a
ip route 209.133.x.a 255.255.255.255 GigabitEthernet0/0/1
ip route vrf INET01 0.0.0.0 0.0.0.0 209.133.x.a

!
route-map INET-INTERNAL permit 10
description Return routing for Local Internet Access
match ip address INTERNAL-NETS
set global
!

route-map NAT permit 10
description Local Internet NAT
match ip address NAT-LOCAL
match interface GigabitEthernet0/0/1
!

ip access-list extended INTERNAL-NETS
permit ip any 10.0.0.0 0.255.255.255
permit ip any 172.16.0.0 0.15.255.255
permit ip any 192.168.0.0 0.0.255.255
!
ip access-list extended NAT-LOCAL
permit ip 10.0.0.0 0.255.255.255 any
permit ip 172.16.0.0 0.15.255.255 any
permit ip 192.168.0.0 0.0.255.255 any

15 Replies 15

oddly, with the deny statement in the access-list the NAT would not work.  can even explain that but since I have it working now i'm not going to fiddle anymore.

 

the route-map I did leave in place since that is supposed to be what allows the return traffic for all of our other internal systems going to the internet.  i'm sure I could do without it if I leaked over all of our internal subnets as you suggested in one of your early posts but doing it this way was the cisco recommended solution.  we also try to maintain configuration standards across all of our sites so if I changed it here i'd have to do 30-something other branches.  

 

ironically, I just finished getting the nat to work using a workaround when your final solution posted but this is much cleaner so I backed that out and am going with this.  thanks again.  i'm posting my final config for reference