Easy VPN Server not working

Unanswered Question
Mar 19th, 2010

We have configured the VPN Server on a router Cisco 2821. After configuring the Cisco VPN Client we can stablish the tunnel (the client receives the correct ip address and there are the secure routes configured properly). But from VPN client we cannot reach any internal ip address and viceversa.

This is the config:

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
crypto isakmp client configuration group XXXXXXXX
key XXXXXXXXXX
pool SDM_POOL_1
acl 101
max-users 6
netmask 255.255.255.0
crypto isakmp profile sdm-ike-profile-1
   match identity group XXXXXXXXX
   client authentication list sdm_vpn_xauth_ml_1
   isakmp authorization list sdm_vpn_group_ml_1
   client configuration address respond
   virtual-template 1

!

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

!
crypto ipsec profile SDM_Profile1
set transform-set ESP-3DES-SHA
set isakmp-profile sdm-ike-profile-1

(...)

interface Virtual-Template1 type tunnel
ip unnumbered ATM0/1/0.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile SDM_Profile1

(...)

ip local pool SDM_POOL_1 172.16.1.1 172.16.1.254

(...)

access-list 101 permit ip 192.168.111.0 0.0.0.255 any
access-list 101 permit ip 10.0.0.0 0.255.255.255 any

Any suggestion? Thanks in advance.

Best regards

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jennifer Halim Fri, 03/19/2010 - 04:28

You might want to check your NAT statement, and make sure that you configure exemption for traffic towards the ip pool.

Eg:

access-list 150 deny ip 192.168.111.0 0.0.0.255 172.16.1.0 0.0.0.255

access-list 150 deny ip 10.0.0.0 0.255.255.255 172.16.1.0 0.0.0.255

access-list 150 permit ip 192.168.111.0 0.0.0.255 any

access-list 150 permit ip 10.0.0.0 0.255.255.255 any

ip nat inside source list 150 interface overload

victorgarciaternero Fri, 03/19/2010 - 04:37

Hello Halijenn, thanks for your quick reply. I had considered the NAT rules as you say in your post. I have reconfigured the ACL 101 to simplify the problem:

access-list 101 permit ip 192.168.111.0 0.0.0.255 any

(...)

ip nat inside source route-map NAT1 interface ATM0/0/0.1 overload
ip nat inside source route-map NAT2 interface ATM0/1/0.1 overload
ip nat inside source route-map NAT3 interface Dialer2 overload

(...)


route-map NAT3 permit 1
match ip address 110
match interface Dialer2
!
route-map NAT2 permit 1
match ip address 110
match interface ATM0/1/0.1
!
route-map NAT1 permit 1
match ip address 110
match interface ATM0/0/0.1
!

(...)

access-list 110 deny   ip 192.168.111.0 0.0.0.255 172.16.1.0 0.0.0.255
access-list 110 permit ip 192.168.111.0 0.0.0.255 any
access-list 110 permit ip 192.168.115.0 0.0.0.255 any
access-list 110 permit ip 192.168.116.0 0.0.0.255 any
access-list 110 permit ip 10.0.5.0 0.0.0.255 any
access-list 110 permit ip 10.0.10.0 0.0.0.255 any

(...)

ip route 0.0.0.0 0.0.0.0 Dialer2
ip route 0.0.0.0 0.0.0.0 xxxxxxx
ip route 0.0.0.0 0.0.0.0 xxxxxxx

We are load balancing traffic between three interfaces with three equal-cost default routes. Traffic to the Internet works perfectly, and I can manage the router using SSH connection to any public ip address.

Best regards.

Jennifer Halim Fri, 03/19/2010 - 04:51

Can you ping the router internal interface?

Which interface did you use to terminate the VPN tunnel? You might want to configure static route for the ip pool (172.16.1./24) to point towards the interface you terminate the VPN on.

victorgarciaternero Fri, 03/19/2010 - 06:16

I cannot ping router internal interface (192.168.111.1). The interface I use to terminate the VPN tunnel is the ATM0/1/0.1. I think it is not neccesary to configure a static route to the VPN, the router automatically forwards the traffic to the virtual interface. Maybe I could set a static ip address to the virtual interfaz, and route all the trafic to the VPN clients to that ip address.

