cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1390
Views
0
Helpful
4
Replies

Unable to ping hosts via VPN client when static NAT translations are used

Mark Rigby
Level 1
Level 1

Greetings, i have a 3825 ISR configured for Cisco VPN client access.


There are also several hosts on the internal network that have one-one static NAT translations for externally facing services.


Everything is working as expected with the exception that i cannot ping hosts on the internal network once connected via the VPN client whos internal IP addresses have static NAT translations to outside public addresses, i can ping any host that doesnt have static NAT translation.


For example, in the example below i cant ping 192.168.1.1 and 192.168.1.2 but i can ping the internal interface of the router and any other active host on the LAN, i can ping all hosts from the router itself.


Any help would be appreciated.


Regards

!

crypto logging session

!

crypto isakmp policy 10

encr 3des

authentication pre-share

group 2

!

crypto isakmp client configuration group vpnclient

key S3Cu4Ke!

dns 192.168.1.1 192.168.1.2

domain domain.com

pool dhcppool

acl 198

save-password

pfs

netmask 255.255.255.0

!

!

crypto ipsec transform-set 3DES-SECURE esp-3des esp-sha-hmac

!

crypto dynamic-map dynmap 10

set security-association lifetime seconds 86400

set transform-set 3DES-SECURE

reverse-route

!

crypto map cryptomap client authentication list drauthen

crypto map cryptomap isakmp authorization list drauthor

crypto map cryptomap client configuration address respond

crypto map cryptomap 65535 ipsec-isakmp dynamic dynmap

!

interface GigabitEthernet0/0

ip nat outside

ip address 1.2.3.4 255.255.255.240

crypto map cryptomap

!

interface GigabitEthernet0/1

ip address 192.168.1.254 255.255.255.0

ip nat inside

!

ip local pool dhcppool 192.168.2.50 192.168.2.100

!

access-list 198 remark ****** Split Tunnel Encrypted Traffic ******
access-list 198 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

!
access-list 199 remark *** NAT0 ACL ***
access-list 199 deny   ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
access-list 199 permit ip 192.168.1.0 0.0.0.255 any

!

route-map noNat permit 10
match ip address 199

!
ip nat inside source route-map noNat interface GigabitEthernet0/0 overload

!

ip nat inside source static 192.168.1.1 1.2.3.5
ip nat inside source static 192.168.1.2 1.2.3.6

1 Accepted Solution

Accepted Solutions

Herbert Baerten
Cisco Employee
Cisco Employee

The problem seems to be that static NAT takes precedence over your nat exemption.

The solution would be:

  ip nat inside source static 192.168.1.1 1.2.3.5 route-map nonat
  ip nat inside source static 192.168.1.2 1.2.3.6 route-map nonat

hth

Herbert

View solution in original post

4 Replies 4

Bastien Migette
Cisco Employee
Cisco Employee

Hi,


first of all, I would suggest you not to parse your VPN Key on a public forum (you can edit your post).

Secondly, you make a mistake in your route-map/nat configuration. Here, you will only nat traffic for 192.168.1.0 network.

Your config should look like this:

access-list 199 remark *** NAT DENY ACL ***
access-list 199 permit ip 192.168.1.0 0.0.0.255 any

access-list 200 remark *** NAT PERMIT ACL ***
access-list 200 permit ip 192.168.0.0 0.0.255.255 any

route-map noNat deny 10
match ip address 199

route-map noNat permit 20
match ip address 200

Note that the permit statement in the ACL is used only to "match" the traffic, then it will be denied by the route-map. If you deny in the route map a denied traffic in the ACL, it's like denying unmatched traffic, which will basically allow it.


Regards,

Bastien.

Thank you for your reply, appreciate the comments regarding the PSK and i can assure you this is entirely fictitious.


I have tried adopting the changes you suggested but unfortunately it hasnt solved the problem.


I believe the original split tunnel and NAT0 ACLs are correct and im getting matches on them when connected via the VPN client.


Regards

Herbert Baerten
Cisco Employee
Cisco Employee

The problem seems to be that static NAT takes precedence over your nat exemption.

The solution would be:

  ip nat inside source static 192.168.1.1 1.2.3.5 route-map nonat
  ip nat inside source static 192.168.1.2 1.2.3.6 route-map nonat

hth

Herbert

Makes perfect sense, thank you that has done the trick

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: