[BBLISA] Odd Latency issues over VPN

[Bob Webber]

On Jan 24, 2014, at 6:02 PM, Nick Cammorato <nick.cammorato at gmail.com> wrote:

> It's 1500 on both sides of the p2p between the SRX and the ASA.  Wouldn't I see fragmentation if it was an MTU problem?  

I had that a little wrong, but if you were setting the don’t fragment bit in your IP header for MTU discovery, you wouldn’t see fragments. But I was wrong anyway: as it turns out, Juniper advises on TCP-MSS value, not MTU.

The document linked slow appears to have some more troubleshooting information, but I called this out in a spirit of crossing every eye and dotting every tee.

<http://kb.juniper.net/library/CUSTOMERSERVICE/technotes/3500176-EN.PDF>

> Configure Tcp-mss to Eliminate Fragmentation of TCP Traffic Across Tunnel

> set security flow tcp-mss ipsec-vpn mss 1350

> Tcp-mss is negotiated as part of the TCP 3-way handshake. It limits the maximum size of a TCP segment to better fit
> the maximum transmission unit (MTU) limits on a network. This is especially important for VPN traffic, as the IPsec
> encapsulation overhead along with the IP and frame overhead can cause the resulting Encapsulating Security Payload
> (ESP) packet to exceed the MTU of the physical interface, thus causing fragmentation. Fragmentation increases
> bandwidth and device resources and is always best avoided. Note that the value of 1350 is a recommended starting
> point for most Ethernet-based networks with an MTU of 1,500 or greater. This value may need to be altered if any
> device in the path has lower MTU, or if there is any added overhead such as Point-to-Point Protocol (PPP), Frame
> Relay, etc. As a general rule, you may need to experiment with different tcp-mss values to obtain optimal performance