Under the appropriate interface with the appropriate IP address, here change the key MTU with the value 578 hexadecimal.Īfter restarting the computer, the SSL-VPN connection can be established. netsh interface ip4 set subinterface Ethernet mtu=1400 store=persistentĪlternatively, call Regedit and navigate to the following key. In a command prompt opened as an administrator, with running netsh. MTU Medienerkennungsstatus Bytes eingehend Bytes ausgehend Schnittstelleġ500 1 0 134436 VMware Network Adapter VMnet8Ĥ294967295 1 0 67869 Loopback Pseudo-Interface 1Ĭheck the MTU size and adjust to 1400 if necessary. The output might look something like this: C:\> netsh interface ipv4 show subinterface To do this, check the MTU size of the network interfaces with the following command from an open command prompt netsh interface ipv4 show subinterface It appears the FortiClient error message:
#FORTINET VPN SETUP 5.0 WINDOWS#
With older Windows versions, or with routers with PPPoE Internet connection, errors when establishing SSL-VPN connections can be eliminated as follows.
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.In the opened Internet Options window Internet Properties click to Advanced tab and click Use TLS Version 1.0 to enable it. I just noticed another difference (marked in orange):
Ike 0: IKEv1 exchange=Identity Protection id=a2611a8be1a0c76f/3855a1dd911dc2e5 len=1324 ike 0:CP-FC:485: responder: main mode get 3rd message. Ike 0:CP-FC:485: responder:main mode get 2nd message. The second attempt works and then the logs are different in one point. 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 ike 0:CP-FC: unable to build CERTREQ for client02 ike 0:CP-FC: building CERTREQ for peer client02 ike 0:CP-FC: unable to build CERTREQ for client01
ike 0:CP-FC: building CERTREQ for peer client01 Ike 0:CP-FC:484: responder:main mode get 2nd message. Here the logs, the yellow lines looks suspicious We are using client certificates with peer groups for authentication reasons Using main or aggressive mode or enabling IKE fragmentation on the client config makes no difference. Rich really errors, the fortigate tries to send P1 response but fails. The problem seems worse with the DHCP profiles, but does occur with the others as well. We have deployed several different VPN profiles - some used mode config and other use DHCP over ipsec. 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." I can immediately connect on the second try. " 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. Our user community's patience in dealing with this inconvenience is fading. If you then disconnect, most often the second an subsequent attempts succeed. Our Fortigate VPN server is current 5.0.9.įrequently, the first (at least) to establish a VPN connects hangs when connecting.
This affects various versions from 5.0.7 through 5.2.1 (at least).
0 kommentar(er)