Best regards.

Jennifer Halim Fri, 03/19/2010 - 20:53

Not too sure if that will work, coz as far as the routing is concern, there will be 3 interfaces to load balance and i don't think it provides sticky connection for the crypto tunnel.

victorgarciaternero Sat, 03/20/2010 - 01:10

Really I don't understand why it does not work. We usually apply this configuration and the router routes the traffic to VPN tunnel automatically. In this case the difference is only the load balancing and the policy based routing:

interface GigabitEthernet0/1
description $FW_OUTSIDE$
ip address 192.168.115.1 255.255.255.0 secondary
ip address 192.168.116.1 255.255.255.0 secondary
ip address 10.120.120.1 255.0.0.0 secondary
ip address 10.0.10.1 255.255.255.0 secondary
ip address 192.168.111.1 255.255.255.0
ip verify unicast reverse-path
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1452
ip policy route-map PBR1
duplex auto
speed auto
snmp trap ip verify drop-rate
no mop enabled

(...)

ip local policy route-map PBR2

(...)

ip nat inside source static tcp 192.168.111.3 80 interface ATM0/0/0.1 80
ip nat inside source static tcp 192.168.111.3 53 interface ATM0/0/0.1 53
ip nat inside source static udp 192.168.111.3 53 interface ATM0/0/0.1 53
ip nat inside source static tcp 192.168.111.4 80 interface ATM0/0/0.1 85
ip nat inside source static tcp 192.168.111.3 21 interface ATM0/0/0.1 21
ip nat inside source static tcp 192.168.111.8 80 interface ATM0/0/0.1 88
ip nat inside source static tcp 192.168.111.8 21 interface ATM0/0/0.1 27
ip nat inside source static tcp 192.168.111.5 25 interface ATM0/0/0.1 25
ip nat inside source static tcp 192.168.111.5 110 interface ATM0/0/0.1 110
ip nat inside source static tcp 192.168.111.5 3000 interface ATM0/0/0.1 3000
ip nat inside source static tcp 192.168.111.6 1723 interface ATM0/0/0.1 1723

(...)

access-list 120 deny   ip host 192.168.111.5 172.16.1.0 0.0.0.255
access-list 120 deny   ip host 192.168.111.6 172.16.1.0 0.0.0.255
access-list 120 permit ip host 192.168.111.5 any
access-list 120 permit ip host 192.168.111.6 any
access-list 121 deny   ip host 192.168.111.3 172.16.1.0 0.0.0.255
access-list 121 deny   ip host 192.168.111.4 172.16.1.0 0.0.0.255
access-list 121 deny   ip host 192.168.111.8 172.16.1.0 0.0.0.255
access-list 121 permit ip host 192.168.111.3 any
access-list 121 permit ip host 192.168.111.4 any
access-list 121 permit ip host 192.168.111.8 any
access-list 122 deny   ip 10.0.10.0 0.0.0.255 172.16.1.0 0.0.0.255
access-list 122 permit ip 10.0.10.0 0.0.0.255 any

access-list 130 permit ip host xxxxxxxxxxx any
access-list 131 permit ip host xxxxxxxxxxx any
access-list 132 permit ip host xxxxxxxxxxx any

access-list 140 permit tcp any any eq ftp
access-list 140 permit tcp any any eq ftp-data

(...)

route-map PBR1 permit 1
match ip address 120
set ip precedence critical
set ip next-hop xxxxxxx
set interface ATM0/0/0.1
!
route-map PBR1 permit 2
match ip address 121
set ip precedence critical
set ip next-hop xxxxxxx
set interface ATM0/0/0.1
!
route-map PBR1 permit 3
match ip address 122
set interface Dialer2
!
route-map PBR1 permit 4
match ip address 140
set interface Dialer2
!
route-map PBR2 permit 1
match ip address 130
set ip next-hop xxxxxxxx
set interface ATM0/1/0.1
!
route-map PBR2 permit 2
match ip address 131
set ip next-hop xxxxxxxx
set interface ATM0/0/0.1
!
route-map PBR2 permit 3
match ip address 132
set interface Dialer2

