04-15-2009 05:14 AM - edited 02-21-2020 04:12 PM
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
Solved! Go to Solution.
04-16-2009 12:52 PM
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,
04-15-2009 06:22 AM
Hi,
Make sure your internal switch has route for VPN client pool.
Regards
04-15-2009 06:25 AM
It does. I still think this is a NAT issue not a routing issue. Thanks for your response.
04-16-2009 12:35 PM
Bump, please help. I'm stuck, and I am sure it is a nat issue that I am missing.
04-16-2009 12:52 PM
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,
04-16-2009 01:00 PM
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.
04-16-2009 01:22 PM
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.
04-16-2009 01:49 PM
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.
04-17-2009 10:22 AM
Its good to know that!
No problem!
regards,
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide