TCP mss adjustment Juniper SRX

A few quick tips on the adjustment of systems wide or tunnel MSS values  Junos  11.X  SRX. 

The following  VPN  & GRE tunnels methods, has additional overhead, and extra headers. So the internet defacto standard of a 1500bytes mtu,  will not be available over these tunneling methods. A means most be imposed, to reduce the size of these datagram to fit these tunneling methods.

A quick means to ensure that we can pass datagrams, & with little to no fragmentation, requires us to intercept the tcp MSS value,  and  manipulate the value set in the 3wayhandshake. This approach only helps with the tcp protocol. With  udp protocol or any other protocol, we typically clear the DF-bit and allow the packets travel thru,  and  let any network layer3 device fragment as required.

e.g ( SRX  VPN tunnel )

set security ipsec vpn <VPN Name> df-bit clear

Without the DF-bit cleared, a router  with a smaller than normal mtu,  will drop theses packets if it can’t fragment. This will typically  generate a icmp.type 3/ icmp.code 4 message back to the sender. Theses icmp messages may or may not be received by the sender, due to  any of the following;  the rate-limiting of icmp protocol, control-plane policing, icmp-filters ( aka ACLs), firewalls/IPS or L3 routers setup to ignore or not generate icmp unreachable messages. Btw, a SRX  does  not send  icmp.type 3 icmp.code 4 due to over size packets for vpn tunnels, unless we use the df-copy bit option for the vpn definition.

In this post we will look at 2 methods for doing  a simple tcp-mss-adjustment  on a Juniper SRX. The Juniper MX is similar and I believe the  T/EX/J series offers something of the  same or similar. Btw I have very limited experiences with the M7i or M10i series, but I believe they have the same basic features/functions as  available in Junos and with these models.

1^st let’s look at  the system  internet-options that we can impose;

Take heed of the tcp-mss value of 1436  bytes, this will strike any MSS value greater than 1436 bytes,  and re-configured both the SYN or SYN-ACK packets within the layer4 tcp datagram.  It does not discriminate on either packet type, so any SYN packet will have the MSS value squeezed to the value set.

These  policies can be set at the command line via the following  set cmd

set system internet-options tcp-mss 1436

( the range 64 to 65535 bytes )

Next, these internet-options are applied to the security zone  of your choice. These internet options effected  any tcp-session that passes thru the SRX appliance.

Okay that’s one way to manipulate the tcp-mss, but we have another means available. And it has quite a few  more options.

Using the security policy we can set the mss for system globally and even tunnels. Here’s a screenshot from the jweb interface.

The 2 groups  shows the MSS value inputs that you can use. These allow for adjustment of the  tcp-mss for either system wide or any tunnel interfaces type.

 ( i.e  gr-0/0/0 or st-0/0/0 )

The cmd line options are quite easy to deploy also. You can use the following set cmd for  the adjustment of these values.

set security flow tcp-mss all-tcp mss 1436

set security flow tcp-mss  ipsec-vpn mss-1380

NOTE: Any  settings here over-rides the internet-options settings. It’s also ideal to adjust vpn ipsecs mtu values to ensure that ESP overhead is taking into consideration. Using unix ping with the do don’t fragment option to find the effective vpn-ipsec  tunnel mtu is highly advise able.

Okay now let’s see a before and after adjustment view of packets capture at a host.  The host 10.98.10.10 is sitting behind a  SRX and make a connection to  10.99.10.10  ssh tcp/22 using the Juniper  SRX NAT { 10.99.10.254}.

The 3 above tcp sessions where captures of the SYN/SYN-ACK , as seen via my  external host & within the  untrusted security zone. So my internal host  at  { 10.98.10.10 ( SNAT 10.98.10.254) }  had it’s mss value adjusted to 1400bytes and then I changed it to 1436 bytes. Before the change, my mss value was 1460 bytes ( 20+20 bytes for IP and TCP overhead  - 1500 = 1460 bytes )

As you can see, these   tcp sessions will now negotiate a tcp session of traffic no bigger than the set tcp mss value. We can validate the tcp  traffic flow by analyzing the  tcp-flow and looking at  ip datagram or tcp length  ( wireshark    ip.len or tcp.len )

I hope you found this post  helpful. Next we will look at  mss adjust  with linux/iptables

Ken Felix

Freelance Network/Security Engineer

Kfelix –at – hyperfeed ----dot-----com

       ^      ^

==(  @  @ ) ==

-------------------------