VPN - Unable to Ping Remote Gateway IP once VPN is established

[CliffPaj]

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

[Toshi_Esumi]

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.

[CliffPaj]

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

[ede_pfau]

Does the remote IP address fall into the phase2 Quick Mode selectors?

[CliffPaj]

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

[Toshi_Esumi]

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?

[CliffPaj]

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

[Toshi_Esumi]

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

[CliffPaj]

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

[CliffPaj]

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