pjhtech Tools
FortiGate

FortiGate IPsec Up but a New Subnet Has No Traffic

Trace one new protected network through Child SA selectors, routing, policy, NAT and the destination host’s return path.

When an old subnet works over IPsec but a new subnet does not, add the new pair to any missing phase 2 selector, remote route and firewall-policy address group. Existing entries may already cover it; use the three corrections below to fill only the missing part.

Scope: FortiGate route-based IPv4 site-to-site VPN; one new, non-overlapping subnet.

Use one client/server pair

Example: client 192.0.2.10 at A connects to server 198.51.100.10 at B. On A, the phase 2 local selector must include the client and the remote selector the server; on B the roles reverse. Inspect members of any named groups, not just the group names. Phase 2 selectors may also constrain protocol and ports.

Read-only • replace the tunnel name; output can contain key material
diagnose vpn tunnel list name <existing-tunnel>

Find the proxyid whose src/dst covers the pair and check its sa count is nonzero (often sa=1). Compare enc:pkts/bytes and dec:pkts/bytes before and after the same client test at both peers. Keep raw SA output private.

Add the new subnet where it is missing

In each tunnel’s VDOM, read the configured selectors and routes:

Read-only • run in the tunnel’s VDOM
show full-configuration vpn ipsec phase2-interface
get router info routing-table details 198.51.100.10
diagnose firewall proute list

On A, the lookup above checks the route toward B’s server. On B, run get router info routing-table details 192.0.2.10 to check the return route toward A’s client. Each remote lookup should select that peer’s VPN interface. In policy-route output, compare iif (ingress), source wildcard, destination wildcard, protocol/sport/dport and oif (egress) with the test flow; a matching policy route can override the ordinary lookup. Routing monitor fields.

The phase 2 selector does not cover the new pair

Open VPN → IPsec Tunnels, edit the existing tunnel and add a phase 2 selector only if none covers this pair. For A set Local Address to 192.0.2.0/24 and Remote Address to 198.51.100.0/24; at B reverse those values. Match the existing agreed phase 2 proposal and PFS/group at both ends. Do not replace an older selector that still carries traffic.

The remote prefix has no VPN route

Under Network → Static Routes → Create New, set A’s Destination to 198.51.100.0/24 and Interface to the existing VPN. At B use 192.0.2.0/24 and its VPN interface. If a route already exists through the wrong interface, edit that route instead; if a routing protocol supplies it, correct its advertisement or selection.

The firewall policy does not include the new subnet

In Policy & Objects → Addresses, create the missing subnet address or add it to the appropriate existing group. In Firewall Policy, edit the specific LAN-to-VPN permit at A and VPN-to-LAN permit at B: source 192.0.2.0/24, destination 198.51.100.0/24, and the test service. Use the subnet objects, preserve existing group members and disable policy NAT for this non-overlapping routed example. Ensure an earlier rule does not match first. B-initiated new sessions need their own reverse permits; replies to A’s session are stateful.

Fortinet’s subnet-addition guidance covers these separate dependencies.

If the missing entry is unclear, trace the drop

On the peer where the packet stops, trace a new client connection in the receiving VDOM. The following filter follows requests from the example client to server. Avoid running it alongside another administrator’s debug session; changing debug state affects shared diagnostics.

Diagnostic state change • trace at most 20 matching packets
diagnose debug flow filter clear
diagnose debug flow filter saddr 192.0.2.10
diagnose debug flow filter daddr 198.51.100.10
diagnose debug flow trace start 20
diagnose debug enable

Start a new client connection. In the trace, read the received packet’s ingress interface, find a route egress, Allowed by Policy ID and any SNAT translation. For a policy deny, inspect the matching policy’s fields below. For reverse path check fail, drop, check the receiving VDOM’s route back to the packet’s source with get router info routing-table details 192.0.2.10 and get router info kernel. Correct a missing return route using the routing branch above. For an intentional policy-routed VDOM link that cannot use a suitable kernel return route, see the receiving VDOM-link RPF exception.

Existing offloaded sessions may be absent from debug flow; do not infer a drop from silence. Stop after the attempt, even if fewer than 20 packets matched:

Cleanup • stop the flow trace and clear its filters
diagnose debug flow trace stop
diagnose debug disable
diagnose debug flow filter clear

Read the reported policy with show firewall policy <policy-id> and compare its interfaces, source/destination, service and NAT. Debug-flow output may be forwarded to configured FortiAnalyzer/FortiCloud logging; keep this short and handle the results privately.

Retest with a new connection

Compare the new client flow with an existing working subnet. If reverting, remove only the added prefix, selector or rule and restore edited group membership. Do not remove a shared object to undo one subnet change.

References