Cant ping inside hosts from client vpn. Think its a NAT issue

Answered Question
Apr 15th, 2009

Hello all, I am running into what I think is a NAT/nat exclusion issue with an IOS IPSEC VPN. I can connect to the VPN with the cisco IPSEC VPN client, and I am able to authenticate. Once I authenticate, I am not able to reach any of the inside hosts. My relevant config is below. Any help would be greatly appreciated.

aaa new-model

!

!

aaa authentication login default local

aaa authentication login userauthen group radius

aaa authorization exec default local

aaa authorization network groupauthor local

crypto isakmp policy 3

encr 3des

authentication pre-share

group 2

!

crypto isakmp client configuration group businessVPN

key xxxxxx

dns 192.168.10.2

domain business.local

pool vpnpool

acl 108

crypto isakmp profile VPNclient

match identity group businessVPN

client authentication list userauthen

isakmp authorization list groupauthor

client configuration address respond

!

!

crypto ipsec transform-set myset esp-3des esp-sha-hmac

!

crypto dynamic-map dynmap 10

set transform-set myset

set isakmp-profile VPNclient

reverse-route

!

!

crypto map clientmap 10 ipsec-isakmp dynamic dynmap

interface Loopback0

ip address 10.1.10.2 255.255.255.252

no ip redirects

no ip unreachables

no ip proxy-arp

ip virtual-reassembly

!

interface Null0

no ip unreachables

!

interface FastEthernet0/0

ip address 111.111.111.138 255.255.255.252

ip access-group outside_in in

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip inspect outbound out

ip virtual-reassembly

duplex auto

speed auto

crypto map clientmap

!

interface Integrated-Service-Engine0/0

description cue is initialized with default IMAP group

ip unnumbered Loopback0

no ip redirects

no ip unreachables

no ip proxy-arp

ip virtual-reassembly

service-module ip address 10.1.10.1 255.255.255.252

service-module ip default-gateway 10.1.10.2

interface BVI1

ip address 192.168.10.1 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip nat inside source static tcp 192.168.10.2 25 interface FastEthernet0/0 25

ip nat inside source static tcp 192.168.10.2 443 interface FastEthernet0/0 443

ip nat inside source static tcp 192.168.10.2 3389 interface FastEthernet0/0 3389

ip nat inside source route-map nat interface FastEthernet0/0 overload

ip access-list extended nat

deny ip 192.168.10.0 0.0.0.255 192.168.109.0 0.0.0.255

deny ip 10.1.1.0 0.0.0.255 192.168.109.0 0.0.0.255

permit ip 10.1.1.0 0.0.0.255 any

permit ip 192.168.10.0 0.0.0.255 any

ip access-list extended nonat

permit ip 192.168.10.0 0.0.0.255 192.168.109.0 0.0.0.255

permit ip 10.1.10.0 0.0.0.255 192.168.109.0 0.0.0.255

permit ip 10.1.1.0 0.0.0.255 192.168.109.0 0.0.0.255

ip access-list extended outside_in

permit tcp object-group Yes_SMTP host 111.111.111.138 eq smtp

permit tcp any any eq 443

permit tcp 20.20.20.96 0.0.0.31 host 111.111.111.138 eq 3389

permit tcp 20.20.20.96 0.0.0.31 host 111.111.111.138 eq 22

permit esp any host 111.111.111.138

permit udp any host 111.111.111.138 eq isakmp

permit udp any host 111.111.111.138 eq non500-isakmp

permit ahp any host 111.111.111.138

permit gre any host 111.111.111.138

access-list 108 permit ip 192.168.109.0 0.0.0.255 192.168.10.0 0.0.0.255

access-list 108 permit ip 192.168.109.0 0.0.0.255 10.1.1.0 0.0.0.255

access-list 108 permit ip 192.168.109.0 0.0.0.255 10.1.10.0 0.0.0.255

!

!

!

!

route-map nat permit 10

match ip address nat

bridge 1 route ip

I have this problem too.
0 votes
Correct Answer by Daniela Herrera about 7 years 7 months ago

I believe the acl applied to the client group is backwards. It should permit traffic from the internal network to the clients pool.

To confirm you can open the Cisco VPN client statistics(after connecting) then go to the route details tab. You should see there the networks that you should be able to reach from the client. Make sure the correct ones are in there.

Regards,

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
nomair_83 Wed, 04/15/2009 - 06:22

Hi,

Make sure your internal switch has route for VPN client pool.

Regards

joneschw1 Wed, 04/15/2009 - 06:25

It does. I still think this is a NAT issue not a routing issue. Thanks for your response.

joneschw1 Thu, 04/16/2009 - 12:35

Bump, please help. I'm stuck, and I am sure it is a nat issue that I am missing.

Correct Answer
Daniela Herrera Thu, 04/16/2009 - 12:52

I believe the acl applied to the client group is backwards. It should permit traffic from the internal network to the clients pool.

To confirm you can open the Cisco VPN client statistics(after connecting) then go to the route details tab. You should see there the networks that you should be able to reach from the client. Make sure the correct ones are in there.

Regards,

joneschw1 Thu, 04/16/2009 - 13:00

That got me in, but my split tunneling is no longer working. I can talk to inside hosts from the client, but the client can't hit the internet, etc. I appreciate the help.

Daniela Herrera Thu, 04/16/2009 - 13:22

mmm can you share the changes that were made? that's the split tunnel access-list, that should give you access to the networks specified there and all the other traffic will be sent through the local connection.

joneschw1 Thu, 04/16/2009 - 13:49

I figured it out. Had a typo that I missed in the new access list. Been staring at it too long. You were exactly right. It was that the access-list was reversed. Thanks for your help.

Actions

This Discussion