NAT Global to FVRF issues - For Expert

[lap]

Hi Expert,

I have a customer with a DMVPN network. Here is a simple drawing of the setup:

First I attach the config og BRANCH1 router: BRANCH1-Config.txt

What the customer want is simple:

From host 200.200.200.200 reach host 192.168.100.2 on port 3389.

So I have thought to do static nat like that:

ip nat  inside source static tcp 192.168.100.2 3389 100.10.10.2 3389

but it doesn't work becasue BRANCH1 router is configured with FVRF that is to say Outside interface is in a VRF and LAN INSIDE interface is in global. I couldn't see any traffic coming to the server (192.168.100.2)  althought I could see the translation in the nat proccess.

So I have tried to configure NAT virtual interface (NVI) as I read that NVI works better in VRF environment. This time with these lines:

interface FastEthernet0/0
description ***Connection to WAN***
bandwidth 20000
ip vrf forwarding DMVPN-VRF
ip address 100.10.10.2 255.255.255.0
ip access-group OUTSIDEACL in
ip nat enable
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1
description *** Connect to VM3***
ip address 192.168.100.1 255.255.255.0
ip nbar protocol-discovery
ip nat enable
ip virtual-reassembly
load-interval 30
duplex auto
speed auto
no cdp enable

ip nat source static tcp 192.168.100.2 3389 100.10.10.2 3389 extendable

Then I got finally some traffic input in the server 192.168.100.2. See the log from Wireshark:

  200.200.200.200    192.168.100.2    TCP    stgxfws > ms-wbt-server [SYN] Seq=0 Win=64240 Len=0 MSS=1260

  192.168.100.2    200.200.200.200    TCP    ms-wbt-server > stgxfws [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460

So far so good but but.....the router sends an ICMP destination unreachable code 13 to the server:

  10.1.0.1    192.168.100.2    ICMP    Destination unreachable (Communication administratively filtered)

I guess is because the router is doing destination lookup in the global routing table instead of the FVRF.

Does anyone knows how I can solve this problem?

Maybe I could a solution at HUB1 for that so everything is managed central, what do you thing?

Best Regards,

Laurent Prat

[jan.nielsen]

Maybe try the vrf keyword ?

ip nat source static tcp 192.168.100.2 3389 100.10.10.2 3389 vrf DMVPN-VRF extendable

But i doubt it will work like you wan't it to, VRFs are designed to keep routing tables seperate, so this would kinda defeat the purpose of a using VRFs.

Or you could ask Ralph about it :-)

Jan

[lap]

Hi Jan,

Thanks for your post.

I have also tried with the VRF keyword but when I do that there is no traffic input on the server.

Any ideas on how I can solve this problem guys?

Best regards,

Laurent

[Ralph Olsen · Accepted solution]

I can't get the spoke1 config. But first routing needs to be working and I would try route leaking from the VRF into Global.

ip route 200.200.200.200 255.255.255.255 FastEthernet0/0

When that is fixed we can look into NAT.

/Ralph

[lap]

Hi Ralph,

With the static route it is working perfectly.

I attach BRANCH1 config.

Best regards,

Laurent

[lap]

Hi again,

What I don´t understand is that 192.168.100.2 is natted back to 100.10.10.2:

NAT: s=200.200.200.200, d=100.10.10.2->192.168.100.2 [40703] s_vrf=> DMVPN-VRF,  d_vrf=>
NAT*: s=192.168.100.2->100.10.10.2, d=200.200.200.200 [16876] s_vrf=> ,  d_vrf=> DMVPN-VRF
NAT: s=200.200.200.200, d=100.10.10.2->192.168.100.2 [40704] s_vrf=> DMVPN-VRF,  d_vrf=>
NAT*: s=192.168.100.2->100.10.10.2, d=200.200.200.200 [16877] s_vrf=> ,  d_vrf=> DMVPN-VRF

I thought that with NVI the routing will occur first after packets were beeing natted. So in this case 192.168.100.2 packets will be natted to 100.10.10.2 and than routing lookup will occur in the FVRF no?

Regards,

Laurent

[Ralph Olsen]

Well you are in 2 different forwarding tables, so I believe it will go

Route -> Nat -> Route

/Ralph

[lap]

Hi Ralph,

Could you detail deeper what you mean when saying that: Route -> Nat -> Route

Hilsen,

Laurent

[Bastien Migette]

Maybe you can start by checking your outside ACLs. When you get a ICMP administravely prohibited message it is often due to ACL filtering.

You may use the show access-lists to see the counters on your ACL.

If it were a routing problem, the router would send other icmp message code sur as destination unreachable.