With debug ip packets and debug ip policy I can see this log after the following ping test:

2821#ping
Protocol [ip]:
Target IP address: 172.16.1.22
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.111.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.22, timeout is 2 seconds:
Packet sent with a source address of 192.168.111.1
.....
Success rate is 0 percent (0/5)

The show log output:

294500: *Mar 20 08:07:43.849 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22, len 100, local feature, NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0
294501: *Mar 20 08:07:43.849 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22, len 100, policy rejected -- normal forwarding
294502: *Mar 20 08:07:43.849 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22, len 100, local feature, Policy Routing(3), rtype 0, forus FALSE, sendself FALSE, mtu 0
294503: *Mar 20 08:07:43.849 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22 (Virtual-Access4), len 100, sending
294504: *Mar 20 08:07:43.849 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22 (Virtual-Access4), len 100, output feature, Post-Ingress-NetFlow(52), rtype 1, forus FALSE, sendself FALSE, mtu 0
294505: *Mar 20 08:07:43.849 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22 (Virtual-Access4), len 100, post-encap feature, IPSEC Post-encap output classification(12), rtype 1, forus FALSE, sendself FALSE, mtu 0
294506: *Mar 20 08:07:43.849 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22 (Virtual-Access4), len 100, sending full packet

But I cannot see where the problem is. What do you suggest?

Best regards.

Jennifer Halim Sat, 03/20/2010 - 01:26

From the logs, it's failing policy based routing for source=192.168.111.1, destination=172.16.1.22, because I don't see any of the ACL matching that source and destination traffic.

victorgarciaternero Sat, 03/20/2010 - 01:30

Really what we can see in the log is that traffic not matching any policy of routing, so it will be routed following the normal routing, using the interface Virtual-Access 4 which corresponds with the VPN client. Is it not correct?

Regards.

Jennifer Halim Sat, 03/20/2010 - 01:33

No, because virtual template would be for traffic before it gets encrypted. After it gets encrypted, it will be routing as per your default gateway, which is load balance. Does it work if you configure static route for the pool towards the interface that terminates the vpn tunnel?

victorgarciaternero Sat, 03/20/2010 - 01:39

I have added: ip route 172.16.1.0 255.255.255.0 ATM0/1/0.1, and this is the route table:

S       172.16.1.22/32 [1/0] via , Virtual-Access4
S       172.16.1.0/24 is directly connected, ATM0/1/0.1

And the log is exactly the same:

294755: *Mar 20 08:38:09.709 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22, len 100, local feature, NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0
294756: *Mar 20 08:38:09.709 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22, len 100, policy rejected -- normal forwarding
294757: *Mar 20 08:38:09.709 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22, len 100, local feature, Policy Routing(3), rtype 0, forus FALSE, sendself FALSE, mtu 0
294758: *Mar 20 08:38:09.709 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22 (Virtual-Access4), len 100, sending
294759: *Mar 20 08:38:09.709 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22 (Virtual-Access4), len 100, output feature, Post-Ingress-NetFlow(52), rtype 1, forus FALSE, sendself FALSE, mtu 0
294760: *Mar 20 08:38:09.709 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22 (Virtual-Access4), len 100, post-encap feature, IPSEC Post-encap output classification(12), rtype 1, forus FALSE, sendself FALSE, mtu 0
294761: *Mar 20 08:38:09.709 UTC: IP: s=192.168.111.1 (local), d=172.16.1.22 (Virtual-Access4), len 100, sending full packet

Regards.

Jennifer Halim Sat, 03/20/2010 - 03:35

If you remove "ip policy route-map PBR1" from Gig0/1 and keep the static route for the ip pool, does it work?

victorgarciaternero Sat, 03/20/2010 - 03:42

I cannot remove the PBR1 from Gi0/1 because I need that policy to route specific traffic to a specific interface. I can only test it out of business hours. But if it works, does it mean that Policy Based Routing is not compatible with Easy VPN Server?

Regards.

Actions

This Discussion