Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

PIX 515E needs site to site with 50 sites

I am attempting to connect 50 remote sites to our main office PIX 515E using PIX 501s at the remote sites. I have two sites up and working fine. When I issue the command SHOW CRYPTO ENGINE is see:

Crypto Engine Connection Map:

size = 8, free = 4, used = 4, active = 4

Yikes! 2 connections used 4 entries? And I only have 8 total? The device literature says the 515 supports 2000 VPN tunnels. What gives? The PIX does not support the CRYPTO SDU command to increase these connections. What are we missing? Can we only support 4 remote sites?

New Member

Re: PIX 515E needs site to site with 50 sites

I'm not a big user of pix-based VPN because it's not included in the common criteria target of evaluation (TOE) for Pix, but then neither is failover, NAT, remote management and a few other things. I can, however, throw a little light on the subject of crypto-tunnels and access-lists based on my experience with routers.

The IPSec RFC refers only to contiguous addresses, whereas Cisco access-lists can cover discontiguous addresses. In addition, a Cisco access-list used in crypto may contain multiple permit statements. The upshot of all this is that in many cases, a Cisco device may form multiple tunnels to the same endpoint. (and PPTP/GRE is a good example of this, where there are two tunnels created, one specific to the GRE traffic, and one relating to the source/destination IP addresses in general)

What all this means is that often when crafting your crypto access-list, if you want to limit the number of tunnels created, you may wish to design the access-list to use as few permit statements as possible. So, for example, the following crypto access-list

permit ip host any

permit ip host any

might be better written as

deny ip host any

deny ip host any

permit ip any

because the second access-list will result in only half as many tunnels being created in the normal course of operation.

Sooner or later I expect someone will extend the concept of tags to crypto so that traffic may be tagged with a tunnel equivalency even though it is discontiguous.