Forticlient VPN - Hangs on "Connecting" on first attempt.

[rsmayer]

This affects various versions from 5.0.7 through 5.2.1 (at least).

Our Fortigate VPN server is current 5.0.9.

Frequently, the first (at least) to establish a VPN connects hangs when connecting.   If you then disconnect, most often the second an subsequent attempts succeed.     Our user community's patience in dealing with this inconvenience is fading.  

Here is quote from one user..  " I’ve had this recurring issue with the FCL VPN, despite all the configuration changes over time, where I cannot connect on the first try. I can immediately connect on the second try. I have tried a variety of scenarios (rebooting, not-rebooting, trying different networks, disabling IPV6 etc, disabling security services like EMET) and none of these things have any effect on the result."

We have deployed several different VPN profiles - some used mode config and other use DHCP over ipsec.   The problem seems worse with the DHCP profiles, but does occur with the others as well.   Any suggested on a possible cause?

Thanks

Rich Mayer

mayer@lgsinnovations.com

[Chris_Lin_FTNT]

It's hard to tell by only reading your description. But if you look at FortiGate debug log, it will probably show you what was going on.

[stpalme]

Same Problem here over years, kind of frustrating. From forticient 4.3 to 5.4, fortios running on the 100D 5.0x to 5.28. Setup is IPSEC VPN with certificates. Different WAN links on the fortigate, different client connection over DSL or mobile networks, no difference. According to the logfile it happens already after the first phase 1 message, Client log says "negotiate_error No response from the peer, phase1 retransmit reaches maximum count..." vpntunnel=XXX vpntype=ipsec". Second attempt works at almost 90%. 

[Chris_Lin_FTNT]

In the log files (from FortiClient and FortiGate), do you see any certificate verification failed or any other error?

[stpalme]

Not really errors, the fortigate tries to send P1 response but fails. Using main or aggressive mode or enabling IKE fragmentation on the client config makes no difference. We are using client certificates with peer groups for authentication reasons

Here the logs, the yellow lines looks suspicious

ike 0:CP-FC:484: responder:main mode get 2nd message... ike 0:CP-FC:484: NAT detected: PEER [style="background-color: #ffff00;"]ike 0:CP-FC: building CERTREQ for peer client01[/style] [style="background-color: #ffff00;"]ike 0:CP-FC: unable to build CERTREQ for client01[/style] [style="background-color: #ffff00;"]ike 0:CP-FC: building CERTREQ for peer client02[/style] [style="background-color: #ffff00;"]ike 0:CP-FC: unable to build CERTREQ for client02[/style] [style="background-color: #ffff00;"]ike 0:CP-FC: building CERTREQ for any[/style] ike 0:CP-FC:483: sent IKE msg (ident_r2send): 95.117.33.150:500->89.204.130.72:16146, len=465, id=7919776837ff80db/afef9b5650fff93e [style="background-color: #ff9900;"]ike 0: comes 89.204.130.72:16146->95.117.33.150:500,ifindex=3....[/style] ike 0: IKEv1 exchange=Identity Protection id=7919776837ff80db/afef9b5650fff93e len=356 ike 0:CP-FC:483: retransmission, re-send last message ike 0:CP-FC:483: sent IKE msg (retransmit): 95.117.33.150:500->89.204.130.72:16146, len=465, id=7919776837ff80db/afef9b5650fff93e ike 0:CP-FC:483: sent IKE msg (P1_RETRANSMIT): 95.117.33.150:500->89.204.130.72:16146, len=465, id=7919776837ff80db/afef9b5650fff93e ike 0: comes 89.204.130.72:16146->95.117.33.150:500,ifindex=3.... ike 0: IKEv1 exchange=Identity Protection id=7919776837ff80db/afef9b5650fff93e len=356 ike 0:CP-FC:483: retransmission, re-send last message ike 0:CP-FC:483: sent IKE msg (retransmit): 95.117.33.150:500->89.204.130.72:16146, len=465, id=7919776837ff80db/afef9b5650fff93e ike 0:CP-FC:483: negotiation timeout, deleting ike 0:CP-FC: connection expiring due to phase1 down ike 0:CP-FC: deleting ike 0:CP-FC: flushing ike 0:CP-FC: sending SNMP tunnel DOWN trap ike 0:CP-FC: flushed ike 0:CP-FC: reset NAT-T ike 0:CP-FC: deleted The second attempt works and then the logs are different in one point. ike 0:CP-FC:485: responder:main mode get 2nd message... ike 0:CP-FC:485: NAT detected: PEER [style="background-color: #ffff00;"]ike 0:CP-FC: sending 1 CERTREQ payload[/style] ike 0:CP-FC:485: sent IKE msg (ident_r2send): 95.117.33.150:500->89.204.130.72:14943, len=361, id=a2611a8be1a0c76f/3855a1dd911dc2e5 [style="background-color: #ff9900;"]ike 0: comes 89.204.130.72:13539->95.117.33.150:4500,ifindex=3....[/style] ike 0: IKEv1 exchange=Identity Protection id=a2611a8be1a0c76f/3855a1dd911dc2e5 len=1324 ike 0:CP-FC:485: responder: main mode get 3rd message...

I just noticed another difference (marked in orange):

In the first failed connection attempt the forticlient answers to the fortigate on port 500, on the second on 4500, which should be the correct port because of the NAT detection...

[stpalme]

I opened a support case regarding this issue. It's annoying, especially for users who are travelling and just quickly want to check their emails etc...

[jhonyspark]

The problem is that fortclient 6.0 inst compatible with your SO.  Just download an older verson of fortclient, and the problem will be solved.