ARTICLES

ARE SITE TO SITE VPNS ON A CISCO FIREWALL MORE PERMISSIVE?

ARE SITE TO SITE VPNS ON A CISCO FIREWALL MORE PERMISSIVE?

 

If you set up site to site VPNs a lot, you will notice quirks between vendors.  OpenVPN doesn’t play nice when PFS is enabled.  The infamous Check Point supernetting issue.  Or this last one where Cisco firewalls request a less restrictive proxy-id to function when pairing with a Juniper ScreenOS policy-based VPN.

Cisco Setup
The phase 2 encryption domain of your Cisco firewall is defined in an access-list which is bound to a crypto map.  99.9% of the time, the access-list is setup like this:

access-list Clever-Name-Enc-Domain permit ip <local> <remote>

We do this because 1) we inherently trust the other side 2) we may not know what protocols are coming across and 3) we are humans and we’re lazy.  Cisco actually discourages it with a nastygram to the administrator in the form of this little diddy:

CN-5510-A/pri/act(config)# crypto map test 1 match address test WARNING: access-list has port selectors. This may impact performance.

 

What’s the point?  The error message below

March 25  1 09:36:36 10 : %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0xC1C8D732, sequence number= 0xF) from 1.1.1.1 (user= 1.1.1.1) to 5.5.5.5.  The decapsulated inner packet doesn’t match the negotiated policy in the SA.  The packet specifies its destination as 6.6.6.6, its source as 2.2.2.2, and its protocol as 6.  The SA specifies its local proxy as 6.6.6.0/255.255.255.240/6/20480 and its remote_proxy as 2.2.2.2/255.255.255.255

6.6.6.6 in this example is obviously a part of the local proxy defined network of 6.6.6.0/28. This message is saying that we negotiated a phase 2 security association, the VPN is up, a packet was encrypted and sent across the tunnel, we recognized it as a TCP packet, but after decryption it doesn’t match what we have configured.  The problem is that the local proxy id on the Cisco firewall is NOT defined for protocol 6 (TCP). It is defined for anything (0). In other words, we are allowing everything to come in for the subnet, but the other side is only sending us a TCP connection as a proxy-id.  This should work!

Resolution

The resolution, in this case, was to add another service to the Juniper ScreenOS policy-based VPN so that when the connection was initialized it would send a proxy-id of <local>/0/0.

You can also find an older reference for proxy-id outcomes at a former colleague’s site here. This has mostly been mitigated with the ability to add multiple proxy-ids in 6.3 for route-based VPNs, but it is still good to know for legacy interoperable deployments.

There is also a bug in the logging on the Cisco side that may lead you astray.

 

TAGS:

FILED UNDER: Cisco ASA | Cloud | Juniper ScreenOS

Request a Demo

Fill out the form below and we'll get in touch via email.
We look forward to talking to you!
Thank you! We'll be in touch.
Oops! Something went wrong while submitting the form.
Top ^