FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Adam_Shortt_FTNT
Article Id 197646

Description

 

The purpose of this article is to aid in troubleshooting WAN connectivity between the FortiGate firewall and a service provider. It is assumed that the FortiGate unit has limited or no Internet connectivity even though the appropriate ISP-provided equipment is configured and connected to the FortiGate unit.

 

Scope

 

All FortiGate versions.

 

Solution

 

Please note:
Make sure to backup the FortiGate unit configuration file before proceeding with steps below.
If using a modem, please reboot it after making any changes to the FortiGate unit.

Check the following to aid in troubleshooting the issue:
 
1. Power: Make sure the FortiGate unit and providers equipment (CPE) are adequately powered, and that there is link light activity on both devices.
 
2. Link Speed Detection: Determine what link speed the providers equipment supports (for example, 10/100/1000 Mbps). On the FortiGate unit, 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) # diag 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 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 unit to the highest values supported by the provider's equipment:

 

FGT (global) # conf sys int
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 unit or to a network local to the FortiGate unit. This is because the connectivity on a network interface may become unavailable when the interface configuration is changed.

 
3. MAC filtering: If the service was originally used with another device (not the FortiGate unit), confirm if it still works with that device. If so, ideally try with another, third device. 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, please contact the service provider to have the MAC filter cleared, and provide the FortiGate unit WAN network interface MAC address. Obtain the FortiGate unit 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 # conf sys int
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.


4. 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 ping succeeds, IP connectivity is working. If pinging by FQDN fails, check DNS. If pinging by IP fails then, run sniffer:

 

diag sniff pack 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 most likely the issue with the next hop or ISP.

 

===================================================


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

 

======================================


6. Isolate the FortiGate unit: If there is an intermediate switch between the FortiGate unit and the provider, confirm that it has the correct MAC address of the FortiGate unit and that the FortiGate unit also has the switch's MAC:

 

FGT # get system arp

 

Ideally, try to test without the switch in the path.


7. 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. It is possible that another ISP customer may be using the same model of FortiGate unit in a cluster with the default group ID of 0 - if that's the case, both FortiGate units may be using the same virtual MAC address, which result in Layer 2 conflicts.


8. Packet sniffing and traceroute: Ensure the FortiGate unit WAN interface has ping enabled. Using the built-in packet sniffer, try sniffing on the problematic FortiGate unit WAN interface:

FGT # diag sniff packet wan1 'icmp'
 
Meanwhile, try to ping the interface IP from another host on the Internet. If it resolves, great - you are likely connected fine. Try pinging out from the FortiGate unit back to the other device next:

FGT # exec 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 trace route in both directions: it is possible that a routing issue is occurring on the ISP level.

FGT # exec traceroute <node ip>
 

If the other node's trace route stops receiving replies before its packets get to the FortiGate gateway device, there may be a routing issue with the provider.

 
===================================
 
If using public on 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 you receive any packets while using 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, please remove the policy routing until you are back to using basic static routing. Test from the FortiGate unit command line for connectivity:
 
exec ping 4.2.2.2
 
(Any reliable IP address on the Internet can be used.)

10. Firewall Policies: If testing connectivity from a PC workstation, protected by the FortiGate unit, 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.
 
 
11. Check the Virtual IP's: Ensure that any external IP referenced in a VIP belongs to the FortiGate unit itself. 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 unit, you may need to restart the routing process for this change to take effect:

execute router restart

12. 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 you can temporarily disable IPv6 on the network adapter or perform some packet captures to validate your network's DNS behavior. Note that disabling IPv6 could impact other services.

 
13. Ask for help: If the above fails, please contact the point of purchase of your FortiGate unit for technical assistance.