Other protocols

Solved
cmr
Kind of a big deal
Kind of a big deal

Other protocols

On a recent install I had to edit the ACL of a Cisco FTD to allow IP protocols 50 and 51 (ESP and AH) for an IPSEC VPN that I needed to pass through it to a VPN concentrator behind.  It got me thinking, with the Meraki MX does it simply pass those protocols through and indeed any protocols other than those on the drop down list from the dashboard shown below:

cmr_0-1729862515486.png

 

 

If my answer solves your problem please click Accept as Solution so others can benefit from it.
1 Accepted Solution
GIdenJoe
Kind of a big deal
Kind of a big deal

Wow that's odd behavior on the FTD.  So it is looking a bit deeper than the first UDP header.

View solution in original post

5 Replies 5
GIdenJoe
Kind of a big deal
Kind of a big deal

If a device is behind the MX it would be NAT'ed which means the IKE negotiation is done with UDP/500 and the ESP would be encapsulated within a UDP/4500.  So you could match this.

However if you would have disabled NAT for this specific then it would send direct ESP behind the IP header and would only match in a rule with Any as protocol.

cmr
Kind of a big deal
Kind of a big deal

@GIdenJoe that's what I thought, but having an ASA behind an FTD with NAT enabled required me to specifically add protocol 50 (ESP) to the ACL...  With the NAT I had allowed all protocols, so that didn't cause the issue.  As the MX has only the options of TCP, UDP or ICMP, I'm guessing that it would just allow other protocols through, but haven't actually tested it.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
GIdenJoe
Kind of a big deal
Kind of a big deal

That's strange because the whole reason the UDP/4500 header is added in front of the ESP header is to get through NAT since NAT on most devices only supports TCP, UDP and ICMP.  The only reason you would get an ESP header right behind an IP header if the two VPN endpoints can reach each other without NAT unless for some reason NAT-T was disabled but then it would not be able to pass through a NAT.

 

So if you had an MX without NAT then you would never be able to match purely on ip protocol 50 or 51 since that is not supported on the MX.  You would have to allow all IP traffic towards that destination.

cmr
Kind of a big deal
Kind of a big deal

Indeed, it was a surprise to me when with the original ACL of UDP500 and UDP4500, the IPSEC VPNs passed through the FTD and were NATed to the ASA where they all came up, but no traffic passed...  Once I added ESP to the ACL all was well in the world.  I double checked that NAT traversal was enabled on the VPNs, even though as they were using port 4500, it was pretty likely, so can only assume that if I'd had an MX instead of an FTD, it would either ignore ESP or you'd have to allow all ports 🤔

If my answer solves your problem please click Accept as Solution so others can benefit from it.
GIdenJoe
Kind of a big deal
Kind of a big deal

Wow that's odd behavior on the FTD.  So it is looking a bit deeper than the first UDP header.

Get notified when there are additional replies to this discussion.