Checkpoint dynamic MTU value over IPSEC tunnel

[custucr]

Hi guys,

Please assist me figuring out the following behaviour related with the MTU setup, used by Checkpoint.

Please find attached the general network diagram consisting of:

2x Checkpoint firewalls with 2 external interfaces, eth0 on the Hub, eth1 on the Remote

- eth0, has MTU 1500, and 10.0.0.1

- eth1 has MTU 1500 and 11.0.0.1

- IPSEC VPN is configured between 2 gateways, tunnel mode, AES-128 and SHA 256

Please also find the following information retrieved from the Central GW:

[Expert@central:0]# ip r get 11.0.0.1
11.0.0.1 via 10.0.0.2 dev bond2 src 10.0.0.1
cache ipid 0x1044 mtu 1500 advmss 1460 hoplimit 64

[Expert@central:0]# ping 11.0.0.1 -s 1410 -c 1
PING 11.0.0.1 (11.0.0.1) 1410(1438) bytes of data.
1418 bytes from 11.0.0.1: icmp_seq=1 ttl=64 time=37.8 ms

--- 11.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

[Expert@central:0]# ping 11.0.0.1 -s 1411 -c 1
PING 11.0.0.1 (11.0.0.1) 1411(1439) bytes of data.
From 11.0.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1438)

--- 11.0.0.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

[Expert@central:0]# ip r get 11.0.0.1
11.0.0.1 via 10.0.0.2 dev bond2 src 10.0.0.1
cache expires 595sec ipid 0x1044 mtu 1438 advmss 1460 hoplimit 64

And now are my questions:

1. why central Checkpoint gw computes a new MTU of 1438 when considering sending packets to the remote gw 11.0.0.1? (There is a dynamic decrease of 62 bytes from the static value, defined on the interface eth0).

2. if those 62 bytes represent the IPSEC header, please help me figure out also what is the breakdown structure of IPSEC overhead used by Checkpoint, considering R80.10 version that is used.

Please consider the model offered by other vendor as an example.

https://cway.cisco.com/ipsec-overhead-calculator/

Regards,

Cristian

[_Val_]

Please read over sk98074 and tell if it helps

[custucr]

Hi Val,

I have read this document, unfortunately that SK does not provide answers to my questions. 

Regards,
Cristian

[Maarten_Sjouw]

You ask questions that do not reflect the reality. The MTU is the Maximum Transmision Unit, this includes all headers except the 18 bytes for the outer header (where the MAC addresses are). The MSS is the Maximum Segment Size, which in fact is the actual data that can pass through a connection. 

The point here is that the 1500 value minus 20 bytes IP header and 20 bytes TCP header, comes down to 1460 bytes MSS, whicxh is what you will see in most SYN and SYN-Ack packets for a new TCP connection.

Now when you set the DF bit, you tell all devices along the way that the packet cannot be split into multiple packets, which will cause a device wich will have to add a header (like the IPSEC header) into the packet and the packet comes with 1460 bytes of data, that new header will not fit in the same packet as that would make the packet 1562 (in your case) bytes in size. This will cause the device to issue a ICMP packet back to the sender with a code 3 (destination unreachable) type 4 (fragmentation needed but DF bit set) message with the header of the original packet in it. This is part of the Path MTU Discovery mechanism, the ICMP packet should cause the sending machine to lower the MSS value and resend the packet with the lower number of bytes.

The best solution for these type of issues is to use MSS clamping, which means that the gateway will, on the fly, adjust the value that the SYN and SYN-Ack packet contain from 1460 (default) to the value you set in the gateway config.

When you want to read more on Path MTU Discovery and MSS clamping look at this article.

[custucr]

HI Maarten,

Thanks for your effort trying to explain and help. I have to say first that I am fully aware about what MTU and MSS is, and also about path MTU discovery and MSS clamping.

1. Please try to notice the output in bold:
   [Expert@central:0]# ip r get 11.0.0.1
   11.0.0.1 via 10.0.0.2 dev bond2 src 10.0.0.1
   cache expires 595sec ipid 0x1044 mtu 1438  advmss 1460 hoplimit 64

My questions probably where not clear:

1. why Checkpoint device decide to use this new MTU 1438, instead of using the default of 1500, considering that the cloud network in the diagram, honours MTU 1500.

2. if IPSEC is the reason, I was curious how Checkpoint did the math, reaching this number. According to the link I have provided in my initial email for IPSEC tunnel-mode with AES128 and SHA256, I get 68bytes instead of 62 bytes.

Kind regards,

[Timothy_Hall]

62 bytes sounds about right for the IPSec/ESP header, and calculating its size should be pretty standard between vendors.  See these examples:

https://community.cisco.com/t5/vpn/ipsec-overhead-in-esp-tunnel-mode/m-p/210468/highlight/true#M2647...

I don't think Check Point is doing anything differently with IPSEC header size vs other vendors, at least for site-to-site VPNs. 

[custucr]

Hi Timothy,

Thanks for your answer. In my case, using the input provided (AES 128, SHA256, tunnel mode) I got 68 bytes.

Regards,