Reachability Issue Between Head Office and Branch IP After IPSec VPN Reconfigure

[rohitchoudhary1978]

Hi,
I’m encountering a reachability issue between our Head Office and Branch Office following changes to our IP Sec VPN setup.
Specifically, the public IP of our Branch Office b-b-b-b is no longer reachable from our Head Office IP h-h-h-h. However, b-b-b-b remains accessible from other external sources, indicating that the branch connection is working outside the Head Office route.
This issue began after we deleted and reconfigured the IP Sec VPN on the Head Office firewall. Since then, the VPN tunnel fails to establish due to unreachability.

Notably
1- If I set up policy-based routing from the Head Office, I can reach b-b-b-b
2- However, with this routing, the IP Sec VPN tunnel fails to work.
3- I’ve verified that there are no deny policies, including local-in-policy, and the IP is only used in the IP Sec configuration.

Ping response from Head Office firewall:
execute ping b-b-b-b
send msg failed: 22 Invalid argument
send msg failed: 22 Invalid argument
send msg failed: 22 Invalid argument
send msg failed: 22 Invalid argument
send msg failed: 22 Invalid argument

Could you please advise on how best to proceed with diagnosing and resolving this issue?

Thanks,
Rohit K

[dingjerry_FTNT · Accepted solution]

Hi @rohitchoudhary1978 ,

1) "This issue began after we deleted and reconfigured the IP Sec VPN on the Head Office firewall."

Any reason why you deleted and reconfigured the IPSec VPN on the Head Office?

Did you delete the IPSec VPN configuration, then copy from the backup FGT config to reconfigure it again?  Or how did you do it?  Did you make any changes?

2) "If I set up policy-based routing from the Head Office, I can reach b-b-b-b" 

Not clear what you did for this.  Did the Head Office FGT have dual WAN links? 

And what did you mean by policy-based routing?  PBR?  

Can you provide the FGT config with such a configuration?  Or you copy and paste it here?

3) "execute ping b-b-b-b"

Is b-b-b-b an IP or a hostname? 

Do you have VDOM enabled?  If yes, where did you run this command?

Can you run this command "exe ping 8.8.8.8" and get any response?

Can you run "exe ping h-h-h-h" from the Branch Office FW and get any response?

4) Before you first saw this issue, did you make any changes to Head Office FGT, such as adding new configurations?

5) If b-b-b-b is an IP, please run the following commands on Head Office FGT:

diag debug flow show iprope enable

diag debug flow filter addr b-b-b-b

diag debug flow filter proto 1

diag debug flow trace start 10

diag debug enable

Then run Ping.  Please do not run the continuous Ping.

[kaman · Accepted solution]

Hi Rohitchoudhary1978

Ensure that the IPsec configuration on both the head office and branch office firewalls is correct and matches. Pay special attention to the phase 1 and phase 2 settings, including encryption, authentication, and network subnets

Check for any overlapping subnets between the head office and branch office configurations. Overlapping subnets can cause routing issues and prevent the VPN tunnel from establishing

Since policy-based routing allows reachability but breaks the VPN, review the routing table to ensure that the correct routes are in place for the VPN traffic.

Ensure that the default route or specific routes for the branch office are correctly configured on the head office firewall.

Use traceroute to determine where the connectivity issue occurs.

[dingjerry_FTNT · Accepted solution]

Hi @rohitchoudhary1978 ,

1) "This issue began after we deleted and reconfigured the IP Sec VPN on the Head Office firewall."

Any reason why you deleted and reconfigured the IPSec VPN on the Head Office?

Did you delete the IPSec VPN configuration, then copy from the backup FGT config to reconfigure it again?  Or how did you do it?  Did you make any changes?

2) "If I set up policy-based routing from the Head Office, I can reach b-b-b-b" 

Not clear what you did for this.  Did the Head Office FGT have dual WAN links? 

And what did you mean by policy-based routing?  PBR?  

Can you provide the FGT config with such a configuration?  Or you copy and paste it here?

3) "execute ping b-b-b-b"

Is b-b-b-b an IP or a hostname? 

Do you have VDOM enabled?  If yes, where did you run this command?

Can you run this command "exe ping 8.8.8.8" and get any response?

Can you run "exe ping h-h-h-h" from the Branch Office FW and get any response?

4) Before you first saw this issue, did you make any changes to Head Office FGT, such as adding new configurations?

5) If b-b-b-b is an IP, please run the following commands on Head Office FGT:

diag debug flow show iprope enable

diag debug flow filter addr b-b-b-b

diag debug flow filter proto 1

diag debug flow trace start 10

diag debug enable

Then run Ping.  Please do not run the continuous Ping.

[kaman · Accepted solution]

Hi Rohitchoudhary1978

Ensure that the IPsec configuration on both the head office and branch office firewalls is correct and matches. Pay special attention to the phase 1 and phase 2 settings, including encryption, authentication, and network subnets

Check for any overlapping subnets between the head office and branch office configurations. Overlapping subnets can cause routing issues and prevent the VPN tunnel from establishing

Since policy-based routing allows reachability but breaks the VPN, review the routing table to ensure that the correct routes are in place for the VPN traffic.

Ensure that the default route or specific routes for the branch office are correctly configured on the head office firewall.

Use traceroute to determine where the connectivity issue occurs.

[rohitchoudhary1978]

Hi, Thanks Team. I had found that a blackhole static route was created by the automated ipsec tunnel creation earlier, and due to that only the b.b.b.b was not reachable and it works after deletion. Thanks

a lot.

[ede_pfau · Accepted solution]

Before I read your last post about the bh route, I was thinking "routing issue".

Black hole routes are indeed a very useful tool in combination with IPsec VPNs, and Fortinet adopted this "best practise" only after many years (i.e., included this step in the VPN wizard).

But, bh routes - set up correctly - NEVER interfere with regular traffic.

The correct setup would be to set the bh routes' metric to 254. In other words, it will only be followed if there is no other route at all. 254 is the worst metric configurable (by the way, do NOT use 255! which will invalidate the metric completely).

As your original post unfortunately lacks crucial information, for instance the routing table ("get router info routing all"), we can only speculate what was happening. My guess is that "0.0.0.0" was inserted as the bh route, and that would never work correctly. Who knows.

If you want to learn more about bh routes and their usage just let me know. You should indeed recreate one to help your VPN recover faster from interruptions.