Hi Guys,
First of all, I am not sure if this was raise already but I just need some clarification about the routing on Route-based IPSec VPN.
The scenario was, I was building a route-based site-to-site ipsec tunnel between FortiGate and Cisco router.
I was able to bring the tunnel up, dynamic routing is working and hosts from both ends are able to reach each other.
However, I was wondering that once the VPN is established, FortiGate can no longer PING Cisco's public IP.
It seems the routing to Cisco's public address is been rerouted to the vpn tunnel interface instead of keeping it on the default route on its wan interface.
====================================
FGT# get router info routing-table details 114.8.24.6 Routing entry for 114.8.24.6/32 Known via "connected", distance 0, metric 0, best * is directly connected, vpn_tunnel2
====================================
Is there a way or a tweak to still enable the Fortigate to ping its vpn peer IP even if the VPN is established?
Thanks,
Cliff
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Are you using the tunnel interface IP on the FortiGate, not the public IP, as the peer/neighbor IP for your routing protocol? Regularly problem like this is on Cisco side's access-list because it requires an explicit deny statement not to go into the tunnel.
Hi Toshi,
Thank you for the reply.
There is no access list from Cisco side, we noticed that on all vpn tunnels we had.
Our Hub is Cisco, and all Fortigate that have vpn tunnels to it have the same results.
Unlike some our site that has Cisco to Cisco route-based (GRE/IPSec) tunnels, we can still ping both ends public IPs even if the tunnel is established.
So like my colleagues question to me is why does Fortigate put a static route to the peer's IP address pointing to the vpn tunnel once the tunnel is established.
Thanks,
Cliff
Does the remote IP address fall into the phase2 Quick Mode selectors?
Hi Ede,
How to verify that from FortiGate side? But Phase1 is set to Main Mode.
We suspect that the presence of connected route to tunnel interface is what caused the FG unable to ping the remote peer IP. Basically, remote peer IP will be reachable via default route. But since FG creates that connected route, it forces the route over to that tunnel interface instead of the default route which creates a routing issue when the vpn is established.
So correct me if I am wrong as I am not familiar with FortiGates's behavior on VPN protocols.
Thanks,
Cliff
It shouldn't if you set up a standard main mode (static) IPsec. Can you share the phase1-interface/phase2-interface config after masking IPs?
Hi Toshi,
Please find below.
config vpn ipsec phase1-interface edit "VPN_NOC" set type static set interface "wan1" set ip-version 4 set ike-version 1 set local-gw 0.0.0.0 set keylife 86400 set authmethod psk set mode main set peertype any set mode-cfg disable set proposal aes256-sha1 set exchange-interface-ip disable set localid '' set localid-type auto set negotiate-timeout 30 set fragmentation enable set dpd on-idle set forticlient-enforcement disable set comments '' set npu-offload enable set dhgrp 5 set suite-b disable set wizard-type custom set xauthtype disable set mesh-selector-type disable set idle-timeout disable set ha-sync-esp-seqno enable set auto-discovery-sender disable set auto-discovery-receiver disable set auto-discovery-forwarder disable set encapsulation none set nattraversal enable set remote-gw --omitted-- set monitor '' set add-gw-route disable set psksecret --omitted-- set keepalive 10 set auto-negotiate enable set dpd-retrycount 3 set dpd-retryinterval 5 next ! config vpn ipsec phase2-interface edit "VPN_NOC_p2" set phase1name "VPN_NOC" set proposal aes256-sha1 set pfs disable set replay enable set keepalive disable set auto-negotiate disable set auto-discovery-sender phase1 set auto-discovery-forwarder phase1 set keylife-type seconds set encapsulation transport-mode set comments '' set protocol 47 set src-port 0 set dst-port 0 set keylifeseconds 3600 next end
This config is a normal main mode (static) config, as we have everywhere. You haven't happened to configure the same public IP on Tunnel Interface "VPN-NOC" remote IP, have you? It's a tunnel interface IP on the Cisco, which is supposed to be a separate /32 IP in management/monitoring subnet. That should show up as a set of connected routes as well as the local tunnel. We just had another thread discussing about how to configure it.
https://forum.fortinet.com/tm.aspx?tree=true&m=153877&mpage=1
Hi Toshi,
Thanks for the reply.
I remove the local and remote gw IP details from the configuration.
But both are configured properly either on the tunnel interface or the ipsec phase1 & 2 interface. Like I said vpn tunnel is working fine and my only issue is I can't ping the remote gw IP once the tunnel is UP.
When FG creates the connected route of the remote gw IP, you'ré sending all your traffic to the remote gw IP via tunnel interface instead over wan1 or wan2 via default route which makes it unreachable.
I have no idea why FortiGate behaves or design in that way.
Thanks,
Clifford
Hi Toshi,
By the way, from Cisco side I can ping FG's gw IP even when tunnel is UP. It should be the same from FG's side but not in this case.
Regards,
Clifford
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1517 | |
1013 | |
749 | |
443 | |
209 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.