Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
DG
New Contributor

[FortiOS 7.0] - Gateway IP in static routes for vpn tunnel interface

Hello,

  in the static routes page, the Gateway IP shown for an ip sec vpn tunnel internface is the public ip of the remote endpoint. FortiOS 6 shows the private ip of the remote endpoint. Personally I think the public ip shown in the routing table as the next hop for a private subnet is misleading:

 

Does anyone know if it's working as intended or it's a graphical bug and I should report it?

 

Thank you

6 REPLIES 6
Kangming
Staff
Staff

Hi DG, 

 

On the FOS7.0 platform, tunnel id is used for a new IPsec kernel implementation.

 

An IPsec tunnel has a tunnel id. Normally this is the remote gateway of the tunnel. For tunnels with the same remote gateway, the tunnel id will be randomly assigned and will be different from the remote gateway. The tunnel id is printed in "diagnose vpn tunnel list".

 

A route also has a tunnel id. The tunnel id in a route coincides with the gateway of the route. That means when a route directs traffic to an IPsec interface.

 

It should be noted that the next-hop of the route of the VIT IPsec VPN tunnel is only a tunnel-ID identifier, not the real route next-hop IP, which is different from our ordinary route next hop. 

 

Therefore, the VPN route we see in the latest V7.0.1 is like this:

S 10.61.0.0/16 [10/0] via t1 tunnel 63.1.1.1, [51/0] B 211.211.211.211/32 [200/0] via 10.1.14.1 (recursive via 64.1.1.1, v3164), 00:15:19 [200/0] via 10.1.63.254 (recursive via t1 tunnel 63.1.1.1), 00:15:19 [200/0] via 10.1.79.254 (recursive via t2 tunnel 64.1.1.1), 00:15:19 S 2261::61/128 [15/0] via to626 tunnel 10.0.0.11, 00:01:10, [1024/0] B 2061::/64 [200/0] via fd01:4::1 (recursive via ts62 tunnel 10.0.0.7), 00:11:14

 

Replace the original IP address with tunnel x.x.x.x, so in order to avoid confusion, Although it is still easy to misunderstand because it is different from before, we will make relevant documentation later, in order to help everyone become familiar with and get used to this way of working.

 

Thank you

Thanks

Kangming

Kangming

Hi DG, 

 

We have added some documents to analyze this change:

https://docs.fortinet.com/document/fortigate/7.0.0/new-features/649094/dedicated-tunnel-id-for-ipsec...

 

Thanks

Kangming

TonyLa

Hey Kangming,

 

I'd just like to point out how very confusing this can become.  I have a VPN tunnel with a vendor whom just migrated to a new ip address.  We've made all the changes and the Tunnel is up both P1 and P2.  However, when I add the route for the new interesting traffic address the "gateway" still shows up as the old address for their tunnel gateway.

 

TonyLa_0-1661962451747.png

 

I can see in the routing table...

 

 

"S 174.xxx.yyy.zzz/32 [10/0] via VPN_ISP1 tunnel 76.79.ccc.ddd"

 

I understand that the "gateway" is not actually the gateway for the route.  The next hop is "VPN_ISP1" and the reference to 76.79.ccc.ddd is the tunnel id and it should be working fine, however, when troubleshooting a connection it is very confusing.  Also, convincing another engineer not familiar with Fortigate that nothing is amiss is difficult.

 

Is there any way to edit the tun_id entry for a tunnel?  Or change the GUI so it doesn't say "gateway" if it's not the actual gateway but instead the tunnel ID?

 

Thank you.

jdoyon
New Contributor II

Seconded. You edit the IP on a tunnel, and the Gateway still shows the OLD IP. Very confusing. This is at the very least a GUI bug, as it is lying to the user. Displayed IP is NOT the gateway.

Manager, IT Operations and Security
Manager, IT Operations and Security
gallo_loco

This seems to go against conventions we've understood for years. Not very intuitive, and different than other vendors. Definitely creates problems if I have multiple tunnels to the same gateway. Is there a reason why Fortinet chose this route? No pun intended.

anikolov

Hello TonyLa,

 

Yes, the IP is misleading. I have tested this issue in lab before, only thing that has helped was to recreate the vpn tunnel from start or reboot the device, it seems like a bug which has not yet been reported.

 

Regards,

Aleksandar Nikolov
Labels
Top Kudoed Authors