SRX

Hi All,

We have got 5 remotes offices, 3 are using SRX and 2 are using netscreen. All of the firewalls including HQ (total 6 firewalls) are using default TCP MMS 1500. Pt-to-Pt VPN is formed to HQ at least over a year without any connection issue.

Few days ago, one of the office is found an abnormal behaviour. This remote office couldn't access our servers in HQ. Some of the HQ devices also counldn't access this remote site servers. We confirmed the VPN connection is working fine and able to ping both side devices. Finally, Juniper TAC helped to apply this command 'set security flow tcp-mss all-tcp mss 1350'. Both sides service are resumed normal. We suspect there is some TCP MMS changes in some of the Internet connection to this remote office.

1. Should I apply this command 'set security flow tcp-mss all-tcp mss 1350' to other remote offices?

2. How do I know 1350 is the best mms? 

Thanks,

Kay 

Hello 

The MSS adjustment is to offset the packet size to account for the overhead of the ESP header, which could vary and is approximately 50-60bytes. 

> I would recommend therefore recommend using an MSS value of 1440

> I would recommend to only adjust the tunnel mss without impacting MSS of all pass-through traffic -  

   > delete security tcp-mss

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

> I would say given the traffic pattern, perhaps not many large packets, the other branches have not run into this issue yet

> However it is recommended tcp-mss set for all branches and HQ for ipsec traffic

I hope this answers your query. Regards,

Vikas

JTAC-CFTS

Hi KayNAHC,

The MSS can be seen as the size to a TCP segment without taking in account the TCP header. In other words is the size of the data (payload) that can be contained in the TCP segment and this value is commonly 1460 bytes. See the below link for more information:

   https://crnetpackets.com/2016/01/27/the-relation-between-maximum-transmission-unit-mtu-and-the-maximum-segment-size-mss/

When we use IPsec VPNs an extra overhead/headers are added to cover aspects like encryption, authentication and integrity. So during the process of encapsulation of data the following headers, fixed in size, could be added:

1460bytes of data (MSS)+ TCP header + Inner IP header s+ ESP header + Outter IP header

It could happen that after adding these extra headers (already encrypted packet) the packet is quite big and might need to be fragmented in transit towards the remote IPsec peer. Because fragmentation is usually not desired, we can lower the MSS value so that a packet wont be that big after the adding of the extra headers. Juniper usually suggests a MSS value of 1350 bytes because the overhead added by an IPSec VPN is not a fixed value, this is why many examples show 1350:

    http://rtodto.net/ipsec-tcp-mss-df-bit-and-fragmentation-in-srx/

    https://kb.juniper.net/InfoCenter/index?page=content&id=KB6346&actp=METADATA

As stated I will use the "set security flow tcp-mss ipsec-vpn mss <MSS-value>" instead of the "set security flow tcp-mss all-tcp mss <MSS-value>" becuase the first one only affects VPN traffic. It is important to note that the SRX is only able to modify the MSS value of packets being sent over a tunnel (being encrypted) and not the packets being received over a tunnel (being decrypted). Because of this I will suggest to set the MSS value at the HQ SRX and the remote offices' SRXs:

       https://kb.juniper.net/InfoCenter/index?page=content&id=KB30688&cat=SRX_3600&actp=LIST

Asnwering your questions:

1. Should I apply this command 'set security flow tcp-mss all-tcp mss 1350' to other remote offices?

R/It is a good practice to avoid fragmentation.

2. How do I know 1350 is the best mms? 

R/ It is a suggested value. In order to configure a more accurate MSS value, you will need to determine the lowest MTU of the interfaces along the path. After that you will have to lower the MSS value and calculate the size of the final packet (already encrypted with extra headers) to be lower than the lowest MTU value across the path.

Another option could be taking a packet capture on the external interface of the SRX a look for fragmented ESP packets. You could start lowering the MSS value until no fragmented ESP packets are seen. 

I hope the above information helps you 😉