Client VPN problems to a 525

[zausner]

I apologize if this is a stupid question however I have run out of ideas to try. I have a customer with a 525 using Cisco VPN software for remote, client vpn's. We're using split tunnel ACL's. There are currently 5 different vpngroups setup for various different companies and employees to access the customer's DMZ and inside networks. The long and short of the problem is that there are three new vpngroups that I added (using the same configs that worked for the other VPN's) that don't work. What happens is that the user fires up the client and authenticates, but then can't access any of the defined services to the specified hosts. When doing various debugs I can see the phase 1 and phase 2 completions and the IPSEC SA is built, correct and active. At first it looked like a translation problem (imagine that on a PIX), but even TAC said all of the translations are in place.

Any advice would be GREATLY appreciated!

 

[themut]

When you try to access the devices behind the PIX are packets being decrypted on the show crypto ipsec sa? How about packets being encrypted from the VPN client statistics?

 

[chicocouk]

The people using these new vpngroup connections, are they trying to connect from behind a NAT device? I've a nagging suspicion that i've seen something similar when trying to vpn in from behind a nat device when the pix didn't have support for NAT-t (it had a 6.2 FOS image)

Post the config?

 

[zausner]

Thanks for the responses!!!

In the debug crypto isa sa the byte counts don't increment, but it shows the SA as active and the correct remote IP.

As for the NAT-T.... that was my first thought as well, however I stuck a laptop on a "raw" internet connection with no NAT devices in front of it..... still no luck.

 

[themut]

If the byte count doesn't increment then it could be a routing problem... How about the statistics from the VPN client? Are packets being ecrypted? Look at the FAQ for safe posting and try to post your configuration.

 

[zausner]

Well I thank everyone for their suggestions, Cisco finally figured it out (5 engineers and 7 days later!). As it turns out the vpnpool address can't be in the same network or subnet as the "inside" network... even though this contradicts the TAC website.... See the Cisco response below:
The VPN clients address pool assignment should not be the same network of the internal network. It is not supported in the PIX or the Cisco Routers.

Acutally it is not documented anywhere on Cisco Web site as far as I know and I even consulted with couple of engineers over here.

I will try to address the issue with one of the documentation leads over here internally and see if there is any way we can implement in the documentaiton or not.

Hope this helps.

Regards,
<NAME OMITTED>

 

[chicocouk]

Ahh, knew i'd seen that behaviour before ...

It is documented on the Cisco website, in at least one place, just not very clearly

Documentation for the ip local pool command:

&quot;The ip local pool command allows you to create a pool of local addresses to be used for assigning dynamic IP addresses to remote VPN clients. The address range of this pool of local addresses must not overlap with any command statement that allows you to specify an IP address.&quot;

In other words, you can't use the same network range used on ANY interface.

There is slightly clearer documentation about it somewhere, but i'm not sure where at the moment ... out of interest, where does the TAC website contradict this?

 

[chicocouk]

And a link to that quote might be useful too, eh?

http://www.cisco.com/en/US/products...eference_chapter09186a00801727a9.html#1027172