Description
This article describes how to troubleshoot WAN connectivity between the FortiGate and a service provider. It is assumed that the FortiGate has limited or no Internet connectivity, even though the appropriate ISP-provided equipment is configured and connected to the FortiGate.
Scope
FortiGate.
Solution
Note:
Make sure to back up the FortiGate configuration file before proceeding with the steps below. If using a modem, reboot it after making any changes to the FortiGate
.
Check the following to aid in troubleshooting the issue:
- Power: Make sure the FortiGate and provider equipment (CPE) are adequately powered, and that there is link light activity on both devices.
- Link Speed Detection: Determine what link speed the provider's equipment supports (for example, 10/100/1000 Mbps). On the FortiGate, run diag hardware deviceinfo nic wan1 - note that 'wan1' may be another port, depending on the model and configuration. Also, if VDOMs are enabled, enter the global config mode first (run the CLI command config global).
FGT (global) # diagnose hardware deviceinfo nic wan1
Driver Name :Fortinet Nplite Driver
Version :1.0
Admin :up
Current_HWaddr 00:09:0f:09:00:06
Permanent_HWaddr 00:09:0f:1d:8c:e3
Status :up
Speed :1000
Duplex :Full
Host Rx Pkts :3529295
Host Rx Bytes :1122573825
Host Tx Pkts :3222356
Host Tx Bytes :1214502511
Rx Pkts :6860327
Rx Bytes :3244775189
Tx Pkts :5575832
Tx Bytes :1609261750
rx_buffer_len :2048
Hidden :No
In the above output, the negotiation appears to be functioning as normal - the interface negotiated a 1000 Mbps full duplex. The link is also up, so the cabling is fine. If odd values appear, such as 10 Mbps half duplex, try manually setting the link speed on the FortiGate to the highest values supported by the provider's equipment:
FGT (global) # config system interface
FGT (interface) # edit wan1
FGT (wan1) # set speed
1000full 1000M full-duplex
100full 100M full-duplex
100half 100M half-duplex
10full 10M full-duplex
10half 10M half-duplex
auto auto adjust speed
Making any configuration change on an 'outside' or 'WAN' network interface requires a direct connection to the FortiGate or a network local to the FortiGate. This is because the connectivity on a network interface may become unavailable when the interface configuration is changed.
Make sure layer 2 (ARP) is working as expected. If the FortiGate loses its ARP entry for the default gateway
connectivity it will fail.
There must be an ARP entry for the ISP router. Run the commands below to check the ARP table.
get system arp
Or
diagnose network arp list
See here for more ARP commands: Diagnostic ARP command information - Fortinet Community
If there is no ARP entry, run a packet sniffer as follows to see ARP traffic. The below command will capture ARP traffic on wan1.
diagnose sniffer packet wan1 'arp' 4 0 l
If VLAN interfaces on the FortiGate are used for Internet access, ensure the ISP router is configured with matching tagged VLANs. Otherwise, the FortiGate will not be able to create the corresponding ARP entry.
If FortiGate is sending ARP requests but no reply, refer to step 3.
- MAC filtering: If the service was originally used with another device (not the FortiGate), confirm if it still works with that device. If so, ideally try with another, third device. FortiCare #10900032
If the third device also cannot get out, and only the original device can, there is likely MAC filtering applied by the provider. In that case, contact the service provider to have the MAC filter cleared, and provide the FortiGate's WAN network interface MAC address.
Obtain the FortiGate MAC from the diag hardware deviceinfo nic <wan> command above (as seen in the 'Current_HWaddr' field). Alternatively, apply the original device's MAC address to the FortiGate WAN:
FGT # config system interface
FGT (interface) # edit wan1
FGT (wan1) # set mac <old device MAC here>
<xx:xx:xx:xx:xx:xx> please input mac address
FGT # end
Note:
If using a FortiGate HA cluster, the virtual MAC cannot be specified. Contact the ISP.
-
Routing: If using a static IP, make sure there is an appropriate static route added. For example:
Destination IP/Mask: 0.0.0.0/0
Device: wan1
Gateway: ISP gateway IP
Additionally, check the routing table to ensure that the route is present (if VDOM is enabled, enter the management VDOM config mode. The name of the management VDOM is 'root' by default):
get router info routing-table all
If the route is not present, it may be necessary to alter the distances on the routes involved.
If the default route is configured and reflected in the output of the routing table, ping the gateway and public IP. For example, 8.8.8.8.
If the default gateway is pingable, pinging any public IP shows high latency/unreachable. Consider checking the static default route's gateway under Network -> Static Route. (10.9.15.254 is default gateway):
Here, in the above example static default route was misconfigured with the gateway as 0.0.0.0 instead of an actual gateway IP.
If the ping succeeds, IP connectivity is working. If pinging by FQDN fails, check DNS. If pinging by IP fails then run sniffer:
diagnose sniffer packet any "host 8.8.8.8 and icmp" 6 0 l
Check if the destination MAC address is that of the ISP or next hop. If it is there, it means FortiGate is sending packets, and the issue is most likely with the next hop or ISP.
-
Try a directly connected device: To rule out most service-related issues, try connecting a PC to the modem directly and observe the result. If unable to get out, reboot the modem. If still having difficulties, contact the ISP.
Plug the PC into the Modem on the same port where FortiGate is connected and provide the same WAN IP that FortiGate is receiving to see if internet connectivity functions.
-
Isolate the FortiGate: If there is an intermediate switch between the FortiGate and the provider, confirm that it has the correct MAC address of the FortiGate and that the FortiGate also has the switch's MAC:
FGT # get system arp
Ideally, try to test without the switch in the path.
-
HA considerations: When using a FortiGate HA cluster: if a static or dynamic IP address can be used on the FortiGate WAN interface but the packets fail to route egress and ingress fully, try changing the group ID value. This will generate a new virtual MAC address. Another ISP customer may be using the same model of FortiGate in a cluster with the default group ID of 0 - if that's the case, both FortiGates may be using the same virtual MAC address, which results in Layer 2 conflicts.
-
Packet sniffing and traceroute: Ensure the FortiGate unit's WAN interface has ping enabled. Using the built-in packet sniffer, try sniffing on the problematic FortiGate WAN interface:
FGT # diagnose sniffer packet wan1 'icmp'
Meanwhile, try to ping the interface IP from another host on the Internet. If it resolves, great - it is likely connected fine. Try pinging out from the FortiGate back to the other device next:
FGT # execute ping <node ip>
If the ping does not work, check if the other node sees any incoming ICMP packets. If not, ensure the other node is also allowing ping.
Additionally, try a traceroute in both directions: a routing issue may be occurring on the ISP level.
FGT # execute traceroute <node ip>
If the other node's traceroute stops receiving replies before its packets get to the FortiGate gateway device, there may be a routing issue with the provider.
If using public IP on WAN, ping from an external PC to the Gateway of the ISP and ISP IP which is set on the WAN interface to check if receiving any packets while using the sniffer.
If the ping attempt fails, the issue may lie with the ISP.
9. Policy Routing: Is there any policy routing that was recently applied? If so, remove the policy routing until back to using basic static routing. Test from the FortiGate command line for connectivity:
execute ping 4.2.2.2
(Any reliable IP address on the Internet can be used.)
- Firewall Policies: If testing connectivity from a PC workstation protected by the FortiGate, ensure that there is an appropriate firewall policy to allow access. Example: internal to wan1 policy, source, destination of all, service of any with NAT enabled.
- Check the Virtual IPs: Ensure that any external IP referenced in a VIP belongs to the FortiGate. For example, do not use a provider's gateway address, as this could prevent the necessary route from being added to the kernel routing table. After updating the external IP to that of the FortiGate, it can be necessary to restart the routing process for this change to take effect:
execute router restart
- Validate if IPv6 DNS resolution delays are occurring: With each year more and more networks are moving to IPv6. With this shift, the new default behavior for Windows Vista and up is for workstations to prefer IPv6 name resolution and addressing over IPv4.
As noted in RFC 6721 there have been issues identified with dual-stack implementations causing delays. A symptom of this problem is intermittent delays in loading web pages, for example, when the DNS server is not configured for IPv6. The workstation may wait for some time before attempting resolution on IPv4. To confirm if this may be the issue it is possible to temporarily disable IPv6 on the network adapter or perform some packet captures to validate the network's DNS behavior. Note that disabling IPv6 could impact other services. - FortiGate as DHCP server: If the connected devices need to get IP from the FortiGate make sure the DHCP server is configured on the FortiGate interface:
Here, the Default gateway is set to the same as the interface IP, so that traffic reaches the correct Interface on FortiGate and then uses the necessary routing and policies, which will send out traffic to the internet.
- Ask for help: If the above fails, contact the point of purchase of the FortiGate for technical assistance.
