4/30/2023 0 Comments Site to site vpn fortigate![]() ![]() With 7.0 the route for a tunnel needs to be identified by the tunnel id (in this case 10.0.0.17). You can see the difference pretty clearly in the routing table (get router info routing-table database) of the hubs with 7.0: S 172.16.190.0/24 via s2s_dialup tunnel 10.0.0.17 (Consequently, the tunnel search option in phase1 is removed, because tunnels are now clearly identified by the tunnel ID and referenced in the routing table.) ![]() Routes are linked to the tunnels by the tunnel IDs, replacing the need to have a route tree in the IPsec tunnel list for selecting tunnels by next hop when net-device is disabled. As described in the New Features Guide there is a new dedicated tunnel IDs that identifies each tunnel. S *> 172.16.190.0/24 is directly connected, s2s-hub_2īut with 7.0.1 we have a change in the behavior. ![]() In 6.4 this hasn’t been a problem because the static route is just “overwriting” the dynamically created route (get router info routing-table database): S 172.16.190.0/24 via 203.0.113.190, s2s-hub_2 One through the phase1 setting “set add-route enable” (with distance 15) and the other one through the explicit configured static route (with distance 10). With this configuration we are creating two static routes for the dialup VPN. Set distance 10 (default setting, not visible with "show") Set distance 15 (default setting, not visible with "show") Set add-route enable (default setting, not visible with "show") Traffic from spoke is routed into the tunnel, but is seems that the traffic is not received by the hub.Ĭonfig-Snippets: config vpn ipsec phase1-interface ![]() Tunnel negotiation is successful and phase 1 and 2 get up. After Fortigate upgrade v6.4 > v7.0.1 (or later) the S2S-dialup VPNs did not work anymore. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |