Re: Cisco 1841 NAT Problem

Nicholas Beard · ‎02-21-2011

I have an extremely strange one to one NAT problem on a Cisco 1841 router. I have two statically NAT'd servers which have one to one mappings as follows -

ip nat inside source route-map SDM_RMAP_1 interface FastEthernet0 overload

ip nat inside source static 192.168.42.x 87.x.x.x route-map NONAT_VPN

The route maps specified are then configured as follows -

route-map SDM_RMAP_1 permit 1
match ip address 105

route-map NONAT_VPN permit 10

match ip address 113

The Access List referenced from the route map is then configured as follows -

access-list 113 deny ip host 192.168.42.x 192.168.0.0 0.0.0.255
access-list 113 deny ip host 192.168.42.x 192.168.0.0 0.0.0.255
access-list 113 permit ip host 192.168.42.x any
access-list 113 permit ip host 192.168.42.x any
access-list 113 remark Deny NAT servers through VPN Tunnel

The problem i have is when then route-map command is used at the end of the NAT statement, the static NAT is ignored and the server is NAT'd using the overload NAT statement. If the route-map statement is removed the static NAT works successfully. The problem i have, is that i need the route map statement to prevent the servers from being NAT'd through the VPN tunnel.

Any help would be greatly appreciated.

Latchum Naidu · ‎02-21-2011

Hi,

Remove the reoute-map and keep only one to one static nat statements
And in the SDM_RMAP_1 which you used for overload, add below statements.

access-list 105 deny ip host 192.168.42.x 192.168.0.0 0.0.0.255
access-list 105 permit ip host 192.168.42.x any

Hope this will help you...

Please rate the helpfull posts.

Regards,
Naidu.

Nicholas Beard · ‎02-21-2011

Thanks for the response; yes that does fix the static one to one NAT problem but then causes an extra problem withthe VPN tunnel.

By removing the route-map statement from the static one to one NAT commands the server is NAT'd correctly, but then cannot access any resources through the VPN tunnel because it is being NAT'd.

Access List 105 is currently setup as follows -

access-list 105 deny ip 192.168.42.0 0.0.0.255 192.168.0.0 0.0.0.255
access-list 105 permit ip 192.168.42.0 0.0.0.255 any

For whatever reason, the access list is not taking effect for the statically NAT'd servers?

Latchum Naidu · ‎02-21-2011

Hi,

Specify explicitly permit which networks that 192.168.42.x need to access and what need to deny in the tunnel access-list and check.

Regards,

Naidu.

Nicholas Beard · ‎02-21-2011

crypto map SDM_CMAP_1 2 ipsec-isakmp
description Tunnel to217.x.x.x

set peer 217.x.x.x

set transform-set ESP-3DES-MD5
match address 109

The tunnel access list is 109 which is specified as follows -

access-list 109 permit ip 192.168.42.0 0.0.0.255 192.168.0.0 0.0.0.255

This should be all i need for the VPN Tunnel because i need to permit all traffic through the tunnel. It is the NAT statements which are causing the problem. The overload NAT which references access list 105 works successfully -

access-list 105 deny ip 192.168.42.0 0.0.0.255 192.168.0.0 0.0.0.255
access-list 105 permit ip 192.168.42.0 0.0.0.255 any

However, the static one to one NAT servers are being NAT'd through the tunnel. This can be fixed if i specify a route-map at the end of the NAT statements but that then causes the server one to one NATs to fail and they use the overload statement instead. What i think i need is a route-map statement applied to the one to one NAT statements which work. I am confused as how to do this however, because the route maps i am specifying are causing the one to one NATs to fail.

Nicholas Beard · ‎02-21-2011

Ok i have setup the NAT statements as follows -

ip nat inside source route-map SDM_RMAP_1 interface FastEthernet0 overload
ip nat inside source static 192.168.42.x 87.x.x.x route-map NONAT_VPN
ip nat inside source static 192.168.42.x 87.x.x.x

The route maps are now as follows -

route-map NONAT_VPN permit 1
match ip address 113
!
route-map SDM_RMAP_1 permit 1
match ip address 105

The access lists are now as follows -

access list 105 - Overload NAT access list

access list 109 - VPN Traffic access list

access list 113 - Static NAT route map access list

access-list 105 deny ip 192.168.42.0 0.0.0.255 192.168.0.0 0.0.0.255
access-list 105 permit ip 192.168.42.0 0.0.0.255 any

access-list 113 deny ip host 192.168.42.4 192.168.0.0 0.0.0.255
access-list 113 permit ip host 192.168.42.4 any

access-list 109 permit ip 192.168.42.0 0.0.0.255 192.168.0.0 0.0.0.255

I have performed some troubleshooting on one of the statically NAT'd servers after removing the route-map statement and found that the access list being referenced is 105 and 109 as follows -

deny ip 192.168.42.0 0.0.0.255 192.168.0.0 0.0.0.255 (141 matches)
permit ip 192.168.42.0 0.0.0.255 any (281540 matches)

Each time i attempt an ICMP test from the server through the tunnel, the deny statement increments by one. This shows access list 105 being referenced and denying the traffic along with then 109 being referenced and allowing the traffic -

10 permit ip 192.168.42.0 0.0.0.255 192.168.0.0 0.0.0.255 (14013 matches)

I have then performed some troubleshooting on the other static NAT'd server with the route map still in place and access list 113 is being referenced, as per the route map statement -

10 deny ip host 192.168.42.4 192.168.0.0 0.0.0.255 (40 matches)
20 permit ip host 192.168.42.4 any

However, when the route map statement is in place the server is not being statically NAT'd and is instead being referenced within the overload NAT statement. Confusing!!!

Latchum Naidu · ‎02-21-2011

Hope you have one to one NAT which single Ip to single IP.
If that is correct then deny that IP under the tunnel accesslist like below.

access-list 109 deny ip 192.168.42.50 0.0.0.255 192.168.0.0 0.0.0.255
access-list 109 permit ip 192.168.42.50 any

And now if you PAT like below which can solve the problem...

ip nat inside source static 192.168.42.50 87.82.82.81 route-map NONAT_VPN

route-map NONAT_VPN permit 10
match ip address 113

access-list 113 permit tcp host 192.168.42.50 any eq 443
access-list 113 permit tcp host 192.168.42.50 any eq smtp
access-list 113 deny tcp any any
access-list 113 deny udp any any

Here you onlything need to do is PAT instead of NAT
Hope this will help you..

Regards,
Naidu.

Nicholas Beard · ‎02-21-2011

Ok so to clarify this...

1) The server with the route map statement fails the one to one NAT and instead uses the overload PAT. This means it is being NAT'd to the internet as the wrong IP Address (The Interface IP).

When traffic then attempts to access the VPN remote network it works successfully. Troubleshooting the access lists first shows it hitting access list 105 (Deny) and then 109 (Permit)

2) The server without the route map statement is working successfully with the NAT statement. Traffic to the Internet is NAT'd correctly with the correct inside Global address.

When traffic then attempts to access the VPN remote network it fails. Troubleshooting the access lists show it hitting access list 105 (Deny) and then failing. No further access lists are referenced.

I guess i have two questions -

1) Why does the one to one NAT statement fail when specifying the route map?

2) Why does the server being successfully one to one NAT'd fail when accessing the VPN remote network.

Latchum Naidu · ‎02-21-2011

1) Why does the one to one NAT statement fail when specifying the route map?
In the route map you particularly specified at specific source network should access a specific desti network only.
It means when it is getting NAT it will carry with the route map and trying to access that specific source to destination only.

If you specify any ports to be nated (PAT) then it will not go to any destin and go out with specified ports.

2) Why does the server being successfully one to one NAT'd fail when accessing the VPN remote network.

Most firewalls and NAT routers support the PPTP VPN protocol from behind a NAT. However, some high profile network equipment vendors don't include a NAT editor for the PPTP VPN protocol. If the user is located behind such a device, the VPN connection will fail for PPTP attempts and vice versa but may work for alternate VPN protocols.

Hope I clear you...

Please rate the helpfull posts.

Regards,
Naidu.