Use during controlled troubleshooting. Capture the current state first and know how to stop or revert the operation.
FortiGate · FortiOS · 7.4
When to use this content
Use this workflow when FortiGate is reachable or partially operational but the expected service or traffic is not behaving correctly.
Problem
An IPsec tunnel appears up/established, but hosts cannot reach the expected remote subnet or application through it.
This is a common situation because an established IKE/IPsec security association proves that tunnel negotiation succeeded; it does not prove that routing, Phase 2 selectors, firewall policy, NAT, return routing, or the remote endpoint are correct for a specific traffic flow.
Objective
Identify the exact stage where the traffic stops.
The troubleshooting order should answer these questions:
- Is the expected Phase 2 security association up?
- Does the FortiGate have the correct route to the remote network?
- Does the traffic actually reach the FortiGate?
- Does the traffic match the correct firewall policy?
- Is NAT disabled or intentionally configured for the VPN flow?
- Do Phase 2 selectors include the tested source and destination?
- Does the packet leave through the IPsec tunnel?
- Does return traffic come back?
- Is the destination host/service itself reachable?
Example scenario
Site A LAN: 10.1.10.0/24
Site B LAN: 10.2.20.0/24
Test source: 10.1.10.20
Test destination: 10.2.20.10
VPN interface: IPSEC-SITE-B
Replace all values with the real environment before executing commands.
Step 1 - Confirm tunnel and Phase 2 state
Start with:
diagnose vpn tunnel list
On systems with many tunnels, filter by tunnel name where supported:
diagnose vpn tunnel list name IPSEC-SITE-B
Look for:
- The expected tunnel name
- An installed security association
- The expected proxy ID / selector information
- Packet counters (
rx/tx) where available
Fortinet's tunnel output includes counters and selector/security-association information that can help show whether packets are being encrypted or decrypted.
Interpretation
Tunnel is not established
This is not an "up but no traffic" problem. Move to Phase 1 / Phase 2 negotiation troubleshooting.
Tunnel is up but counters remain at zero
Generate controlled test traffic and check again.
If counters remain unchanged, the traffic may not be reaching the tunnel at all. Continue with routing, packet capture, and policy checks.
TX increases but RX does not
The local FortiGate is sending encrypted traffic, but no matching return traffic is being observed.
Investigate:
- Remote firewall policy
- Remote route back to the source network
- Remote selectors
- Destination host/service
- Upstream filtering
Step 2 - Confirm the route
Run:
get router info routing-table all
Find the route that should match the remote destination.
For the example destination 10.2.20.10, verify that the most-specific route points toward the intended IPsec interface/tunnel.
Critical check: overlapping routes
Do not look only for the expected /24 route.
A more-specific route such as:
10.2.20.0/26
will take precedence for destinations from 10.2.20.0 through 10.2.20.63 even if a broader /24 route points to the VPN.
This can produce symptoms where some addresses in the remote network work and others do not.
Step 3 - Confirm the traffic reaches the FortiGate
Use a narrow packet capture:
diagnose sniffer packet any 'host 10.1.10.20 and host 10.2.20.10' 4 0 l
Generate the failing traffic.
Interpretation
Nothing appears
The traffic is not reaching this FortiGate, or the filter/test is wrong.
Investigate the source endpoint, VLAN, default gateway, local switching, or another upstream device.
Traffic enters the LAN interface but does not appear on the tunnel
Continue with debug flow. Likely areas include routing, firewall policy, policy routing, selectors, or NAT/configuration logic.
Traffic enters and is seen leaving through the tunnel
The FortiGate is forwarding the traffic toward the VPN. Look for the return direction.
Traffic returns through the tunnel but does not reach the source host
Investigate the reverse firewall policy, routing, session state, endpoint path, or local network.
Step 4 - Use debug flow for the policy/routing decision
Reset existing state:
diagnose debug reset
Apply precise filters:
diagnose debug flow filter saddr 10.1.10.20
diagnose debug flow filter daddr 10.2.20.10
Optionally add protocol/port filters.
Enable function names and limit the trace:
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable
Generate the test traffic.
Then stop:
diagnose debug flow trace stop
diagnose debug disable
diagnose debug reset
What to look for
- Correct ingress interface
- Correct route / tunnel selection
- Firewall policy ID
- Accept or deny result
- Unexpected NAT
- Session handling
- Explicit drop reason
Step 5 - Validate firewall policies
For an interface-based site-to-site VPN, confirm there is an appropriate policy for the required direction.
Typical Site A to Site B flow:
Source interface: LAN / VLAN
Destination interface: IPSEC-SITE-B
Source: required local subnet/object
Destination: required remote subnet/object
Service: required service(s)
Action: ACCEPT
NAT: normally disabled for traditional site-to-site private-network traffic
The exact design may vary. NAT can be intentional in some VPN architectures, so treat "NAT disabled" as a common design expectation, not a universal rule.
If bidirectional initiation is required, validate the policy for the reverse direction as well.
Step 6 - Validate Phase 2 selectors
Fortinet documents Phase 2 quick mode selectors as defining the address ranges permitted for IPsec negotiation/security associations.
Confirm that the tested addresses are included in the configured local and remote selectors on both peers.
For example:
Local: 10.1.10.0/24
Remote: 10.2.20.0/24
If the remote peer is a third-party firewall, selector requirements can be stricter and must match the peer configuration.
A tunnel can appear established while the specific traffic being tested is outside the usable selector pair.
Step 7 - Check NAT
Unexpected SNAT is a frequent cause of VPN mismatch.
Use debug flow to confirm whether the source is translated.
For a conventional private subnet-to-subnet site-to-site policy, NAT is commonly disabled so that the remote peer receives the original source address.
If NAT is intentionally required, verify that:
- The translated source is included in the VPN design.
- The remote side has routes/selectors/policies for the translated network.
Step 8 - Confirm the return route on the remote side
A one-way packet path is not enough.
The remote device and destination network must know how to return traffic to the original source subnet.
If Site A sends:
10.1.10.20 -> 10.2.20.10
Site B needs a valid path back toward:
10.1.10.0/24
through the VPN.
A missing return route often produces a healthy-looking local FortiGate configuration with no application response.
Step 9 - Test from the FortiGate carefully
You can perform a controlled ping with a source address representing the local protected network:
execute ping-options source 10.1.10.1
execute ping 10.2.20.10
Be careful with interpretation: FortiGate-originated traffic is local-out traffic and does not prove that forwarded client traffic matches the same policy path.
Use packet capture and client-generated tests for final validation.
Step 10 - Validate the destination service
If packets traverse the VPN in both directions, move beyond the VPN.
Check:
- Is the destination host online?
- Is its local firewall allowing the traffic?
- Is the application listening on the expected IP and port?
- Is the server's default gateway correct?
- Does the application have its own access control?
A working IPsec tunnel cannot fix an application that is not listening.
Decision tree
IPsec shown as up
|
v
Phase 2 / SA installed?
| |
No Yes
| |
VPN negotiation |
troubleshooting v
Correct route?
| |
No Yes
| |
Fix route v
Traffic reaches FGT?
| |
No Yes
| |
Source/L2 path v
Correct policy/decision?
| |
No Yes
| |
Fix policy v
Seen on IPsec tunnel?
| |
No Yes
| |
Selectors/NAT/ v
route/debug Return traffic?
| |
No Yes
| |
Remote side v
/ return path Host/application
Evidence to collect before changing configuration
Capture the following before making changes:
Source IP:
Destination IP:
Protocol/port:
Tunnel name:
Phase 1 status:
Phase 2 status:
TX/RX counters before test:
TX/RX counters after test:
Selected route:
Firewall policy ID:
NAT observed:
Packet sniffer result:
Debug-flow result:
Remote-side result:
This makes troubleshooting reproducible and reduces configuration changes based on assumptions.
Common root causes
- Missing or incorrect route
- More-specific overlapping route
- Missing firewall policy
- Wrong policy order
- Unexpected NAT
- Phase 2 selector mismatch
- Wrong source/destination object
- Remote firewall policy
- Missing remote return route
- Host firewall
- Service not listening
- Testing with the wrong source address
- Hardware-offloaded session hiding expected debug-flow output
Risks and rollback
Most commands in this runbook are read-only diagnostics.
diagnose debug flow can produce a large amount of output and should always be filtered and stopped after testing.
Do not reset, flush, bring down, or delete VPN security associations simply because the tunnel is not passing traffic. Those actions affect live connectivity and should only be used when the evidence specifically justifies them.
Related articles
- FortiGate
diagnose vpn tunnel - FortiGate debug flow
- FortiGate packet sniffer
- FortiGate routing table
- FortiGate execute ping
Sources
See the authoritative Fortinet references in the article metadata.
This article is part of a path
Knowledge graph
Explicit editorial relationships across prerequisites, commands, troubleshooting, Labs and next steps.
Did this article help you solve the problem?
Each account can vote once per article. You can change your vote without increasing the total count.
0 user reports