Skip to content

Enable IP Forwarding Between Interfaces

"IP forwarding" is one of those phrases that means two different things depending on context:

  1. Routing traffic between interfaces — letting a packet that arrives on one FortiGate interface leave through another. This is what most people mean when they ask "how do I enable IP forwarding."
  2. Port forwarding — letting an external request reach an internal server. That's different and lives under Virtual IPs (VIPs). See Forward a Port to an Internal Server (VIP / DNAT).

This page covers #1.

What's Actually Happening

By default, the FortiGate does NOT forward traffic between interfaces. Every flow between two interfaces requires:

  1. A route that knows where the destination lives (the routing table).
  2. A firewall policy that allows the flow (source interface → destination interface, source address → destination address, on the right service).

There's no global "enable IP forwarding" toggle like there is on Linux (net.ipv4.ip_forward=1). FortiOS forwards as soon as you have both a route AND a firewall policy.

Steps to Forward Traffic Between Two Interfaces

Example: clients on the internal interface (LAN, 10.0.0.0/24) should reach servers on the dmz interface (172.16.0.0/24).

1. Confirm both interfaces are configured

Network → Interfaces — both interfaces should be Up with IPs in their respective subnets. See Configure a Network Interface.

2. Confirm the route exists

Connected routes (subnets directly on FortiGate interfaces) are automatic — no static route needed. Run:

get router info routing-table connected

You should see lines like:

C       10.0.0.0/24 is directly connected, internal
C       172.16.0.0/24 is directly connected, dmz

If both subnets show, routing is ready.

3. Create the firewall policy

This is the missing piece — the policy that says "internal can talk to dmz."

  1. Policy & Objects → Firewall Policy → + Create New.
  2. Fill in:
    • Name — e.g. LAN-to-DMZ.
    • Incoming Interface — internal.
    • Outgoing Interface — dmz.
    • Source — all (or a specific address object like Office-LAN).
    • Destination — all (or a specific server object).
    • Schedule — always.
    • Service — ALL (or restrict to specific services like HTTP, HTTPS).
    • Action — Accept.
    • NAT — Off (you usually don't NAT between internal interfaces; you do NAT when going to WAN).
  3. Click OK.
  4. Drag the policy into the right position in the list (policies match top-down).

4. Reciprocal direction if needed

If DMZ servers should also initiate connections back to LAN clients, add a second policy DMZ-to-LAN. Most setups don't — DMZ initiates outbound to WAN only.

CLI Equivalent

config firewall policy
edit 0
    set name "LAN-to-DMZ"
    set srcintf "internal"
    set dstintf "dmz"
    set srcaddr "all"
    set dstaddr "all"
    set action accept
    set schedule "always"
    set service "ALL"
    set logtraffic all
next
end

Verify

From a client on internal, ping a server in dmz:

ping 172.16.0.10

Check the policy hit count:

diagnose firewall iprope show 100004 | grep <policy-id>

In GUI: Policy & Objects → Firewall Policy — the policy row shows live byte/packet counts.

Common Issues

  • Ping works but a specific application doesn't. Service field too restrictive. Add the application's port to the Service field, or use ALL for testing then narrow down.
  • Traffic passes one way only. You only added one direction's policy. FortiGate is stateful, so once a flow is allowed in one direction, return traffic is automatic — BUT only if the flow was initiated in the allowed direction. To allow either side to initiate, add policies both ways.
  • No traffic at all, even though policy exists. Policy is below a more general DENY policy in the list. Drag your ACCEPT policy higher.
  • Traffic gets dropped with "policy 0" in logs. No matching policy — FortiOS denies by default with implicit policy 0. Add the policy or check that source/dest match.