cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2479
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

1 Accepted Solution

Accepted Solutions

Hello
I think your missing the following vrf static from your config please add it and test once more as this should then complete the return traffic path:
ip route vrf INET01 209.133.70.130 255.255.255.255 192.168.16.38

ip access-list extended NAT-LOCAL
deny ip host 192.168.16.38 any
< this has to be above the other ace entrys
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

interface GigabitEthernet1
no ip policy route-map INET-INTERNAL




As an alternative you could try port redirection

example:
conf t
no ip nat inside source static 192.168.16.38 209.133.70.130
ip nat inside source static tcp 192.168.16.38 443  interface gig1 443
ip nat inside source static tcp 192.168.16.38 80  interface gig1 80

ip nat inside source static tcp 192.168.16.38 <X>  interface gig1 <X>
ETC.....


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

View solution in original post

15 Replies 15

Cristian Matei
VIP Alumni
VIP Alumni

Hi,

 

     Ideally, you would use VASI NAT (instead of inside/outside), but it requires inter-VRF routing (so no GRT). For your case, you have the following options:

 

         1. I see you're trying to NAT into 209.133.x.y.If this IP does NOT fits into the same subnet as configured on your outside NAT interface (ip address 209.133.x.b 255.255.255.224), look at option 2.

If this IP fits into the same subnet as configured on your outside NAT interface (ip address 209.133.x.b 255.255.255.224), so the IP of 209.133.x.y looks as directly connected, there is a problem with the fact that this interface being in VRF, the router in most cases will not respond to ARP requests for aliases (directly connected IP's for which it responds to ARP requests, due to NAT configuration). Check your next-hop router and see if it has an ARP entry for 209.133.x.y, and if it doesn't manually addd one pointing to the MAC address of the router performing the NAT, however this creates an issue that if you replace the NAT router, you would need to go again to next-hop and reconfigure the ARP mapping; a better solution instead of creating manual ARP entries, would be to configure 209.133.x.y 255.255.255.224 as secondary on your NAT router, this will make it respond to ARP requests for 209.133.x.y. 

 

2.If you have the option of NAT'ing into something public which is not contained in the subnet  configured on your outside NAT interface (like 209.133.x.y or 50.50.50.50), and your Internet next-hop routes for those IP's towards, you, there are no issues with ARP

 

3. There are other options, like router-on-a-stick NAT, by using a dedicated VRF for NAT with a Loopback interface in that VRF. But the above should work.

 

 

Except fixing the ARP problem, configuration looks like:

 

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 (ensure this allows traffic from Internet destined to your NAT'ed IP)
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

!

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

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 209.133.x.a (replaced the above 2 in order to avoid CEF bugs)
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

 

 

Regards,

Cristian Matei.

 

 

 

     

Thanks Christian.

 

the IP i'm trying to use for NAT does fall within the /27 that is configured on the interface itself.  what I have noticed though is that the static NAT command does not create an entry for the IP as locally connected in the route table, either global or vrf.  I believe this is the crux of the issue.  without that entry the router is just ignoring anything destined for that IP.  the next hop router is owned by the ISP so I can't check it or add a manual arp entry.  in the lab I did notice no arp entry in the upstream device.  I considered configuring the secondary ip on the interface as you suggest but ended up not even testing it because it wouldn't solve our problem in production.  in the configuration I presented i'm trying to do this NAT for one test system but once working I have about a dozen others I need to do this for and I wouldn't be able to add a dozen IP address to the internet interface.

 

we don't have any other public address space at this location so option 2 seems to be out.  

 

i'd still love to get this working if possible but there doesn't seem to be a workable solution.  as a workaround I have started planning to connect yet another router to the same internet subnet (we have a layer2 switch between us and the ISP). that device has no vrf configuration, static nat rules configured, and PBR directing only DMZ to internet traffic out its interface.  I did lab this out and it worked perfectly.  

 

completely off-topic, i'm interested in your proposed static route change and reference to a cef bug.  we have an issue that has popped up at a couple of our branch offices that to me has the behavior of being a cef bug but when it is happening the routing and cef tables all look to be correct and clearing cef doesn't fix it.  a reboot does.  TAC has never been able to confirm we are hitting a bug but i'm convince we are.  i'm new on the forum here so I don't know the etiquette. let me know if I should start a new thread and tag you in it or something.  

Hi,

 

     The problem is not with the missing route. When you do a NAT into an IP which is directly attached to the router, the router puts that IP in the alias table and it knows to answer ARP requests for it.

    For how many servers do you need to do static NAT, as in the end you consume one public IP per server (without PAT), so it doesn't matter if those public IP's are secondary IP's on the router interface, or members of a pool.

    The NAT VRF solution would work, but you may end up with some issues on the long run, if other services are deployed for those traffic flows. Let me know if you would want the config.

   As for the cef bug, open another thread, and yes, you could mention me.

 

Regards,

Cristian Matei.

 

I would be interested in looking at the config

it also occurs to me I did not answer your question.  for the site at hand I have 2 internal servers that I need to expose.  I have another site with identical configuration with about 12 servers that I need to do the same for.    

Hello


@bgoulet00 wrote:

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



@bgoulet00 wrote:

what I have noticed though is that the static NAT command does not create an entry for the IP as locally connected in the route table, either global or vrf.  I believe this is the crux of the issue

Given the nat order of preference for domain nat this should work providing that is  you have the routing in place between the vrf and global rib tables, however I dont see any reference to the vrf rib for your internal subnets?

Could you try appending the following and test again?

no ip route 0.0.0.0 0.0.0.0 209.133.x.a <---- specifying interface also negates unwarranted arp
no ip route vrf INET01 0.0.0.0 0.0.0.0 209.133.x.a

route-map NAT permit 10
match ip address NAT-LOCAL
no match interface GigabitEthernet0/0/1 <-- just have reference to the access-list is required here assuming you have just the one egress interface? 

 

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


ip route vrf INET01 192.168.0.0 255.255.0.0 gig0/0/0 10.224.33.x global  <-adds the internal subnets to the vrf rib table
ip route vrf INET01 172.16.0.0 255.255.0.0 gig0/0/0 10.224.33.x global
ip route vrf INET01 10.0.0.0 255.255.255.0 gig0/0/0 10.224.33.x global


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

thanks Paul,

 

I did try those changes and they didn't work.  after adding the route statements I can ping the inside private addresses from the ISP router but ping to the public IP in the nat statement does not work and does not create an entry in the nat translation table.  ping sourced from the inside test device does create an entry in the table but there is not return traffic

Hello

Can you post the current run configuration including the nat translation, global and vrf route tables


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

cleaned up configuration attached.  this is a mockup in the lab so the interface numbers differ from those I previously posted.  I also do not have all of the vrf route commands you added.  I don't want to leak everything internal to the outside.  I did try them as an experiment and it still didn't work so I reverted back to just exposing the internal test system i'm trying to get this to work for

Hello @bgoulet00 

Thank you for sharing --
Can you remove the policy-based routing from the gig1 interface and test again, you shouldnt require this for the returing traffic as nat translation is perfromed before route lookup from natted egress interface and then the static vrf routes should take care of routing from vrf to global rib tables

 

interface GigabitEthernet1
no ip policy route-map INET-INTERNAL


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

that route map is for return traffic from the users at the branch and I believe was part of the cisco validated design for iwan.  as a test I did remove it and incoming nat for the server i'm trying to expose still doesn't work

Hello
I think your missing the following vrf static from your config please add it and test once more as this should then complete the return traffic path:
ip route vrf INET01 209.133.70.130 255.255.255.255 192.168.16.38

ip access-list extended NAT-LOCAL
deny ip host 192.168.16.38 any
< this has to be above the other ace entrys
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

interface GigabitEthernet1
no ip policy route-map INET-INTERNAL




As an alternative you could try port redirection

example:
conf t
no ip nat inside source static 192.168.16.38 209.133.70.130
ip nat inside source static tcp 192.168.16.38 443  interface gig1 443
ip nat inside source static tcp 192.168.16.38 80  interface gig1 80

ip nat inside source static tcp 192.168.16.38 <X>  interface gig1 <X>
ETC.....


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

thanks Paul.  adding ip route vrf INET01 209.133.70.130 255.255.255.255 192.168.16.38 it suddenly started working in the lab environment.  I did not need to make the other changes.  still not working in production but there I still haven't cleaned up the default routes.  i'm going to wait until after business hours to do that and will respond back

Hello

Glad to hear it worked- fyi the other additional changes  i would suggest perform as the current statements are not relevant.

 

ip access-list extended NAT-LOCAL
deny ip host 192.168.16.38 any

interface GigabitEthernet1
no ip policy route-map INET-INTERNAL


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: