Skip to main content
nathan_emerson
New Member
September 3, 2014
Question

Issues with Fortigate 60D IPSec VPN and packet size

  • September 3, 2014
  • 5 replies
  • 13631 views
We have an issue with IPSec VPN tunnels to new Fortigate 60D units that we do not with the 60C model, same firmware on both and we have tested 5.0.7-9 and 5.2 issue persists in all cases on the 60D. We have a HQ running an 80C HA cluster which accepts Dialup client connections from a number of remotes site Fortigate 60C and now 60Ds. The 60D tunnels are established as normal and look OK, however we experience issues with VNC access to these sites, very slow and timing out access to the Fortigate web interface, and timing out to SSH when running commands with large output. Through flow filters and packet sniffing we have determined that the 60D appears to be dropping packets over a certain size. We can successfully send ICMP packets up to 20996 bytes to the Fortigate itself anything over is received by the 60D but no response is sent. As another test there is a printer onsite, in it' s case any ICMP request over 8192 bytes is received but nothing is sent back. I have attached the flow filter and sniffer logs. Any suggestions on settings that may have changed or are new on the 60D that may cause this? Thanks, Nathan Emerson

    5 replies

    emnoc
    New Member
    September 3, 2014
    Will these are fragments and fragments are very bad. What I would do is to rule out any ASIC offloading, but 1st do you see problems only with VPN traffic or what about traffic locally that' s none VPN bound? To disable vpn offload execute the following under your vpn-cfg. set npu-offload dis Or for a firewall policy; set auto-asic-offload dis Now back to your problem, do you really have packets that big in VNC? FWIW I could not imagine any icmp pings that needs 8K byte big and a lot of unixes will deny you crafting a packet that big. Nor should you be testing with fragments. e.g Request timeout for icmp_seq 0 ping: sendto: Message too long Request timeout for icmp_seq 1 ping: sendto: Message too long Request timeout for icmp_seq 2 ping: sendto: Message too long Request timeout for icmp_seq 3 ping: sendto: Message too long Request timeout for icmp_seq 4 ping: sendto: Message too long Request timeout for icmp_seq 5
    nathan_emerson
    New Member
    September 5, 2014
    Thanks for your response. The remote sites ONLY send traffic via the tunnel under normal circumstances. We will arrange a local traffic test. The dropping of large ICMP packets is the only thing we could find through monitoring flow filter and sniffer traffic to indicate any kind of issue or difference to working sites. As you rightly suspect our normal traffic is usually made up of much smaller packets. When monitoring the problem traffic otherwise it simply arrives at the remote site and no response is generated from the client device.
    emnoc
    New Member
    September 5, 2014
    What i would do; 1: determine the VPN effective MTU A mtu ping or unix has this function 2: I would ensure the DF is being cleared 3: You might want to intercept the tcp-msss and adjust the mss size to be less than effect MTU size ( btw mtu and mss are the not the same, but former effects the latter ) than try and monitor the RDP/VNC or whatever traffic your experiencing problems with.
    ede_pfau
    SuperUser
    SuperUser
    September 5, 2014
    If I see this right you' re using policy mode VPN. Might be worth to quickly set up a route-based VPN instead. I' d have the suspicion that there is an inherent limit in p-m VPN and/or the new hardware in the 60D was not reflected correctly in this part of the FortiOS code. If the latter is probable it may be worth to open a support case to notify the developer team and eventually get a fix.
    MikePruett
    New Member
    September 11, 2014
    Yeah...if you are running a policy based VPN go ahead and can it for the routing based. It will make things a lot easier for ya.