VPN Client Issue

[TheStressFactor]

Hello All,

I have recently set-up vpn access with my cisco pix.

From my house it works fine. I can access everything no problem. The same for my boss.

I have a user who is at a client site. They use the same subnet as us (192.168.1.x). I have my vpn ip local pool using 10.1.1.0.

The user can connect to the vpn fine but not access any rescources. I cannot ping him either. I can ping any other vpn users when they are connected.

Any ideas what I may be doing wrong?

Patrick

 

[chicocouk]

I think you've already figured out what you're doing wrong - you're both on the same local ip range. One of you will have to change your ip addressing scheme to get this to work.

Probably not what you want to hear, but that's how it is. Sorry.

CCNA, CCSA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[TheStressFactor]

Actually I am not sure what the deal is but I added the nat traversal command and it worked.

 

[chicocouk]

Good stuff. I didn't think that worked (as is probably obvious from my reply )

What version of the pix o/s out of interest? I assume split tunneling is turned off?

CCNA, CCSA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[Gungnir77]

Nat-traversal is needed when they are making a VPN connection from inside a firewall (or router) that is tanslating their address to the outside. Your firewall sees their connection request as coming from their public address, not their inside address. nat-t allows IPSec over UDP allowing for the translated vpn tunnel to get back tot he inside of their firewall. A very common issue actually, I work at Cisco TAC on the security team and see al ot of this. It works for you just fine at home because you are likely connected directly to the internet (presumably broadband) through a public IP

Gungnir77
CCNP, Cisco TAC security team

 

[chicocouk]

NAT-t is a mechanism used to work around the problem of ESP passing a PAT gateway.

NAT-t is required in this situation because ESP doesn't have ports. As such it's not possible to effectively PAT the ESP payload from more than one host behind a gateway that performs PAT. Think about it. If you have two vpn clients behind the same gateway, and they both vpn to the same remote firewall ... how does the gateway know which host to route the return ESP traffic to? There's no ports, so it can't do it statefully. It can't look in the payload, because that's encrypted. So which host does it route it to? (If the gateway's doing static NAT, on the other hand, there's no problem. You can set up as many statics as you want and it will work)

IpSec pass-through works around this (for one internal host) by "remembering" which host initiated the phase 1 from behind the pat device and routing all ESP traffic back to that. If more than 1 host initiates a tunnel the device doesn't know which one to route the ESP traffic back to.

Because there's a device performing PAT between the client and the firewall, the ESP payload is tunnelled under UDP. UDP has ports, which can be noted in the state table, traffic can be routed from endpoint to endpoint reliably, job done.

In this instance I'm surprised that routing between the two networks works at all as they're both on the same range. I can only see that being possible if split tunnelling has been turned off (which is a good idea from a security point of view), otherwise how does the vpn client know what is local traffic, and what is destined for the other side of the vpn?


CCSP, CCNA, CCSA, MCSE, Cisco Firewall specialist, VPN specialist, IDS specialist