Esp encapsulation

EDIT: sorry, didn't mean to post twice

Hey guys, wondering if anyone has run into ISPs throttling ESP for site to site vpns? Doing some troubleshooting and have read that forcing udp encapsulation of esp packets can allow them to move through isp networks faster. The idea is that ISPs seeing high bandwidth ESP packets will throttle them down to reduce risk of ddos attacks. No idea if that's true. Also, a question for running bovpns on a firebox - is there a way to force udp encapsulation? From my understanding, nat-t does this, but only if it detects a nat device in its path - other wise, packets remain in esp protocol format.


  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @grahamo

    If an ISP is throttling ESP traffic, they're likely using software that will be able to tell them that you're sending UDP traffic with something in it.

    The only way to invoke NAT Traversal is to traverse NAT -- it's an auotmatic process if the option is enabled.

    You can send traffic via TCP using the BOVPN over TLS feature. However, that tends to see lower throughput numbers than the IPSec variant.

    If the ISP is engaging in throttling your traffic, the most effective way is to call them and look into it with them. They can potentially whitelist communications between two IPs. It's also possible that it's actually a network issue, and contacting them will be the only way to fix it.

    -James Carson
    WatchGuard Customer Support

  • Awesome, thanks @James_Carson. I will call the ISPs and see what's up.

    In this case it's two ISPs, Jaguar and Comcast. Jaguar is fiber 50/50Mbps and Comcast is cable 450/50Mbps. Testing VPN throughput sending from Jaguar to Comcast using iperf3 has been showing at best 7-10Mbps and sometimes much less. The respective external interfaces are under low load overall. I could post some more info on my configurations too, but it's pretty straightforward, managed vpns using ikev1, one /24 subnet tunnel on each side, no SNAT. Packet captures from external interfaces show a lot of lost esp packets, maybe 20% even. Verified said missing esp packets were sent from fiber side and never seen on Comcast side. T-35 on each side running 12.5.4.
  • That much dropped/lost packets is a HUGE issue which does need to be addressed, and will kill thoughput.

  • There are tools such as ping plotter which can show where the dropped/lost packets are likely happening.

    Free trial:

    I have done a pingplotter session to both the far BOVPN endpoint and to some internal IP addr at the other end which would go though the tunnel - to help identify if the issue is an ISP or the BOVPN settings.

    Make sure that the BOVPN settings are not rekeying too often. Normally now, the rekeys are set to just on hours and not also on kilobytes.

  • Ok yes, makes sense. Thanks @Bruce_Briggs - will do
Sign In to comment.