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

IPSec tunnel probes drop "reverse path check fail, drop"

  • June 22, 2025
  • 3 replies
  • 2620 views

Hi,

I have a SonicWall NSA (site A) connected to Fortigate (site B) with IPSec Tunnel. Site A sends ping probes over the tunnel interface to site B's WAN IP. The Sonicwall configures implicit probes when configurating the IPSec tunnels in virtual SD-WAN configuration. Debug flow revealed "reverse path check fail, drop" due to strict RPF, so I configured a DNAT policy with Virtual IP as below. This got me passed the RPF check but when enabling below policy the CLI command does not responds normally for some reasons so I must be doing something wrong. Any suggestions?

 

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

 

Firewall Policy

edit 24
set status disable
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"                 (site A WAN interface IP)
set dstaddr "vpn-hub-probe-vip"
set schedule "always"
set service "PING"
next

 

 

Screenshot 2025-06-22 171946.png

 

3 replies

Toshi_Esumi
SuperUser
Toshi_Esumi
SuperUser
June 22, 2025

Not sure about Sonicwall's configuration since I haven't touched Sonicwalls before. But it seems to be flexible to let you choose the source IP/interface for the probing packets.
Then, you shouldn't be pinging the public IP on the FGT side. Otherwise, you wouldn't be proving the tunnel (through the tunnel) but proving just the internet path from the FGT. Instead, you should be pinging from the source IP within the source subnet(s) you configured in the phase2 network selectors, and to the destination IP within the destination subnet(s) also in the phase2 config. That would detect tunnel down while the internet is up on the FGT side, which can be used for failover or something else.
Then you would never have RPFs at the first place.

Toshi 

    dbah01
    dbah01Author
    Explorer
    June 22, 2025

    Sonicwall's "SD-WAN" / Virtual IPSec tunnel group probes cannot be modified; it probes the remote side public interface IPs through each respective tunnel in the group. Not sure why though; for individual tunnels the probes can be customized.

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    June 23, 2025

    Are you sure the 169.255.x.x in the flow debug is the Sonicwall's public IP? 

    dbah01
    dbah01Author
    Explorer
    June 23, 2025

    Yes, 100%

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    June 23, 2025

    Based on this Soncwall's doc:
    https://www.sonicwall.com/support/knowledge-base/how-do-i-configure-sd-wan-using-vpn-numbered-tunnel-interfaces/190214085748593
    One end has 10.0.0.1/30 configured as the tunnel interface IP. That implies the other end has 10.0.0.2/30 configured as the counter part.
    Then it says:
    "For the SD-WAN on VPN Tunnel interfaces, the Performance Probe object is auto created..."

    This implies to me that it automatically uses those 10.0.0.1 and .2 for the performance prove. Then if the other end is a FGT, I would try duplicate this config. With FGT, the tunnel interface IP (and remote-ip) you can configure is /32. So in CLI it would look like below if I used the 10.0.0.1/30 on the Sonicwall side:

    config system interface
      edit [tunnel_name]
        set ip 10.0.0.2 255.255.255.255
        set remote-ip 10.0.0.1 255.255.255.255

      next
    end

    Toshi

      ebrlima
      Staff
      ebrlima
      Staff
      June 23, 2025

      Are you using the public ip address to manage the firewall? Because this could be messing up your management session, since you have the same IP for management and also for a DNAT rule.

       

      Also, your vip object maps to a lan interface IP, which would be useful if the SonicWall is trying to ping the  "192.168.10.1" ip. To probe the public IP, the rule should be from the tunnel interface to the wan interface, and the IP address of wan interface should be allowed via phase2 configuration.

       

       

      Terms & ConditionsAccessibility statement