Fortigate WAN port issue

Hi,

I don't know if you have proxy mode (for web and AV) enabled, but it's hard to test in this configuration (because the fortigate will buffering the data downloaded, analyze and then pass to the computer). 

Always if you use proxy mode : set thé "HTTP POST Action" to "comfort". it might be help to avoid timeout connection

And if you fix the link speed to 100Mbps full (or 1giga/full), you need to do that of both device (fgt and router)

Lucas

Has tech support (both sides) asked/checked what the MTU value on the WAN Interface is suppose to be?

Thanks for the replies

Both ISP and fortinet tech support didnt care about MTU value.

How do i change the MTU value? What would be the optimal value ?

The issue may still be related to MTU, but as far as link negotiations go, speed and duplex are figured out first.

Where both sides are set to auto and fail to negotiate the right speed, or else both sides are set to the same speed and duplex, seemingly, and still fail to properly negotiate a link, you may want to try testing with a cheap switch in between. Get a Fast Ethernet 4-port switch (or Gigabit, depending on the speed you're testing), and cable the modem and FortiGate into it.

I've sometimes seen cases where the chipsets are not exactly compatible, but where both will successfully negotiate with a switch in the middle.

This didn't happen when we had Watchguard firewall.This started before 2 days when watchguard was replaced with Fortigate.I tried both the ways.Connecting directly between ISP device and fortinet and via netgear switch.The upload speed is still slow.Sometimes download and upload gets stuck and disconnected.I need to disable Web filter and App control features to re download them properly again.Not sure if both these issues are related.

The best way to tell if changing the MTU globally or per-policy would help is to run a verbose sniff on the WAN interface and look for the incidence of fragmented packets. If NPU offloading is enabled for your WAN port, this may not be possible or advisable, depending on how much additional overhead shunting all traffic through the CPU would add to the resource usage on the firewall.

All that being said, here is the syntax for the sniff:

diag sniffer packet wan1 "" 6 0 a

Run it long enough to get a representative sample of the affected traffic, then press Ctl+C to stop the capture. Use PuTTY or a similar terminal emulator application to run the sniff so that you can save the results to a file.

Then, search kb.fortinet.com for 'fgt2eth'. This file, as a Perl script and a self-contained executable, can be used to parse the sniff output into the proper Wireshark format. Within Wireshark, you can visually see whether or not a large percentage of your packets are being fragmented, and adjust your settings accordingly.

To change the MTU globally (or at least, per-interface), the commands are:

config system interface

edit wan1

set mtu-override enable

set mtu x

end

To change the MTU per-policy, the commands are:

config firewall policy

edit x

set tcp-mss-sender x set tcp-mss-receiver x

end

If it doesn't end up helping to change the MTU per-interface or per-policy, I would open a ticket with TAC detailing what you have already tried, and attach the PCAP from the sniff you ran for reference.

Just want to point out changing the  MSS value is NOT changing the MTU. What you should be doing 1st is determining the link MTU between the WAN interface your ISP.

This is revelently simple by using pings with the DF bit enable  and see when you start dropping packets. This would be the "last hop link" MTU size.

e.g ( assuming 1.1.1.1  is  ISP next-hop )

execute ping-options df-bit yes

execute ping-options data-size 1470

and now we ping and increase the  packet size

SOC60D (root) # execute ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 1470 data bytes 1478 bytes from 1.1.1.1: icmp_seq=0 ttl=254 time=1.5 ms 1478 bytes from 1.1.1.1: icmp_seq=1 ttl=254 time=1.7 ms --- 1.1.1.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 1.5/1.6/1.7 ms SOC60D (root) # execute ping-options data-size 1480 SOC60D (root) # execute ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 1480 data bytes --- 1.1.1.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss

Remember that  ICMP uses 8bytes and the ip header is 20bytes for the ethernet standard. Once you know what the true path MTU is, than you can hack around with interface MTU settings or  MSS if required

Hi all,

Thanks for the replies.I wasnt notified about the last two reply.

Tech was able to fix it by bringing a switch between fortigate and ISP device.it was a negotiation issue.

I have an SSL download issue  for which i'm going to start a new topic.

Thanks

Hi, We are having a similar issue. Can you tell me what switch you put in place and did you leave it AUTO or did you force a specific speed at both the FW and Switch?

Shrisundar wrote:

When i set WAN port to auto speed it automatically takes 100mbps half duplex.I had to manually force it to full duplex.This is speed that has been set on ISP side.Issue still remains and i spoke with fortinet tech support.They feel that WAN port should not take half duplex speed when it is set to auto.

For some reason "Auto" ends up as 100Half and I had to set it to 100Full manually