ARE SITE TO SITE VPNS ON A CISCO FIREWALL MORE PERMISSIVE?
April 15, 2015 | Filed Under: Cisco ASACloudJuniper ScreenOS
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.
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 184.108.40.206 (user= 220.127.116.11) to 18.104.22.168. The decapsulated inner packet doesn’t match the negotiated policy in the SA. The packet specifies its destination as 22.214.171.124, its source as 126.96.36.199, and its protocol as 6. The SA specifies its local proxy as 188.8.131.52/255.255.255.240/6/20480 and its remote_proxy as 184.108.40.206/255.255.255.255
220.127.116.11 in this example is obviously a part of the local proxy defined network of 18.104.22.168/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!
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.