A clear path
through FortiGate.

01 / Before configuration

Gather the service details.

Confirm the handoff location, port and optic requirements, cable, operational speed, and any specified VLAN, MTU, negotiation or FEC settings. Obtain the actual address, prefix or mask, gateway and routed-block instructions from the service order. Confirm which team manages each device.

Virtual wire or transparent modes, dynamic routing, multiple providers, and upstream routers require different steps. This guide does not replace the organization’s approved design.

02 / Physical connection

Check the link first.

Connect the agreed data port using supported optics and cabling. Compare operational link state and speed on both sides. If a switch or router sits between the firewall and provider, check each interface on that path. A link can be up while VLAN, MTU, or routing settings are wrong.

03 / WAN interface

Assign the external interface.

For a FortiOS 7.4 example, open Network → Interfaces, select the agreed WAN data interface, and edit its addressing. Select the static addressing option and enter the provider-assigned IPv4 address and netmask. Interface names and available settings differ by model, firmware, and configuration; wan1 below is an example, not an assumed port.

Optional CLI example

For a static IPv4 handoff on FortiOS 7.4, the following partial configuration illustrates the interface settings. The interface and address are examples; use your approved assignment and the correct VDOM. This does not configure routing, security policy, or NAT. Applying interface changes can interrupt connectivity, so retain management and rollback access.

config system interface
    edit "wan1"
        set mode static
        set ip 198.51.100.2 255.255.255.252
    next
end

Configure the internal interfaces and address ranges according to the existing LAN design. If the handoff uses a VLAN, use the agreed tagging and interface design rather than assuming an untagged port.

04 / Routing

Set the path to the provider.

In the illustrated static design, open Network → Static Routes and configure the appropriate IPv4 default route, destination 0.0.0.0/0, with the provider-assigned gateway and correct outgoing interface. For illustration, 198.51.100.2/30 is the interface address and 198.51.100.1 the next hop; these documentation addresses are not usable Stealth assignments.

Some FortiGate models may already use SD-WAN, and DHCP or dynamic routing may supply routes. Check the active routing and SD-WAN design before adding a competing default route. In a multi-VDOM configuration, verify that the interface, route, and policy belong to the correct VDOM.

05 / Security policy and NAT

Allow the intended traffic.

Review Policy & Objects → Firewall Policy for the intended incoming and outgoing interfaces or zones, source and destination, services, logging, and security profiles. Permit only the traffic required by the business. A route does not itself permit a session.

For internal private IPv4 addresses, source NAT is often required. Depending on the design and whether central NAT is enabled, translation may be controlled in the firewall policy or by separate NAT rules. A routed public block or IPv6 design may have different requirements; do not assume NAT is always needed. NAT does not replace the firewall policy.

Check the actual rule order, translation, and return path for a representative flow. Avoid broad allow rules or disabling inspection merely to make a test pass.

06 / Verify the result

Work outward from the handoff.

1. 01

   Review and apply

   Confirm the intended interface, zone, address, gateway, route, access rule and translation. Apply changes through the correct management workflow and retain rollback access.

2. 02

   Check link and gateway

   Verify the operational interface speed and state, then test the gateway from the appropriate source where permitted. An unanswered ping alone does not prove all traffic is blocked.

3. 03

   Check a client

   From an authorized wired client, test DNS, an approved external destination, and a business application. Confirm the return path and repeat for IPv6 where used.

4. 04

   Record the baseline

   Record the time, interface counters, test direction, and results for later comparison.

07 / Troubleshooting

Follow the evidence.

If the link is up but clients cannot reach the Internet, check the WAN address and gateway, active routing or SD-WAN selection, LAN-to-WAN policy, source NAT where required, DNS, and the return path. A successful firewall-originated ping may follow different local-out routing or policy than a client session; check both paths.

diagnose hardware deviceinfo nic wan1

get router info routing-table all

get system performance status

diagnose netlink interface list wan1

# diagnose netlink interface list wan1
if=wan1 ... mtu=1500 ...
flags=up broadcast run multicast
stat: rxp=124820 txp=118500 ... rxe=2 txe=0 rxd=0 txd=0 ...

Compare physical and logical errors or discards over time on the firewall and each device through the circuit handoff. A rising counter is a reason to investigate, not proof of where a fault occurred. Record values before clearing counters; coordinate captures and keep sensitive diagnostic data in approved support channels.

Review the relevant logs and session or policy decisions for a specific authorized flow, and verify which device and path carry the return traffic. For name-resolution symptoms, see our business DNS guide.

08 / Capacity and performance

Check the whole path.

Interface speed is not the same as throughput with inspection, VPN, logging, and the business’s traffic profile enabled. Check the model’s documented capabilities and resource use during the issue. A five-minute average can hide short bursts.

Use capable, separate client and server systems for a throughput test across the path. Coordinate high-speed tests to avoid disrupting production. Our performance guide covers iperf3, latency, loss, and the limits of the measurement.

09 / Escalation

What to have ready.

• Service address, circuit identifier, handoff, and affected interface.
• When the issue began, time zone, affected applications, and recent changes.
• Operational link speed and state, plus counter changes at accessible devices along the path.
• Source, destination, address family, test results, and whether the client used Wi-Fi or a VPN.
• Relevant route, security-policy, and NAT evidence without passwords or private keys.

For Stealth service, contact support@stealth.net or +1 212 232 2020. Your firewall administrator and vendor support can assist with device and policy behavior.