Possible Bug: VPN Tunnel Name Change causes Firewall Policies to not work

[AZFortinetMember335]

I don't know if this is the correct place to post this but we found a possible bug. We had our test IPSec Dialup tunnel successfully setup and routing rules implemented. Last week our team started converting the setting from our test setup to how we want our production settings to be.

During this process the team changed the PSK, Peer ID and name of the VPN tunnel. After these changes were saved traffic no longer was being routed to the correct destination. I found that DNS queries were traveling down the tunnel and traffic was being denied. We changed everything back to the way it was during testing and there was no change to behavior. Everything was still being blocked.

Then I was reviewing the interface for the VPN tunnel and noticed that the 'Security Fabric Connection' was still checked from a previous test we were working on. I unchecked the box it okay and all traffic for the VPN tunnel started routing correctly again.

So I went back to the VPN tunnel and changed the name again. As soon as that happens the VPN tunnel drops. I connect back and traffic is again blocked. I now go to the interface for the VPN tunnel and check 'HTTPS' and click ok. Traffic immediately starts flowing again. I then uncheck 'HTTPS' and traffic still flows.

So it seems that re-naming tunnels can cause an issue with how the Firewall evaluates the traffic causing unintended routing problems. Hopefully this helps someone in the future as this was by pure luck that we found the problem.

We are currently running 7.4.8 with FortiClient 7.4.3.

[BillH_FTNT]

HI @AZFortinetMember335 

Did you change the tunnel name in Firewall ? Can you snapshot where you put "https" ? 

Thanks

Bill

[AZFortinetMember335]

Ok, so for example we start out with the Tunnel name and change it here to IPSEC-Dialup-03.

The traffic will stop adhering to Firewall policies until you go to the interface for the tunnel and make a change to the interface. I only made changes to the Administrative Access portion of the interface. I didn't test if any change would fix this. So after I go to the interface I click HTTPS and save the change. As soon as that is done traffic flows as designed. Going back into the interface and unchecking HTTPS and saving does not change the behavior after it is 'fixed'.

[ede_pfau]

Nice find, thanks for sharing.

Would you be so kind to open a support case to make FTNT aware of this bug? Apparently, an internal table (translating a name string to a tunnel ID) will only be refreshed if other changes are made.

Just copy&paste your post to the ticket, and while I do not expect FTNT to have a patch ready for this, it will trigger a bug ticket which eventually will lead to a fix in a future patch.

[AZFortinetMember335]

I submitted a ticket, thanks for verifying it wasn't just an us issue.

[BillH_FTNT]

Hi @AZFortinetMember335 

I will reproduce the issue in my lab. Could you please upload the configuration to the ticket? This will help us identify the exact version and setup, increasing the chances of reproducing the issue and finding the root cause. Thanks!

Regards

Bill

[AZFortinetMember335]

@BillH_FTNT 

Ok, uploaded the current config.

[BillH_FTNT]

Hi @AZFortinetMember335 

The issue could reproduce in my lab that when I change Tunnel name, the traffic dropped.

When I changed the tunnel name, traffic was dropped. However, once I re-established the tunnel, traffic flowed normally. Could you please test a new tunnel using a local user account like "test01"?

Update Sep 5: When you do the test, please help to collect the debug log. 

# Debug 

diag debug enable
diag debug cli 7
diag debug application ike -1

# Get vpn information.
diag vpn ike gateway list
diag vpn tunnel list

Our engineering team is investigating a similar issue. We need the log files to identify the root cause. Thank you

Bill