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

[dbah01]

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

[Toshi_Esumi]

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]

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]

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

[dbah01]

Yes, 100%

[Toshi_Esumi]

Based on this Soncwall's doc:
https://www.sonicwall.com/support/knowledge-base/how-do-i-configure-sd-wan-using-vpn-numbered-tunnel...
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

[dbah01]

Hi Toshi, one would hope that the auto created probes will target the remote tunnel interface 10.0.0.1 but it targets the remote gateway (WAN) IP, don't know why though.

[Toshi_Esumi]

You should get Sonicwall support, or their community's help to figure out why not. If public to public proving, it can't come through the tunnel. Has to be outside of the tunnel. Could be a bug on their end.

Toshi

[ebrlima]

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.