Why does using multiple sets of specific ip's to specific ip's in a crypto ACL - cause instability in VPN tunnels, please relate this to phase 2 SA's (IPSEC).

Ex. -> -> ->


any ->

OR -> -> ->


any -> any (and using ACL's on interface or VPN-filter to limit traffic across).
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer. – Ron Maupin Jan 6 at 0:19

If you're talking Cisco, each acl record is it's own SA (tunnel). FWIW, the Cisco PIX/ASA will not allow an "any" rule. (which is why an IOS tunnel interface cannot terminate to a PIX/ASA.)

What sort of instability are you seeing? If one rule works, they should all work. Yes, there will be a delay if the SA isn't setup yet. The only issue I can think of would be where IPsec is passing through a NAT device that cannot keep track of multiple streams.

  • This was from a config for AWS from Amazon, it said if you had multi line crypto ACL's that DID NOT include the keyword 'any' it would cause instability. Also I know for a fact you can use 'any' in crypto ACL's, and you can filter w/ VPN filter list.. maybe I misunderstand you? – A L Aug 1 '14 at 19:04
  • I should add that when I questioned some buddies on this, their response was multiple lines builds multiples phase 2 SA's, and that causes problems under heavy load. These are engineers in a major datacenter so I'm inclined to believe them just wanted to more fully understand this claim, and I've had no response from them. – A L Aug 1 '14 at 19:05
  • 1
    Many systems do allow "any" rules, I mentioned the Cisco ASA line as one that won't. You'd have to ask Amazon why their setup is "unstable" with multiple SAs. – Ricky Aug 1 '14 at 19:10
  • 1
    Cisco ASA does allow "any" rules. I have two such tunnels configured and working, Cisco router to ASA. The "any" is in the ASA's direction, essentially forcing all traffic from the router to cross the tunnel. The router side uses the old-style non-interface IPsec tunnel (same as the ASA). – James Sneeringer Aug 1 '14 at 21:14

The "instability" would only exists if both ends of the VPN tunnel are using different values for the subnets on either side (aka, the "Encryption Domain"). Let me explain...

There are three main symptoms of instability you would encounter if the subnets don't match perfectly. I'll start by describing a "fully working" tunnel, then list out the possible scenarios for a misconfigured tunnel where the subnets are not the same.

Fully Working Example

For this example, let's assume two sites are connecting to each other via VPN:

Site A                                         Site B                                          

Both sites have two /24 networks. If SiteA is configured to list out each /24 individually, SiteA would have something like this in its Encryption Domain: --> --> --> -->

Each of these pairs of /24 networks would each receive its own set of IPsec tunnels (one for outgoing traffic, one for incoming traffic), identified by a specific SPI (Security Parameter Index -- fancy term, its just a 8-hex digit label for a set of security algorithms and keys -- also known as a Security Association).

So for example, SiteA might have something labeled like so:

SiteA Pairs                      Outbound SPI    Inbound SPI     -->      0xBBBB1022      0xAAAA1022 -->      0xBBBB1023      0xAAAA1023 -->      0xBBBB1122      0xAAAA1122 -->      0xBBBB1123      0xAAAA1123

If SiteB wanted to be completely correctly configured, must have the exact mirror configuration for its Encryption Domain. So in a perfect world, it would look like this:

SiteB Pairs                      Outbound SPI    Inbound SPI -->      0xAAAA1022      0xBBBB1022 -->      0xAAAA1023      0xBBBB1023 -->      0xAAAA1122      0xBBBB1122 -->      0xAAAA1123      0xBBBB1123

Notice, the SPIs and the networks are perfectly flipped. The Outbound SPI that SiteA uses for to speak to is the Inbound SPI that SiteB uses for to speak to This is by design.

Symptom #1

Now, lets assume SiteB is misconfigured, and decides to use to summarize SiteA. From a purely subneting perspective, that should be perfectly acceptable, right? I mean, two /24's definitely add up to a single /23. However, because of how IPsec negotiates its tunnels, it will cause some issues.

If SiteB initiates by proposing a -->, SiteA will reject the request, because SiteB is trying to create a tunnel for something that is "outside" what SiteA intended to protect (remember, SiteA is still using the four, individually listed out /24 pairs).

If SiteA initiates by proposing a -->, SiteB will accept the request, because is within what SiteB is configured to protect (

(1) So initially, the first set of symptoms will look like the tunnels can only build in one direction (if SiteA initiates).

Symptom #2

If SiteB is configured with the /23, and SiteA initiates... the tunnel will build. And when and try to communicate.... everything will work just fine. BUT, remember, SiteB isn't considering as a /24, it considers it as a /23. So if at some point in the future, SiteB tries to send some traffic to, it will use the pre-existing SPI/tunnel. Which means SiteA will receive something from SiteB with a source of (expected) and a destination of (unexpected). Which in the Cisco world, will cause a syslog message like this to be generated:

%PIX|ASA-4-402116: IPSEC: Received an protocol packet (SPI=spi, sequence 
number= seq_num) from remote_IP (username) to local_IP. The decapsulated inner packet 
doesn't match the negotiated policy in the SA. The packet specifies its destination 
as pkt_daddr, its source as pkt_saddr, and its protocol as pkt_prot. The SA specifies 
its local proxy as id_daddr /id_dmask /id_dprot /id_dport and its remote proxy as 
id_saddr /id_smask /id_sprot /id_sport.

Details Here

(2) The second set of symptoms would look like certain subnets can not communicate through the VPN, and your syslog is full of messages like the above.

Symptom #3

Same scenario as the last time, except this time SiteA decides it wants to send some traffic from to Remember, the already existing SPI from SiteA's perspective is to So this new traffic will require a completely new tunnel. SiteB will receive the request for a new tunnel/SPI and can either reject it, since it considers the original SPI for (although, this is rare). More often, SiteB will accept the request to build a new tunnel from to, which will cause SiteB to tear down the old tunnel. And now you have the same set of symtoms in reverse, speaking to works, but speaking to doesn't.

(3) The third possible set of symptoms here would look like tunnels rebuilding "randomly", and certain subnets keep loosing connectivity to the other side.

NOTE: A lot of the reactions of how the Firewall/Router will work will different depending on the vendor you are using. Most of the examples above are from my years of working with Cisco ASA and PIX products. YMMV, but even still, the concepts are still relevant and apply

So there you have it. What it should look like is a perfect mirror reflection of each other. If you want to summarize the /24's into one /23, that is perfectly fine, as long as BOTH SIDES DO IT THE SAME WAY. If one side decides to do something the other side isn't, you will run into some of the issues described above.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.