cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
588
Views
0
Helpful
8
Replies

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

joneschw1
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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,

View solution in original post

8 Replies 8

nomair_83
Level 3
Level 3

Hi,

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

Regards

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

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

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,

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.

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.

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.

Its good to know that!

No problem!

regards,

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: