MSS Clamping in 80.10

[Kevin_Werner]

I am looking at clamping the mss value of packets going through my firewalls.  I am running an environment of all 80.10 gateways supported by an 80.10 management server.  

When investigating this situation, this sk clearly lays out the steps for enabling clamping such that it will survive a reboot: Issues requiring adjustment of the Maximum Segment Size (MSS) of TCP SYN and TCP SYN-ACK packets on ... 

I am wondering what I need to do in order to specify the mss value after clamping is enabled.  Older documentation (TCP MSS Adjustment ) suggests supplying a "fw ctl set int fw_tcp_mss_value 1360" argument if i want to set my mss value to 1360.  This sk is from R76 and doesn't specify what needs to be done in order for that to survive a reboot.

Do I want to add a line in the fwkern.conf file saying "fw_tcp_mss_value=1360" and/or are there any global properties I need to change to specify an mss value?

Thanks

[Mark_Mitchell]

Hi Kevin,

I believe that SK61221 is the correct SK, did you also complete the security management server settings using the GuiDBEdit utility? The change needs to be performed on both the gateway and the management server to retain the settings.

Issues requiring adjustment of the Maximum Segment Size (MSS) of TCP SYN and TCP SYN-ACK packets on ... 

Just out of interest, what is the scenario as to why you want to clamp the mss? 

Regards

Mark

[Kevin_Werner]

Thanks Mark - it's an issue we're having with one of our service providers on the edge, they're recommending this change as its fixed the issue we're having in the past.

Any idea on how to specifically set the mss value?  

[Mark_Mitchell]

Not a problem. So the MSS is a value that is derived from the MTU size of an interface. So you could set the MTU of the interface that faces your provider. 

What sort of connection do you have facing your provider? PPPOE?

Regards

Mark

[Kevin_Werner]

Thanks Mark, this is for direct communication with our DDOS provider, we're concerned about the impact it's going to have on our point to point gre tunnels and possible packet fragmentation that could take place.

Our provider is reccomending an MTU adjust of 1400 with an MSS setting of 1360, so I would like to be able to have that mtu size and mss value as being different if at all possible

[Mark_Mitchell]

No worries. Understood. Ok, so the formula that is used by the gateway is based on:

"TCP MSS value = [ MTU value on interface - TCP Header Length ]" 

So setting your MTU to a value of 1400 should set the MSS to 1360 based on a 40 byte TCP header length. 

Example quoted from the SK article. 

"Formula:

TCP MSS value = [ MTU value on interface - TCP Header Length ]

Note: The minimum TCP header size is 20 bytes and maximum is 60 bytes (allowing for up to 40 bytes of options in the header). Generally, TCP Header Length is 40 bytes.

Example for TCP Header Length of 40 bytes:

• Connection is initiated from 10.10.1.0/24 network to 20.20.1.0/24 network:

  [Host 1] (10.10.1.0/24) --- (eth0)[Security Gateway](eth1) --- (20.20.1.0/24) [Host 2]

• Suppose, we need to "clamp" the TCP MSS at 1280 bytes on the outgoing interface eth1.

• Therefore, the MTU on interface eth1 has to be set to:

  [ TCP MSS + TCP Header Length ] = [ 1280 + 40 ] = 1320 bytes.

After enforcing the "clamping" per the above procedure:

• TCPdump on incoming interface eth0 will show:

  13:45:33.002185 10.10.1.3.62912 > 20.20.1.3.23: S 4273442499:4273442499(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp[|tcp]> (DF) [tos 0x10]

• TCPdump on outgoing interface eth1 will show:

  13:45:33.002511 10.10.1.3.62912 > 20.20.1.3.23: S 4273442499:4273442499(0) win 65535 <mss 1280,nop,wscale 1,nop,nop,timestamp[|tcp]> (DF) [tos 0x10]

As you can see, TCP SYN comes in through interface eth0 with an advertised MSS of 1460 (default 1500 bytes - 40 bytes), which is clamped on the interface eth1to 1280 (1320 bytes - 40 bytes)."

Regards

Mark

[Kevin_Werner]

Phenomenal, thanks Mark.  Do I need to get involved in changing the clamping settings or will changing the mtu on the firewall interface take care of that for me?

[Mark_Mitchell]

The clamping setting on the gateway and management server via GuiDbEdit will still need to be completed to ensure that it is enforced and maintained post reboot. 

If you complete the MSS clamping change on the gateway only, then clamping will be enabled until the next policy install, in which case it will then be disabled. Otherwise the clamping will not be performed at all. 

Let us know how you get on.

Regards

Mark

[Danny]

GUIDBEdit fw_clamp_tcp_mss_control -> true

In $FWDIR/boot/modules/fwkern.conf add the following lines:

fw_clamp_vpn_mss=1
fw_clamp_tcp_mss=1‍‍‍‍

and in $FWDIR/modules/simkern.conf add this line at the end:

sim_clamp_vpn_mss=1‍‍

Save, Policy Installation and Reboot. Done.

[Kevin_Werner]

Perfect, thanks Danny.

Is there any way to set what I want the specific mss value of the packets to be?

[Maarten_Sjouw]

Kevin,

MSS is the value of the data that a packet can really transport, the MTU is the gross value of the packet, the IP header of 20 bytes and the PCP header of 20 bytes are just the values when you don't have any reason to change the MSS value. The Default MSS with the above mentioned values is 1360, however as soon as a VPN or any other encapsulation method is used in the communications line it will need to start fragmenting as that IPSEC or GRE header will be added into the packet, a GRE packet is 24 bytes, which will end up in leaving yopu 1400 -20-20-24 = 1336 bytes, which is the actual possible MSS in case of GRE.

What happens when you try to put 1360 bytes inside a GRE packet is that the packet will be fragmented.

The best document about this that i have ever seen can be found here, it also explains PMTUD (Path MTU Discovery)

So the MSS value should be tested and normally you should be able to do a end to end test, there is a small program called TCP-optimizer, which runs on windows and will tell you the right MTU value for that connection, just substract 40 from it to get the MSS.

The MSS value should be set via GuiDBedit, on the interface of the gateway object you will find a MSS value, default=0