Global to VRF NAT Problems

[james-worley]

Hi

I am using a 1841 running IOS 'c1841-adventerprisek9-mz.151-3.T1.bin'. I have two ethernet interfaces. One the WAN and the other the LAN. We use an Internet VRF to connect the WAN. Does anyone have any experiance with running NAT from a global interface to a VRF interface?

My config is as follows:

interface FastEthernet0/0

description *** Untrusted Public Network ***

ip vrf forwarding INTERNET

ip address 10.1.2.40 255.255.255.0

ip access-group WAN-IN in

ip access-group WAN-OUT out

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly in

ip verify unicast reverse-path

duplex auto

speed auto

no cdp enable

end

The LAN interface connects to the Global routing instance:

interface FastEthernet0/1

ip address 192.168.35.1 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

ip pim query-interval 10

ip pim sparse-dense-mode

ip nat inside

ip virtual-reassembly in

ip verify unicast reverse-path

ip ospf cost 500

ip ospf 60 area 5

duplex auto

speed auto

end

Routing on each instance looks good:

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 10.1.2.1 permanent name Global_NAT_default_route

ip route vrf INTERNET 0.0.0.0 0.0.0.0 10.1.2.1 permanent name Public_default_route

The problem is when I try to browse the internet and resolve DNS queries. My NAT config looks like this:

ip nat inside source list LAN-NAT interface FastEthernet0/0 overload

!

Extended IP access list LAN-NAT

    10 deny ip any 192.168.0.0 0.0.255.255

    20 deny ip any 172.0.0.0 0.31.255.255

    30 deny ip any 10.0.0.0 0.255.255.255

    40 permit ip 192.168.35.0 0.0.0.255 any (162 matches)

I see nat translatiosn happening:

Pro Inside global         Inside local          Outside local         Outside global

udp 10.1.2.40:35992       192.168.35.21:35992   62.179.104.196:53     62.179.104.196:53

udp 10.1.2.40:40818       192.168.35.21:40818   212.142.28.68:53      212.142.28.68:53

udp 10.1.2.40:50020       192.168.35.21:50020   212.142.28.68:53      212.142.28.68:53

udp 10.1.2.40:50216       192.168.35.21:50216   212.83.68.131:53      212.83.68.131:53

udp 10.1.2.40:53440       192.168.35.21:53440   212.83.68.131:53      212.83.68.131:53

udp 10.1.2.40:54970       192.168.35.21:54970   62.179.104.196:53     62.179.104.196:53

udp 10.1.2.40:57031       192.168.35.21:57031   212.142.28.68:53      212.142.28.68:53

udp 10.1.2.40:54737       192.168.35.23:54737   62.179.104.196:53     62.179.104.196:53

udp 10.1.2.40:54737       192.168.35.23:54737   212.83.68.131:53      212.83.68.131:53

udp 10.1.2.40:54737       192.168.35.23:54737   212.142.28.68:53      212.142.28.68:53

udp 10.1.2.40:63199       192.168.35.23:63199   62.179.104.196:53     62.179.104.196:53

udp 10.1.2.40:63199       192.168.35.23:63199   212.83.68.131:53      212.83.68.131:53

udp 10.1.2.40:63199       192.168.35.23:63199   212.142.28.68:53      212.142.28.68:53

udp 10.1.2.40:63658       192.168.35.23:63658   62.179.104.196:53     62.179.104.196:53

udp 10.1.2.40:63658       192.168.35.23:63658   212.83.68.131:53      212.83.68.131:53

udp 10.1.2.40:63658       192.168.35.23:63658   212.142.28.68:53      212.142.28.68:53

udp 10.1.2.40:64366       192.168.35.23:64366   62.179.104.196:53     62.179.104.196:53

udp 10.1.2.40:64366       192.168.35.23:64366   212.83.68.131:53      212.83.68.131:53

udp 10.1.2.40:64366       192.168.35.23:64366   212.142.28.68:53      212.142.28.68:53

tcp 10.1.2.40:64577       192.168.35.23:64577   17.149.36.107:443     17.149.36.107:443

However my ACL see some funny looking traffic:

