Specify MTU for an IPSec Tunnel

[Alby23]

Is it possible to specify a MTU value for a specific tunnel just you do for an interface?

I don't think so because I think that the MTU settings is specific of a physical interface and not a virtual/ipsec one but just to be sure...

[BWiebe]

Not to my knowledge - at least not for interface-based tunnels.

I believe we could prior to 5.x firmware, but not anymore.

Quick search of the subject seems to confirm that.

You can specify MSS on the tunnel interface, but not MTU.

[Alby23]

I confirm to myself that it is not possible.

From the CLI Reference:

You can set the MTU of a physical interface, a VLAN interface, and some tunnel interfaces (not IPsec). All virtual interfaces inherit the MTU of the parent physical interface. The variable mtu is only available when mtuoverride is enabled.

[virtualj]

I have the same question/problem.

My physical interface for VPN tunnel is 1500, but the other endpoint (also fortigate) is lower. This translate in virtual interface MTU (automatically calculate after VPN tunnel is up) is different between two peers. MTU path discovery doesn't work correctly with a VPN and this can cause a fragmentation issue in the tunnel.

The only "workaround" is to set tcp-mss-sender/receive in the VPN policyies, but this value is difficult to calculate because it depends from Encryption algorithm and MTU of the other side (that is not always known).

Any other ideas?

[ede_pfau]

If your theory is right, just set the MTU to that of the other side, or some multiple of 64 bytes lower. It doesn't have to be the exact maximum transfer unit size, just one equal or below it.

[emnoc]

The only "workaround" is to set tcp-mss-sender/receive in the VPN policyies, but this value is difficult to calculate because it depends from Encryption algorithm and MTU of the other side (that is not always known). Any other ideas?

Actually not correct, the overhead does NOT change  that much  due to  enc-algorithm. The fortigate does a pretty good job  with  calculation of the pMTU t begin, if you wanted or think you need to  set the MTU using the values listd from the dig vpn tunnel list name <tunnel name> | grep mtu

(e.g)

mtu=1446  AES128-256

mtu=1438  3des

It would be better just to set the  value to begin with in the  fwpolicy using  set mss  commands for tcp

 config firewall policy 

     edit 0

       set service "SOME TCP SERVICE" 

        set tcp-mss-sender   14XX    <===compute the MSS based on a 20byte tcp overhead

        set tcp-mss-receiver 14XX  <===compute the MSS based on a 20byte tcp overhead

end

[virtualj]

The situation is not very simple. I have a central VPN concentrator. It does VPNs with several endpoint with different MTU:

1) normal connectivity -> MTU 1500

2) Sat connectivity -> GRE tunnel -> MTU 1476

3) VPN connectivity -> VPN tunnel (from provider) -> MTU 1438

Situation number 1 is all ok. Fortigate reports MTU tunnel of 1446 on both side.

Situation number 2 is asymetric: Central Fortigate reports MTU tunnel of 1446. The SAT side reports MTU 1412.

Situation number 3 is very strange: Central Fortigate have a specific VLAN for these VPNs, and I have specify MTU 1438 on this vlan (the same of the other side). BUT Central fortigate reports MTU tunnel of 1382. The VPN side reports MTU 1374.

So... What can be the better and fast solution? The fortigate should share the MTU information with the other side and choose the minimum.

[emnoc]

The fortigate should share the MTU information with the other side and choose the minimum.

what do you mean by "share MTU", the  vpn  is a layer3 concept  & a MTU is a layer2 ethernet frame nothing to share. MTU sizing is also not bi-symmetrical  to begin with hence why icmppath-discovery was created. keep in mind ICMP packets are not a sure thing and more so with firewall or other devices dropping imp.

What you should do is to run a ping or mtu-ping with the "DF" bit set (1 = don't frag ) and  see the max size packet that's able to be sent. The result is your path-MTU between those 2 end-points.

Keep mind to ignore most report interfaces  MTU size & when  you have a mix of devices  that ever body report slightly different numbers.

e.g

1500 1514 1518 could all mean 1500 bytes with the later showing the  ( 802.1q overhead to confuse matter even more )

GRE always has a minimum of 24bytes overhead  since this is what you have a calculated 1476

NOTE: If you  run GRE over-ipse you even have more overhead.

Ken

[virtualj]

You don't focus the problem. When there is a VPN and GRE path mtu discovery fail. Check this:

server -> FGT Central -> VPN -> GRE -> FGT Remote -> client

Central site: physical interface MTU 1500, VPN virtual MTU 1446

Remote site (SAT): physical interface MTU 1476, VPN virtual MTU 1412

Both side client and server have MTU 1500, so they choose TCP MSS of 1460.

For the packets from server to client FGT central can tell to the server that the maximum packet size is 1446 and not 1500 (PMTUD) and the server adjust the MSS. But when the IPSEC packet traverse the GRE TUNNEL the router should advise FGT Central (source IP of IPSEC packet) that MTU is lower (if DF set) and the router drop the packet (if DF ignore not used), OR the router do fragmentation (if DF not set).

In any case the server will never know that pMTU is lower. The fragmentation case is the more frequent and will cause a very low transfer if you sum this with the very high latency of SAT connection. The other case is pMTUd fail that cause a packet size very very low.

When I say "fortigate should share the MTU information with the other side" this will help and a VPN tunnel for definition is a connection beetween two point without anything in the middle. It is not sese to have differente MTU beetwen the two endpoint because it is a virtual layer 2.

So to came back to the topic question: it will be usefull to manually set the MTU of a virtual VPN interface.

[emnoc]

When I say "fortigate should share the MTU information with the other side" this will help and a VPN tunnel for definition is a connection beetween two point without anything in the middle. It is not sese to have differente MTU beetwen the two endpoint because it is a virtual layer 2.

No layer3 device shares  any MTU ( L2 ) or MSS (L3)  with a far-end, in your case the set tcp mss setting would be the best thing for intercept of  SYN and SYN-ACK packet to reduce the  MSS for tcp-datagrams.

Hard coding a interface  MTU ( route-based interfaces ) could help but  this is not practical for the exact reason that you mention of the DF bit state  "On" or "Off"

Once again, a simple icmp ping with the DF set and raising the packet size will give you an ideal of the  path-mtg between  two-end-points.

Ken