Fortinet 60D VPN connectivity issue.

[TheFivePoints]

Good day folks, I have a good one for you all.

We have recently instated a VPN with a provider of services. In short, the VPN works, however the connection is unreliable. Ping tests between the two have been sporadic at best, on average 20 - 30% packet loss. That and other connections, RPC, SSH, Telnet, RDP fail and when they do connect, timeout very quickly. I contacted our ISP to test and see if there is anything on the WAN side, but that came up clean. I just want to run down the configuration of the VPN connection to be 100% sure that it is indeed not the config nor the Fortinet causing the issue.

The Fortinet 60D has the latest update, I used the VPN wizard, and converted it to custom, and punched in the necessary Phase 1 and 2 entries. Here is where it got a bit tricky;

We have one encryption domain, 192.168.228.0/24. HOWEVER 228.0/24 had to be mip'd to 12.0/24 (factual internal range). Of course we know that you create a VIP range external 192.168.228.0/24 to 192.168.12.0/24 internal. Then create a IPpool for the one-to-one of 192.168.228.0/24.

That said, I have the source encryption domains IP pointing to the VIP range (192.168.228.0/24 to 192.168.12.0/24), any service, NAT enabled for the incoming policy.

As for the outgoing policy, I have the local subnet 192.168.12.0/24 pointed to their encryption domains, any service, NAT enabled and using the dynamic IPpool for the one-to-one addressing of 192.168.228.0/24.

My question is, could there be an issue with the way I have the VPN routed within the Fortinet back to their network? Have I missed something, as far as configuration is concerned? After some long conversation between their net admin and I, we are both at a impasse as to why the connection is so unstable.

Any input or suggestions would be very much appreciated!

[ede_pfau]

Quite hard to tell without any stats on the WAN line itself.

What you could do IMHO:

1- test/document the line reliability. Put iperf on both sides, open up a port on the WAN side and directly access the iperf server. Collect stats with ICMP and TCP traffic. iperf may not be the smartest choice for statistics but it's easy to set up, has a client and a server side and allows for different protocols. Another tool is PingPlotter which accumulates ping RTT nicely but cannot use TCP or UDP.

2- IPsec VPN is - by design - very picky about packet loss. If the line itself shows some inevitable packet loss you may get better results with SSL VPN. Only that there is no such thing like site-to-site over SSL VPN. But you may try it out host-to-host just to see if it copes better with lost packets.

[TheFivePoints]

Thanks for the input Ede. We did rule out WAN side ISP issues, everything else not VPN pings fine.

After some more long tech sessions between us and them, they have disabled the replay attack function on their Check Point system. The pings have gotten better, however something was brought up and I think it may be the root cause. They have their end set to site to site. Should it not be gateway to gateway?

I haven't found anything yet that suggest that the Fortinet by default, uses site to site. I am wondering if this may be the problem. Is there a way for me to check setting this within the Fortinet's GUI or CLI, if by using a custom VPN configuration, it is indeed gateway to gateway or site to site?

Thanks again.

[ede_pfau · Accepted solution]

hmm, for me "gw to gw" and "site to site" is the same, namely a VPN which connects networks (in contrast to hosts). The only other topology would be 'dial-in' which means host to site.

As long as you've got your networks correctly specified in phase2 (quick mode settings) there should be no issues.

As to Replay detection, this may be vendor-dependent. Try without. Same for "dead gateway detection" which uses hello packets which sometimes the other side/vendor equipment doesn't understand correctly.

[TheFivePoints]

After they disabled Replay detection, and I disabled dead peer detection, the connection has become acceptably stable, and has been for three days now.

Thanks Ede once again for the insight.