Skip to main content
dbah01
dbah01
Explorer
June 22, 2025
Solved

IPSec tunnel probes received targeting WAN interface dropped

  • June 22, 2025
  • 2 replies
  • 1360 views

Hi,

I have a remote site A (SonicWall NSA) connected to site B (FortiGate) with IPSec tunnel. Site A is sending load balancing probes (over the tunnel) to site B, but it's targeting the WAN interface IP of site A. Traffic arrives on my tunnel interface at site B. Note that site A's probes are implicit and cannot be edited to target one of my local IPs on the local site. On the receiving site the FortiGate drops the traffic due to strict RPF, message as in logs below contains "reverse path check fail, drop". I tried setting up a DNAT with Virtual IP and got pass the initial above error, but still could not get the firewall policy to trigger correctly. When I enable below CLI bash stops working for some reason, so I suspect something is not right. Any idea if this is the right approach and what I should look at? Thnks.

 

Policies are:

vip

config firewall vip
edit "vpn-ahg-hub-probe-vip"
set uuid 3e958d92-4f6b-51f0-67e8-xxx
set extip 217.91.x.x
set mappedip "192.168.10.1"  --> local LAN interface
set extintf "any"
next
end

 

firewall:

edit 24
set status enable
set name "TEST"
set uuid 20025a9c-4f6e-51f0-1a3d-xxx
set srcintf "virtual-vpn-to-hub-link"
set dstintf "lan"
set action accept
set srcaddr "PubIP 169.255.x.x"
set dstaddr "vpn-ahg-hub-probe-vip"
set schedule "always"
set service "PING"
next

 

 

log before vip :

id=20085 trace_id=2531 func=print_pkt_detail line=5957 msg="vd-root:0 received a packet(proto=50, 169.255.x.x:0->217.91.x.x:0) tun_id=0.0.0.0 from ppp2. "
id=20085 trace_id=2532 func=print_pkt_detail line=5957 msg="vd-root:0 received a packet(proto=50, 169.255.x.x:0->217.91.x.x:0) tun_id=0.0.0.0 from ppp2. "
id=20085 trace_id=2533 func=print_pkt_detail line=5957 msg="vd-root:0 received a packet(proto=50, 169.255.x.x:0->217.91.x.x:0) tun_id=0.0.0.0 from ppp2. "
id=20085 trace_id=2534 func=print_pkt_detail line=5957 msg="vd-root:0 received a packet(proto=1, 169.255.x.x:64222->217.91.x.x:2048) tun_id=169.255.x.x from HUB-V60. type=8, code=0, id=64222, seq=5031."
id=20085 trace_id=2534 func=init_ip_session_common line=6137 msg="allocate a new session-001cd75f, tun_id=169.255.x.x"
id=20085 trace_id=2534 func=ip_route_input_slow line=1704 msg="reverse path check fail, drop"
id=20085 trace_id=2534 func=ip_session_handle_no_dst line=6223 msg="trace"

Best answer by Jean-Philippe_P

Hello dbah01,

 

I found this answer. Can you tell me if it helps, please?

 

Your solution effectively addresses the issue by allowing ping traffic through the IPsec tunnel while blocking external pings for security. Here are some insights and considerations:

 

  1. Enable Ping on WAN Interface: This step is necessary to allow the FortiGate to respond to ping requests on the WAN interface. It's a common requirement for troubleshooting and monitoring.

  2. Local-In Policy Configuration:
    - Allowing ping from the specific source IP (remote WAN) ensures that only trusted traffic can reach the WAN interface.
    - Denying all other ping requests on the WAN interface enhances security by preventing unauthorized access.

  3. Static Return Route: Configuring a static route for the return path ensures that responses to the ping requests are correctly routed back through the IPsec tunnel.

  4. Firewall Policy: Allowing ping traffic from the tunnel to the WAN interface ensures that the traffic is permitted through the firewall, completing the communication path.

  5. Security Considerations:
    - While enabling ping on the WAN interface is necessary for this setup, ensure that other security measures are in place to protect the interface from potential threats.
    - Regularly review and update firewall policies and routes to adapt to any network changes.

 

Your approach is sound, and the configuration steps you've taken are appropriate for the scenario. If you wish to explore alternatives, consider using more granular access controls or monitoring tools to further secure and manage the traffic.

2 replies

Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
June 25, 2025

Hello dbah01, 

 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

 

Thanks, 

Jean-Philippe - Fortinet Community Team
    dbah01
    dbah01Author
    Explorer
    June 25, 2025

    Hi,

    Managed to resolve this issue in the following way:

     

    1. Enabled Ping on WAN interface

     

    2. Configure allow local-in policy to allow ping to WAN interface from within the Fortigate. Source address is the remote WAN on the other side of the IPsec tunnel. 

    edit 3
    set uuid 3465fe5c-5203-51f0-7122-x
    set intf "WAN VLAN7"
    set srcaddr "PubIP_169.255.x.x"
    set dstaddr "PubIP_217.91.x.x"
    set action accept
    set service "PING"
    set schedule "always"
    next

     

    3. Configure deny local-in policy on WAN interface to block external ping probes for security

    edit 4
    set uuid 83d0e9d8-5209-51f0-7be4-x
    set intf "WAN"
    set srcaddr "all"
    set dstaddr "PubIP_217.91.x.x"
    set service "PING"
    set schedule "always"
    set comments "Block external ping on this WAN"
    next

     

    4. configure static return route for 169.255.x.x to IPSec tunnel

    5. configure firewall policy to allow ping traffic from tunnel to WAN interface

     

    Once I had above in place the ping packet reply was received at the remote side. Ping probes to my WAN interface over Internet is blocked. I was trying to get this working without enabling Ping on the WAN interface itself, but this was the only way I could get this working. I'd appreciate any more insights. 

     

    Kind regards

     

     

      Jean-Philippe_P
      Staff & Editor
      Jean-Philippe_P
      Staff & Editor
      June 26, 2025

      Hello,

       

      Thanks for the follow-up!

       

      We are still looking for an answer to your question.

       

      We will come back to you ASAP.

       

      Thanks,

      Jean-Philippe - Fortinet Community Team
      Terms & ConditionsAccessibility statement