2611 and VPN client

[cbaird]

Hello,

I am trying to setup a 2611 to provide remote access for a user using Cisco VPN client over the Internet. The PC connects to the VPN and receives an address from the IP local pool. The IP also appears as the default gateway for the VPN adapter.

While connected to VPN, ping and tracert from laptop to 10.0.0.n go nowhere. Also, route print on the laptop does not include the "10.0.0.0 /24 LAN network.

Any help to get this working will be greatly appreciated. Attached is the router config along with some show commands that were run while the VPN client was connected.

Device details:

Router: 2611XM w/ 16F/64D and AIM-VPN/BPII

IOS: 12.3(26) c2600-advsecurityk9-mz.123-26.bin

VPN client is 5.0.03.0560

laptop: XP Pro SP3

[Richard Burts]

Chris

Perhaps we can clarify a couple of things about the situation and that might make it easier to identify the problem:

- what IP address is on the PC before it initiates the VPN?

- you indicate that traffic from the PC to 10.0.0.n fails, and I wonder whether traffic from the PC to any of the addresses in the secondary address work or does that fail also?

- does traffic from the PC to addresses other than network 10 work?

Also I am curious about the configuration of the secondary address on the router interface. Do you really mean to give it a /8 mask:

ip address 10.10.2.1 255.0.0.0 secondary

HTH

Rick

[cbaird]

Rick,

Thanks for your reply. The PC is behind another router elsewhere on the Internet. That said, the PC has a DCHP address from the 192.168.1.0/24. I have not tried to connect to anything (just printers) on the 10.10.2.0/24. I suspect that would fail too since the PC "route print" does not show anything for networks beginning with 10.x.x.x. There is no other networks behind the router that the PC needs to connect with other than 10.0.0.0/24. The secondary 10.10.21 /8 was done intentionally. There are old printers that were setup on that 10.10.2.0 network but with /16 and /8 masks. The customer is not able to change that so I used the /8 for connectivity.

Also, I added the following access-list to the dynamic-map SDM_DYNMAP_1: access-list permit ip 10.0.0.0 0.0.0.255 192.168.250.0 0.0.0.255.

and applied:

crypto dynamic-map SDM_DYNMAP_1 1

match address 199

next I removed and reapplied the crypto map to int fa 0/0 (public)

now it seem that I am no longer able to login through xauth. Below is output from "debug crypto isakmp" "debug crypto isakmp error":

the vpn client attempts to connect and attempts to login but the client display goes from "authenticating user" -> "netgotiating security policies" -> "securing communications channel" -> "not connected".

[cbaird]

I removed acl 199 from the dynamic-map and can connect with the VPN client again.

I confirmed that when connected with the VPN client I am not able to ping the 10.10.2.1 interface.

[Richard Burts]

Chris

I am not sure that I understand what is going on or exactly what the issue is. I have been looking at the config and am wondering about the command reverse-route which is configured in the dynamic map. I wonder why it is there and what it is doing. In my (very limited) experience with it, I associate this command with site to site (or LAN to LAN) VPN and not so much with remote access VPN. What happens if you remove this from the config?

HTH

Rick

[cbaird]

I removed the reverse-route and there is no difference in VPN client connectivity- still cannot see the 10.0.0.0/24 networks. I added that command hoping it would push the 10.0.0.0/24 network to the PC connected with the VPN client.

The fact that the PC does not know how to get to 10.0.0.0/24 is the problem.

Also, from the router public interface I can ping the PC through the VPN:

Dallas#ping

Protocol [ip]:

Target IP address: 192.168.250.11

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

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 192.168.250.11, timeout is 2 seconds:

Packet sent with a source address of

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 24/29/44 ms

However, I am not able to ping from the 10.0.0.0/24 network:

Dallas#ping

Protocol [ip]:

Target IP address: 192.168.250.11

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 10.0.0.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 192.168.250.11, timeout is 2 seconds:

Packet sent with a source address of 10.0.0.1

.....

Success rate is 0 percent (0/5)

The 192.168.250.0 network is not in the routing table on the router.

Traceroute fails from any network on the router to the PC and from the PC to any network on the router.

After removing the "reverse-route" command, I added ACL 197 to the dynamic-map SDM_DYNMAP_1, removed and applied the crypto map SDM_CMAP_1 to the int fa 0/0, and finally retried the VPN client connection - would not connect and fails while "securing communications channel" is displayed on the client.

I repeated the same thing with ACL 198 and ACL 199.

Extended IP access list 197

10 permit ip 192.168.250.0 0.0.0.255 any

Extended IP access list 198

10 permit ip 10.0.0.0 0.0.0.255 any

Extended IP access list 199

10 permit ip 10.0.0.0 0.0.0.255 192.168.250.0 0.0.0.255

***Why is the router not pushing the 10.0.0.0/24 network to the PC?***

[Richard Burts]

Chris

why do you believe that the router needs to push 10.0.0.0/24 to the PC? Since the PC has its default gateway set to send to the VPN peer (the router), and since 10.0.0.0/24 is not in the PC routes, why would the PC not send to the VPN per (the router) to get to 10.0.0.0/24?

There is an aspect of this that I have been thinking about and would like to point out to you. In the file with the outputs that you posted are these:

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 132, #pkts decrypt: 132, #pkts verify 132

The packets deencapsulated of 132 and packets decrypted are traffic from the PC to the router and traffic is obviously flowing that way. The packets encapsulated of 0 and the packets encrypted are traffic from the router to the PC and there is no traffic flowing there. Why is the router not sending traffic to the PC?

HTH

Rick

[Richard Burts]

Chris

Another aspect of this that I am wondering about is this:

router#sh crypto isakmp sa

dst src state conn-id slot

QM_IDLE 3 0

what is

HTH

Rick

[cbaird]

Public IP #7 is the Nat'd IP for the PC.

[cbaird]

I figured it out! I had to add a line in the Internet_IN ACL to allow 192.168.250.0 access to 10.0.0.0. Not thrilled about having 1918 access in from the Internet but does not seem to be much choice. I have been banging away at this for over four weeks now.

Thank you for your ideas and time.

[Richard Burts]

Chris

I am glad that you got it worked out and got it going.

As I think about it, your solution kind of make sense. In 12.3 code I believe that IOS sort of runs VPN data through the interface access list twice, once as it comes in encrypted and again after it has been decrypted. I believe that there was an enhancement somewhere in 12.3T that changes this and only runs data through the access list once. If you were to upgrade your router to something after 12.3(14)T I am not sure that you would need the RFC1918 addresses in the access list.

HTH

Rick

[cbaird]

Thank you Rick - I will look into upgrading the image.

[cbaird]

I can't upgrade because of memory requirements - will make do as is.

Thanks again Rick.