PIX 501 VPN/Default Gateway

I'm tearing my hair out here! I've been trying to get a PIX501 IPSec VPN at a remote site up and running for the last few days, and I thought I was just about there. However, I seem to have run into a problem. We have a lot of locations on our network, and I've been specifying them as separate subnets on the PIX (all accessed via the same endpoint, the ISA server at our central site). This works, but I noticed the VPN connections seemed to be dropping for no reason. What I think is happening is that the machines are using up one of the IPSec tunnels for each remote subnet they talk to - it doesn't take long before it reaches the limit (10) and the PIX starts dropping things.

I think all I need to get round this is a way to specify a default gateway for all VPN-bound traffic (which will be everything the PIX receives) at our central site. That way if the PIX doesn't have an explicit entry for a subnet, it can forward it through the VPN to our central router which can take care of it.

Is this possible, or am I in trouble? Thanks in advance.

Colin

Reply to
GlasWolf
Loading thread data ...

:This works, but I noticed the VPN :connections seemed to be dropping for no reason. What I think is :happening is that the machines are using up one of the IPSec tunnels for :each remote subnet they talk to - it doesn't take long before it reaches :the limit (10) and the PIX starts dropping things.

No, the limit of 10 is on the number of peers, not on the number of Security Associations. There is one security association per 'permit' crypto map ACL entry.

:I think all I need to get round this is a way to specify a default :gateway for all VPN-bound traffic (which will be everything the PIX :receives) at our central site. That way if the PIX doesn't have an :explicit entry for a subnet, it can forward it through the VPN to our :central router which can take care of it.

:Is this possible, or am I in trouble? Thanks in advance.

The PIX will only forward traffic if the traffic matches a crypto map ACL entry. The destination in a crypto map ACL entry can be 'any'; if so then you have to be quite careful on the other end.

Note that if a crypto map ACL entry -is- 'any' then unless you take care, you will not be able to contact your outside router itself from your inside LAN -- because 'any' includes the IP address of your outside local equipment.

Reply to
Walter Roberson

Many thanks for your reply, Walter.

OK, I'll discount this. The 10-tunnel limit is stated on a few reseller sites

formatting link
but is absent from the actual Cisco 501 page.

Can you clarify this please? Maybe if I give you a bit more information you'll be able to put it into context.

The remote site is a single private subnet of 5 machines on a switch (DHCP from the PIX). That is going via the PIX and an ADSL line to our central site, where it connects to the public address of our dual-homed ISA server. This has static routes to all our other site subnets. Our WAN provider has added a route for the PIX's subnet (pointing to the ISA server), so everything else on our network can route traffic accordingly.

So even though the crypto map entries aren't the limitation (and therefore the source of the connection dropping problem), it would still be very useful to use an "any" crypto map rule for the sake of a simpler, standardised config, plus future-proofing against addressing changes.

Meanwhile (with my one-crypto-map-per-site config), the PIX still drops frequently drops tunnels, sometimes for a ping or two and sometimes until it's rebooted. The short dropouts tend to be for all connected sites (which is understandable), the longer ones are independant.

Thanks again.

Colin

Reply to
GlasWolf

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.