Solved: Re: site2site and remote-access-VPN on PIX - no way?

ewald.jenisch · ‎08-16-2004

i,

I've got a problem wrt site2site & remote-access VPNs on a PIX:

My setup is as follows: PIX (6.3) terminates both a site2-site VPN and should also service remote-access clients using the Cisco VPN-client (4.0.x).

The problem is with the VPN-Remote-access clients get an IP-address on their VPN-interface but the clients cannot reach anything. (Please note that the site2site VPN runs without problems)

To be specific (see config-excerpts below):

The client, having 212.138.109.20 as its IP-address gets an IP-address 10.0.100.1 on its VPN-adapter which comes from the "pool vpnpool"

configured on the PIX. This client ties to reach a servers on the "inside" interface of the PIX like 10.0.1.28.

However the client can't reach *anything* - neither a server on the inside nor anything on the outside (i.e. the Internet)!

Using ethereal traces I found out that the packets arrive at the inside interface coming from 10.0.100.1 (the IP-address of the

VPN-client). I also see the reply of the server (10.0.1.28) to 10.0.100.1. However for some reason the packet doesn't make it through

the PIX to the client. The PIX-logs also show packets to/from the VPN-client on the inside interface - and *no* drops. So to my understanding the packets from the server(s) to the VPN-client really should make it through the PIX.

I'm attaching the following as separate files:

o) Relevant parts of the PIX-config

o) PIX-log showing packets between the VPN-client and the server(s) on the inside-interface

o) ethereal-trace done on the inside interface that also shows the packets between the VPN-client and server(s)

I've really scratched my head quite a while over this one, tested a lot of things but I really don't know what could be wrong with my

config.

After all, it really should be possible to run site2site- and remote-access VPNs on the same PIX, shouldn't it?

Thanks alot in advance for your help,

-ewald

mostiguy · ‎08-16-2004

I think your problem is in your ACLs and your crypto map:

access-list 101 permit ip 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0

access-list 101 permit ip 10.0.0.0 255.255.255.0 10.0.2.0 255.255.255.0

access-list 101 permit ip 10.0.3.0 255.255.255.0 10.0.2.0 255.255.255.0

access-list 101 permit ip 10.0.1.0 255.255.255.0 10.0.100.0 255.255.255.0

crypto map loc2rem 1 match address 101

This means this map wants to match those addresses. But your dynamic map is the one that should match traffic from 10.0.1.0 to 10.0.100.0, because your ip local pool is 10.0.100.x. I think what happens is that the return traffic from the lan to the vpn clients is trying to go out the static tunnel, which likely does not exist (for those netblocks - you likely have a Security association for each pair of netblocks, but not one for the vpn clients), and thus fails .

I would recommend adding these lines:

access-list 105 permit ip 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0

access-list 105 permit ip 10.0.0.0 255.255.255.0 10.0.2.0 255.255.255.0

access-list 105 permit ip 10.0.3.0 255.255.255.0 10.0.2.0 255.255.255.0

no crypto map loc2rem 1 match address 101

crypto map loc2rem 1 match address 105

Then reapply :

crypto map loc2rem interface outside

View solution in original post

y-harady · ‎09-01-2004

Hi!!

I just met quite the simular case a couple of weeks ago!! (and I finally resolved it!!)

This case maybe a problem of the ACL.

Now you're using the same ACL (101) for "Site-to-Site crypto map" and "nat command".

This may cause the packet to remote-client transported to the "Site-to-Site VPN".

So I suppose to creat another ACL(102) for "Site-to-Site crypto map" like the following:

access-list 102 permit ip 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0

access-list 102 permit ip 10.0.0.0 255.255.255.0 10.0.2.0 255.255.255.0

access-list 102 permit ip 10.0.3.0 255.255.255.0 10.0.2.0 255.255.255.0

Good Luck!!

Y.Harada