NATing from Internet on the global VRF to an internal VRF

Answered Question
Oct 23rd, 2014
User Badges:

I have a router with an Internet connection in its global vrf, and a VLAN interface in vrf internal. The global vrf is running public addresses, the internal vrf uses RFC1918 addresses

What I want to do is take traffic entering on the Internet connection, apply a NAT to it, then pass it to a server connected via the internal VLAN

 

To achieve the NAT, I proposed setting up the internet connection with "ip nat outside" and the internal vrf interface with "ip nat inside.

Then, to ensure that the NAT-ed packet could get to the server on vrf internal, I wanted to avoid route leaking if I could, and so proposed using a routing statement in the global vrf :

ip route 10.0.0.0 255.0.0.0 10.1.1.1

i.e. to get to network 10/8, go via 10.1.1.1, which is a router, directly connected over the internal VLAN in which vrf internal operates.

 

Is that the right way to do this, or is there a better/simpler/more robust way of doing this.

 

Thanks for any help

 

 

Correct Answer by Jody Lemoine about 2 years 9 months ago

Your static NAT statement is missing the VRF:

 ip nat inside source static 192.168.1.10 10.0.0.2 vrf Core

Just like the previously-discussed route statement, NAT assumes that you're working entirely within the global routing table unless you tell it otherwise.

There may be more to it than this, but give that a shot first.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jody Lemoine Thu, 10/23/2014 - 07:00
User Badges:
  • Gold, 750 points or more
  • Community Spotlight Award,

    Member's Choice, April 2016

Using "ip route 10.0.0.0 255.0.0.0 10.1.1.1" won't do what you need because the router will assume that your next hop is in the global routing table. If you need it to go to the VRF, you need to specify the VRF interface as part of the statement. Something like this:

ip route 10.0.0.0 255.0.0.0 Vlan1 10.1.1.1

Replace Vlan1 with whatever interface hosts your VRF. Similarly, your VRF will need a default route going out. This can be done the same way with:

ip route vrf VRF_LAN 0.0.0.0 0.0.0.0 GigabitEthernet0/0 x.x.x.x

Obviously, the VRF_LAN should be replaced with your internal VRF name, GigabitEthernet0/0 should be replaced with your Internet WAN interface and x.x.x.x should be replaced with your Internet next hop.

If you're getting DHCP/IPCP-assigned addresses from your ISP or are using BGP, then that second part might have to be done a little differently... but that's the basic idea.

Jim Blake Thu, 10/23/2014 - 08:34
User Badges:

Hi Jody,

Thanks for the suggestions, but I've misunderstood somewhere along the line.

I've modelled this in GNS 3, where I have the following:

R3-------------------R1------------------R2

 

R3 has address 192.168.1.2 on F0/1

R1 has 192.168.1.1 on F0/1 in the global VRF (NAT outside) and 10.0.0.1 on F0/0 in VRF Core (NAT inside)

R2 has address10.0.0.2 on F0/0

R2 and 3 have just the bare bones: an interface address

R1 has the following in its config

!
interface FastEthernet0/0
 ip vrf forwarding Core
 ip address 10.0.0.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 192.168.1.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
!
ip forward-protocol nd
ip route 10.0.0.0 255.0.0.0 FastEthernet0/0 10.0.0.1
ip route vrf Core 0.0.0.0 0.0.0.0 FastEthernet0/0 192.168.1.1
no ip http server
no ip http secure-server
!
!
ip nat inside source static 192.168.1.10 10.0.0.2
!
I try pinging from R3 to R2 ("ping 192.168.1.10" which should xlate to 10.0.0.2)  but get nothing back. if I look at Nat trans, I get

R1#show ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- 10.0.0.2           192.168.1.10       ---                ---
R1#
 

can you suggest where I'm getting this wrong?

Thanks for your help so far!

 

Jim

 

 

 

 

 

Correct Answer
Jody Lemoine Thu, 10/23/2014 - 09:50
User Badges:
  • Gold, 750 points or more
  • Community Spotlight Award,

    Member's Choice, April 2016

Your static NAT statement is missing the VRF:

 ip nat inside source static 192.168.1.10 10.0.0.2 vrf Core

Just like the previously-discussed route statement, NAT assumes that you're working entirely within the global routing table unless you tell it otherwise.

There may be more to it than this, but give that a shot first.

Jim Blake Fri, 10/24/2014 - 00:59
User Badges:

Well, that makes a lot of sense, so I spent a couple of hours on it last night and its got me a bit further. If I ping 192.168.1.10 from R3 now, I don't get any reply, but I get some translations occurring:

R1#show ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 192.168.1.10:7    10.0.0.2:7         192.168.1.1:7      192.168.1.1:7
--- 192.168.1.10       10.0.0.2           ---                ---
R1#


so that's a bonus :)

I changed the NAT statement as you suggested, but I also changed the routing statements  to:

ip route 10.0.0.0 255.0.0.0 FastEthernet0/0
ip route vrf Core 192.168.1.0 255.255.255.0 FastEthernet0/1 192.168.1.1
 

so "sho ip ro" gives an output like this:

 

R1#sho ip ro

Gateway of last resort is not set

S    10.0.0.0/8 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1


R1#sho ip ro vrf Core

 

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/0
S    192.168.1.0/24 [1/0] via 192.168.1.1, FastEthernet0/1

 

I've attached the configurations, they are pretty basic, I've been doing this as a Proof of Concept on GNS3.

I'll work on this over the weekend , I have a feeling I'm close, but if you have any further thoughts, I'm listening!

 

Thanks

 

Jim

Attachment: 
Jim Blake Fri, 10/24/2014 - 01:08
User Badges:

Additional Note...the reason I'm seeing NAT translations is because I used the translation statement:

ip nat inside source static 10.0.0.2 192.168.1.10 vrf Core

 

Part of my earlier problems were that I had the addresses round the wrong way....

I think I've got issues with routing back from the target now, but that's a guess. I'll keep working on it :)

Jim Blake Mon, 10/27/2014 - 03:15
User Badges:

I got it working, finally, so I've posted the "sho run" files so others can get the benefit.

Many thanks for your help, I'll mark up your answer as correct as it  sent me down the right road.

 

Cheers

 

Jim

Attachment: 

Actions

This Discussion