Passing FortiClient IPSec through a Fortigate fails

[Ziegenpeter]

Hello All,

I have been given a laptop by one of our clients which connects to the client's company LAN through an IPSec VPN. That IPSec VPN runs on a Fortinet solution (FortiClient on the laptop and a Fortigate device on the client's premises).

However, I have trouble getting a VPN connection through our own Fortigate which sits between our own LAN and the internet. This is a Fortigate 50E running 6.2.10. The laptop is connected to a completely open guest network with all services including IKE and NAT-T passed through and no filtering, scanning or any security services provisioned.

When trying to connect to the client's VPN, the connection fails at the phase 1 handshake with the following error:

"No response from the peer, phase1 retransmit reaches maximum count"

However, the client's VPN gateway is reachable via ping, and I can establish a connection when using a WiFi hotspot from my cell phone.

Other IPSec VPNs we use for other clients connect just fine through the same network and Fortigate, so I have no idea what's causing this. The firewall logs also show no blocked traffic.

Any idea what might be causing this? Could this be because of too aggressive settings in the VPN profile?

[ConnyGustavsson]

Hi. That company's IPSec setting may miss "nat traversal" configuration? Then you can not be behind a NAT:ed firewall. More unlikely you have some config in your fw that blocks IPSec. Check with packet capture on outside interface if you get response. 

[Ziegenpeter]

Hi! Thanks for the reply.

NAT-T should be configured as the client's own workers use the same VPN and for most of them it works even through cheap home broadband routers which mostly are behind NAT. 

I did a package capture on the WAN side while trying to establish a VPN connection, and it seems the IPSec traffic goes through just fine:

No Time Source IP Dest IP Protocol Length SrcPort DestPort
434 2022-03-24 15:51:26.592634 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB ISAKMP 550 500 500
435 2022-03-24 15:51:26.618459 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA ISAKMP 491 500 500
437 2022-03-24 15:51:26.648424 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
438 2022-03-24 15:51:26.648435 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
439 2022-03-24 15:51:26.648441 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB ISAKMP 230 4500 4500
443 2022-03-24 15:51:26.690696 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA IPv4 886
828 2022-03-24 15:51:29.161519 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
829 2022-03-24 15:51:29.161528 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
830 2022-03-24 15:51:29.161533 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB ISAKMP 230 4500 4500
831 2022-03-24 15:51:29.191518 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA IPv4 886
891 2022-03-24 15:51:29.876761 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA ESP 186 4500 4500
1152 2022-03-24 15:51:32.168041 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
1153 2022-03-24 15:51:32.168050 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
1154 2022-03-24 15:51:32.168055 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB ISAKMP 230 4500 4500
1155 2022-03-24 15:51:32.196343 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA IPv4 886
1264 2022-03-24 15:51:33.972541 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA ESP 186 4500 4500
1342 2022-03-24 15:51:35.184579 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
1343 2022-03-24 15:51:35.184587 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
1344 2022-03-24 15:51:35.184593 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB ISAKMP 230 4500 4500
1345 2022-03-24 15:51:35.212873 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA IPv4 886
1964 2022-03-24 15:51:38.186001 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
1965 2022-03-24 15:51:38.186010 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
1966 2022-03-24 15:51:38.186017 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB ISAKMP 230 4500 4500
1968 2022-03-24 15:51:38.214209 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA IPv4 886
2187 2022-03-24 15:51:41.204099 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
2188 2022-03-24 15:51:41.204108 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB IPv4 1514
2189 2022-03-24 15:51:41.204114 AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB ISAKMP 230 4500 4500
2190 2022-03-24 15:51:41.232770 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA IPv4 886
3601 2022-03-24 15:51:49.653294 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA ESP 138 4500 4500
3720 2022-03-24 15:51:50.080558 BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA ESP 378 4500 4500

(AAA.AAA.AAA.AAA is the WAN IP of my Fortigate, BBB.BBB.BBB.BBB is the IP of the client's Fortigate the VPN should connects to)

From what I can see (not being a network engineer) there is nothing in my Fortigate to stop the VPN traffic. So I have no idea what could cause the phase1 handshake to fail (time out).

[sw2090]

hm he wrote that it worked using a hotspot. Hotspot usually does NAT too so I guess there is NAT-T .

If there is no repsonse from peer it would be interesting which side did not respond.

Maybe there is no answer from the FortiGate due to some reason.

Then looking at the ike debug log on the FGT might give some clue.

That e.g. might happen when psk auth fails or if the vpn dos not have any policy referencing to it on the fortigate.

On Client side you see the "no response from peer" as there is no more response from the peer then.

Anyways FortiClient is always good for trouble ;)

Do you use the VPN only one or the "full" FortiClient?

[Ziegenpeter]

The strange thing is that the VPN end point (the client's Fortigate) is responding (I can ping it reliably, and the data capture above shows that it's responding to the VPN connection request from the client laptop). It's just that something in the phase1 handshake appears to go wrong. 

The FortiClient on the laptop seems to be the full version ("About" says FortiClient 6.4.7.1713, and it says it's connected to EMS).

Our client's IT department is more reactive than pro-active and says because it works for others that the problem must be on my end, and that's it. They might be prepared to adjust some settings if I tell them which ones. 

My hope was that someone had an idea what could be causing this, and maybe there is a setting that could cause a phase1 handshake fail (considering that the profile itself seems to be working).

[sw2090]

well ping uses a different protocol (icmp echo) then vpn (ipsec).

Could you request the IT-Dept to look into the ike debug log on the endpoint to see if that reports any error?