Skip to main content
arkololo
arkololo
Visitor III
February 17, 2026
Question

IPsec IKEv2 FortiClient + EAP + FortiToken connects, but all traffic dropped (policy 0)

  • February 17, 2026
  • 2 replies
  • 1104 views

FortiGate / FortiOS: Fortigate 81F / v7.6.2
VPN: IPsec IKEv2 dial-up 
Client: FortiClient VPN-only
Auth: Local users + EAP-MSCHAPv2 + FortiToken (2FA)

 

Whats working so far : 

  • FortiClient connects successfully

  • FortiToken OTP is requested and validated

  • Client receives an IP from the IPsec pool

  • Tunnel is UP

 

Issue : 

  • No access to LAN resources (can't ping my DCs from ipsec vpn but can from ssl vpn)

  • All traffic is dropped by firewall with policy 0

 

Debug : 

 

Flow debug shows:

received packet from VPN_IPSEC_0 route found via LAN Denied by forward policy check (policy 0)

 

Policies I tried so far : 

  • srcintf = VPN_IPSEC (not accepted)

  • srcintf = VPN_IPSEC_0 (not a valid interface)

  • srcintf = zone containing VPN_IPSEC

  • srcintf = any

  • With / without user groups

  • With very permissive rules (ALL / ALL)

Still always policy 0.

 

Observations 

  • Interface VPN_IPSEC exists (169.254.x.x, type tunnel, UP)

  • Traffic arrives as VPN_IPSEC_0, which cannot be referenced in policies or zones

  • Authentication and routing are correct, but traffic never matches any firewall policy

 

Question

Is this a known FortiOS limitation/bug with wizard-created IPsec dial-up tunnels where traffic is bound to an internal interface not exposed to the policy engine?

If so, is the only solution to recreate the tunnel manually (route-based, no wizard)?

2 replies

funkylicious
SuperUser
funkylicious
SuperUser
February 17, 2026

hi,

as for the firewall rules, if you are using the user group in the phase1, you dont need it in the rules and vice versa. try setting tho a specific destination interface for the traffic in the rules, the source is VPN_IPSEC itself.

 

i would suggest to have different subnets allocated to user connecting to IPsec to the ones connecting to SSLVPN.

 

does the client get specific routes upon connecting to the vpn or is it full tunnel ?

 

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Connected-to-Dialup-IPsec-tunnel-but-traffic/ta-p/296333 

"jack of all trades, master of none"
arkololo
arkololoAuthor
Visitor III
February 17, 2026

Hi,

Thanks for the suggestions.

To clarify based on my setup and tests so far:

 

I am not using the user group in phase1.
The user group is applied only in the firewall policy, not in phase1.

SSL VPN and IPsec VPN already use different address pools.
SSL users and IPsec users are on separate subnets, so there is no overlap or ambiguity there.

 

Regarding the firewall rule:

 

I cannot use VPN_IPSEC as source interface in the policy (CLI rejects it).

Traffic appears in debug as coming from VPN_IPSEC_0, which is not a valid interface or zone member for firewall policies.

 

Routing-wise:

 

The client does receive routes via mode-config.

This is split tunnel, with internal subnets explicitly pushed to the client.

Routing on both client and FortiGate is correct (confirmed in debug: route lookup succeeds).

At this point, authentication, addressing, routing, and split tunnel are all working as expected.
The issue seems to be that traffic from the IPsec dial-up tunnel is not bindable to a firewall-policy-usable interface, unlike SSL VPN (ssl.root), so no firewall rule ever matches.

funkylicious
SuperUser
funkylicious
SuperUser
February 17, 2026

the source interface for the traffic is the phase1-interface.

VPN_IPsec_0 is the device/interface created by a user logged in due to net-device enabled in phase1, it will keep incrementing depending on how many users connect so it cannot be the source, but its parent.

 

L.E. can you share the whole debug output for a session, start to finish ?

"jack of all trades, master of none"
mark8263
mark8263
New Member
February 17, 2026

A couple of questions:

What ip address or scope have you assigned to those users, from the fw or internal? It doesn't seem like you have provided an address to them if their ip address is a 169.x address, unless that's your scope.

Whenever I created mine, with the Wizard (using sso, but shouldn't matter), I had to create a internal scope of addresses for those users and then create routes to the internal networks that they needed access to.  The scope I created was a 'local' scope to/on the firewall instead of pushing the dhcp request to my internal dhcp server.

 

arkololo
arkololoAuthor
Visitor III
February 17, 2026

The 169.254.x.x address is the IPsec tunnel interface on the FortiGate, not the client address.

Clients are assigned IPs from a local IPsec mode-config pool on the FortiGate:

10.0.2.100–10.0.150

This is not DHCP from the internal network and not an internal DHCP relay.

Split tunneling is enabled and specific internal routes are pushed to the client via mode-config (ipv4-split-include). Routing on the FortiGate side is correct and confirmed in debug.

So address assignment and routing behave as expected; the issue is not related to missing client IP allocation or DHCP scope imo

Terms & ConditionsAccessibility statement