FortiGate Self-Originated IKE Traffic Bypasses Local-In-Policy Drop on Dial-Up VPN

Hello,

I am facing a persistent issue with a Dial-up IPSec VPN tunnel configuration on our HQ FortiGate.

HQ Public IP -> 176.x.x.x

Location -> 91.x.x.x

Our goal is to restrict IPSec VPN connections only to a specific list of public IP addresses. To achieve this, I've configured a local-in-policy to permit only our allowed IP group (Public_IPs) and deny IKE/ESP traffic from all other sources.

Here is the current local-in-policy configuration:

config firewall local-in-policy
    edit 1
        set intf "FortiStore_WAN"
        set srcaddr "Public_IPs"
        set dstaddr "all"
        set action accept
        set service "IKE" "ESP"
        set schedule "always"
    next
    edit 2
        set intf "FortiStore_WAN"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "IKE" "ESP"
        set schedule "always"
    next
end

An unauthorized remote gateway (e.g., 91.x.x.x) that is not in the Public_IPs address group is still able to establish a VPN tunnel with our HQ FortiGate.

According to the packet flow trace (diagnose debug flow):

1. Initially, when the unauthorized IP (91.x.x.x) sends a packet, the local-in-policy successfully drops it under Policy ID 2: iprope_in_check() check failed on policy 2, drop

2. However, shortly after, the HQ FortiGate itself initiates or responds by looking for an existing session and sending outbound traffic to the remote peer: resolve_ip_tuple_fast line=5899 msg="Find an existing session, id-40f74ec6, reply direction"

3. Because this becomes a self-originated outbound request from the FortiGate, it bypasses the local-in-policy (which only filters inbound traffic to the box), allowing the tunnel to establish.

• I disabled keepalive on the phase2 configurations to prevent the FortiGate from attempting to bring up the tunnel itself, but the issue still persists.

• Since this is a Dial-up configuration, the HQ FortiGate should strictly act as a responder and never initiate connections outward to dial-up clients, yet it still generates outbound sessions.

How can I completely block these connection attempts if local-in-policy is bypassed by the firewall's own self-originated reply packets?

Thanks in advance.