Skip to main content
Alby23
New Member
August 24, 2016
Question

Specify MTU for an IPSec Tunnel

  • August 24, 2016
  • 2 replies
  • 103198 views

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...

    2 replies

    BWiebe
    New Member
    August 24, 2016

    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
    Alby23Author
    New Member
    August 24, 2016

    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
    New Member
    September 19, 2016

    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?

    virtualj
    New Member
    September 20, 2016

    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
    New Member
    September 20, 2016

     

     

    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