I have a number of GRE tunnels between an MX480 and some branch SRX devices. Unfortunately I have an MSS problem. The SRX'es typically have a regular connection (typically fiber) to an MPLS network and a GRE-encapsulated backup. They run in packet mode.
Currently the GRE tunnels are transported in a way where the packets get transparently encrypted and fragmented as needed by an external device after passing through the SRX, and decrypted and defragmented again before the MX480 sees them. This provides an effectively 4000-byte MTU between the SRX and the MX480, which means that there are technically no problems just presenting a 1500 byte MTU and pretending it is a regular Internet link.
However, in practice the performance of the link is significantly better if I limit the GRE packets to about 1300 bytes, to keep the packets from fragmenting.
On the MX side I have two ways of achieving this. One is to set tcp-mss on the gre-subinterface to something appropriate, and the other is to simply set the MTU on that same interface, and rely on ICMP packet-too-big.
I cannot seem to find a way to accomplish the same on the SRX. The options seem to be:
Security flow tcp-mss gre-in and gre-out, which only work when the traffic is entering an IPSEC tunnel
Security flow tcp-mss all-tcp which hits traffic going through the main fiber and does not seem to work in packet-mode anyway
Zone-based firewalling, which only works in flow mode
Setting MTU on the GRE subinterface which seems to make the SRX fragment the packets itself and helps in the wrong direction anyway, the MX-side has fixed the MSS in that direction. Fragmenting is a no-go without reassembly, too many fragment blackholes on the Internet (hello Azure).
I would rather avoid messing with the MTU, path-MTU-discovery is just too fragile. Is there any way to adjust the MSS on a packet-mode branch SRX?
Not sure if this helps but my common black magic options are:
set system internet-options gre-path-mtu-discovery
set interfaces gr-0/0/0 unit 0 clear-dont-fragment-bit set interfaces gr-0/0/0 unit 0 tunnel allow-fragmentation
set security flow force-ip-reassembly
At least on SRX300 with 15.1X49-D130.6 its fine then:
# run ping 100.64.255.1 source 100.64.255.2 size 7000 do-not-fragment PING 100.64.255.1 (100.64.255.1): 7000 data bytes 7008 bytes from 100.64.255.1: icmp_seq=0 ttl=64 time=25.415 ms 7008 bytes from 100.64.255.1: icmp_seq=1 ttl=64 time=23.142 ms 7008 bytes from 100.64.255.1: icmp_seq=2 ttl=64 time=23.199 ms 7008 bytes from 100.64.255.1: icmp_seq=3 ttl=64 time=23.296 ms