553814: *Feb 16 2012 11:14:23.974 CET: %SEC-6-IPACCESSLOGP: list WAN-OUT denied udp 62.179.104.196(53) -> 192.168.35.16(63590), 1 packet 

553815: *Feb 16 2012 11:14:28.258 CET: %SEC-6-IPACCESSLOGP: list WAN-OUT denied udp 62.179.104.196(53) -> 192.168.35.23(53699), 1 packet 

553816: *Feb 16 2012 11:14:37.089 CET: %SEC-6-IPACCESSLOGP: list WAN-OUT denied udp 62.179.104.196(53) -> 192.168.35.21(45487), 1 packet 

For some reason the destination IP is showing as the source and the source inside address as the destination. If I remove NAT I see:

553775: *Feb 16 2012 11:07:29.182 CET: %SEC-6-IPACCESSLOGP: list WAN-OUT denied udp 192.168.35.200(3440) -> 212.142.28.68(53), 1 packet 

553776: *Feb 16 2012 11:07:32.182 CET: %SEC-6-IPACCESSLOGP: list WAN-OUT denied udp 192.168.35.200(3441) -> 62.179.104.196(53), 1 packet 

553777: *Feb 16 2012 11:07:49.700 CET: %SEC-6-IPACCESSLOGP: list WAN-OUT denied udp 192.168.35.21(41043) -> 62.179.104.196(53), 1 packet

Which is inline with what I would expect. I have had a play with the NVI feature but did not find a working config.

[Eugene Khabarov]

Hi! I think there is the problem only with WAN-OUT ACL. You should permit praffic from addresses in the NAT pool maybe?

Moreover you need to allow established connections in your WAN-IN acl.

In other way you need to inplement statefull firewall, f.e. ZBFW.

HTH. Please rate if it was helpful.

[james-worley]

Hi Eugene

I'm pretty confident my ACL is correct. It was working before I moved the WAN interface into a VRF. But for the record my ACL is:

Extended IP access list WAN-OUT

    10 permit udp object-group Dirty-Interface eq isakmp object-group VPN-Hub eq isakmp

    20 permit udp object-group Dirty-Interface object-group VPN-Hub eq non500-isakmp (11300 matches)

    30 permit object-group Allowed-ICMP object-group Dirty-Interface any

    40 permit udp object-group Dirty-Interface eq ntp object-group Public-NTP eq ntp (1 match)

    50 deny ip 192.168.0.0 0.0.255.255 any log (34 matches)

    60 deny ip 172.16.0.0 0.15.255.255 any

    70 deny ip any 192.168.0.0 0.0.255.255 log (2031 matches)

    80 deny ip any 172.16.0.0 0.15.255.255 log

    90 deny ip any 10.0.0.0 0.255.255.255 log

    100 deny tcp any range 135 139 any log

    110 deny udp any range 135 netbios-ss any log

    120 deny tcp any any range 135 139 log

    130 deny udp any any range 135 netbios-ss log

    140 deny tcp any eq 161 any log

    150 deny udp any eq snmp any log

    160 deny tcp any eq 445 any log

    170 deny udp any eq 445 any log

    180 deny tcp any any eq 445 log

    190 deny udp any any eq 445 log

    200 deny udp any any eq syslog log

    210 permit udp object-group Dirty-Interface eq 27593 any

    220 permit tcp object-group Dirty-Interface eq 27593 any

    230 permit ip object-group Dirty-Interface any reflect IPtraffic (16073 matches)

    240 deny ip any any log (8 matches)

I use a lot of network-object (one of the best features of IOS 15 IMO):

object-group network Dirty-Interface

host 10.1.2.40

!

[Eugene Khabarov]

I still belive that it is correct behavior of the ACL and here is blocking rule:

    50 deny ip 192.168.0.0 0.0.255.255 any log (34 matches)

Just for testing you can allow udp port 53 traffic and check for results.

HTH. Please rate if it was helpful.

[james-worley]

No, I don't think it is. NAT should not be using original destination address as the source after NAT.

line 50 is blocks traffic that has not been NAT'd correctly.

[Eugene Khabarov]

Ok, according to the NAT order of operations, NAT will happens before outbound ACL check. I will look forward.

[james-worley]

I have now fixed this issue. I changed NAT to use the NVI interface.