Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 2599 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Site-to-Site connected but no traffic over failover GW

Werner Smit

Good day,

On our XG230 [SFOS 20.0.0 GA-Build222] we have two IPsec site-to-site tunnels on two different GWs.


Both connect to the same remote GW but use Different NATed local Subnets to Fortigate Firewall. IPSec policies are the same no change there.

When connecting the Primary tunnel over Port 3. Connection is established and traffic flows.

Connecting the Backup tunnel over port 2. Connection is established but no traffic is flowing

  • Checked SD-WAN's 
  • Checked FW rules 

Anyone have suggestions on how to get the traffic to flow over the Backup line which uses port 2 or the backup GW?

IPsec logs:

MRI_Ent2_SC-1[7524945]: ESTABLISHED 2 hours ago, <BackupGW IP>...105.243.233.162[105.243.233.162]
MRI_Ent2_SC-1[7524945]: IKEv2 SPIs: 1f652a70fc26c820_i* 220f6adcc589567d_r, rekeying in 21 hours
MRI_Ent2_SC-1[7524945]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
MRI_Ent2_SC-1{20285}: INSTALLED, TUNNEL, reqid 107, ESP SPIs: c3a8933a_i 62641c46_o
MRI_Ent2_SC-1{20285}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 47012 bytes_o (909 pkts, 79s ago), rekeying in 9 hours
MRI_Ent2_SC-1{20285}: 172.31.1.9/32 === 10.89.140.53/32

Packet Cap when on backup GW:



This thread was automatically locked due to age.
Parents
  • 0

     , I assume you are using policy based IPSec. Why do you want to use NATed local Subnets when the local subnet of SFOS is different from LAN host of Fortigate? Can you check this - do not enable Failover group on SFOS, keep only the IPsec tunnel hosted on Port2 of SFOS UP, verify the end-to-end traffic (from LAN client of SFOS to LAN client of Fortigate) works and go via the IPsec tunnel hosted on Port2. If this path works fine, then enable the failover group, on the occurrence of failover, repeat the traffic from LAN client of SFOS to client of Fortigate, do 'tcpdump -n esp' on SFOS if the traffic is going via the tunnel; verify if the LAN host of Fortigate receives traffic etc.. You can DM me if you need a session to debug this further.

  • 0 in reply to Werner Smit

     , did you try this that was asked earlier? I am waiting for the result of this verficiation:

    Can you check this - do not enable Failover group on SFOS, keep only the IPsec tunnel hosted on Port2 of SFOS UP, verify the end-to-end traffic (from LAN client of SFOS to LAN client of Fortigate) works and go via the IPsec tunnel hosted on Port2. If this path works fine, then enable the failover group, on the occurrence of failover, repeat the traffic from LAN client of SFOS to client of Fortigate, do 'tcpdump -n esp' on SFOS if the traffic is going via the tunnel; verify if the LAN host of Fortigate receives traffic etc..

Reply
  • 0 in reply to Werner Smit

     , did you try this that was asked earlier? I am waiting for the result of this verficiation:

    Can you check this - do not enable Failover group on SFOS, keep only the IPsec tunnel hosted on Port2 of SFOS UP, verify the end-to-end traffic (from LAN client of SFOS to LAN client of Fortigate) works and go via the IPsec tunnel hosted on Port2. If this path works fine, then enable the failover group, on the occurrence of failover, repeat the traffic from LAN client of SFOS to client of Fortigate, do 'tcpdump -n esp' on SFOS if the traffic is going via the tunnel; verify if the LAN host of Fortigate receives traffic etc..

Children
No Data
Unfiltered HTML