Tag Archives: VPN Connectivity

The resulting benefits of a VPN can, depending on the VPN protocol used, be supplemented by encryption that enables tap-proof and manipulation-proof communication between the VPN partners.

Maximum Transmission Unit (MTU) Check using Ping Packet

Home
Leave a comment

Use Ping to determine MTU Packet size

Use ping to determine MTU packet size. The Maximum Transmission Unit that a router allows without packet fragmentation. The Maximum Transmission Unit describes the maximum packet size of a protocol in the network layer of the OSI model, which can be transmitted in networks without fragmenting the frames in the data link layer. This packet size fits into the payload of the data link layer protocol.

How to check optimal MTU size for Routers

To check the MTU of a path, you have to pass the parameter -f to ping to set the “don’t fragment bit (DF-Bit-Set)” for the ICMP test packet in the IPv4 header, only then you will receive a message if the MTU is exceeded.

The ICMP Packet and MTU size

ICMP Packet and Maximum Transmission Unit (MTU) size

MTU check using ICMP ping packet

Run ICMP Ping in the Windows command prompt to determine the MTU size of a desired path.

The parameter -f specifies that the packages are not fragmented.
The size of the send buffer is specified with -l.

C:\> ping -4 -f 1.1.1.1 -l 1473

Pinging 1.1.1.1 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

As the above results show, the packets should be fragmented. If the -f parameter were omitted, the ping would respond with fragmentation, which we don’t want.

If you don’t get an reply but see “Packet needs to be fragmented but DF set.” you’ve not found the maximum ping size.

  Hint. It is best to gradually reduce the ping with the MTU value, in steps of 10+/-10 (e.g. 1472, 1462, 1440, 1400) until a packet size has been reached that is no longer fragmented and a response is received.

C:\> ping -4 -f 1.1.1.1 -l 1472

Pinging 1.1.1.1 with 1472 bytes of data:
Reply from 1.1.1.1: bytes=1472 time=7ms TTL=56
Reply from 1.1.1.1: bytes=1472 time=7ms TTL=56
Reply from 1.1.1.1: bytes=1472 time=7ms TTL=56
Reply from 1.1.1.1: bytes=1472 time=7ms TTL=56

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 7ms, Maximum = 7ms, Average = 7ms

The above results indicate that the packets will not be fragmented.

To get the right MTU size, take 1472 and add 28 to it. In the example above, 1472 is the correct value, and the size is 1500 for the network in which you work.

  Calculation: 8 bytes for the ICMP-header + 20 bytes for the IP-header + 1472 bytes for the ICMP-payload:  8 + 20 + 1472 = 1500

The Control Message Protocol Protocol (ICMP) in layer 3 of the network layer, which is used by ping to send a message via the ICMP payload, which is encapsulated with the IP header. The MTU cannot exceed the size of the ICMP packet of 1500 bytes.

ICMP packet at Network layer

IP headerICMP headerICMP payload sizeMTU (1500)
20 bytes8 bytes1472 bytes
(maximum)		20 + 8 + 1472 = 1500
Ethernet
header		IP headerICMP headerICMP payload size  MTU (1514)
1420 bytes8 bytes1472 bytes
(maximum)		14 + 20 + 8 + 1472 = 1514

Note. default size of ICMP payload is 32 bytes and the maximum is 1472, if the size of the payload packet is greater than 1472 then packet gets fragmented into small packets.

ICMP Message Packet decoding in Wireshark

The ICMP packet sent by the source machine is an echo request. The figure shows that ICMP query code 8 responds to the ping request.

Using Linux Ping set don’t fragment bit (DF-Bit-Set) in the Linux Shell and macOS Terminal

Linuxping -M do -s 1472 1.1.1.1
macOSping -D -s 1472 1.1.1.1
Linux Ping DF-Flag to set don’t fragment (DF)

Use Linux ping in a terminal will using DF-bit-set do not fragment message.

$ ping -M do -s 1473 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
^C
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 31ms

Typical MTU sizes

MediumMTU in Bytes
Ethernet1500
PPPoE1492
VPN encapsulated1420
ATM4500

Credential or ssl vpn configuration is wrong

Home
2 Comments

FortiClient Error: Credential or ssl vpn configuration is wrong (-7200)

When trying to start an SSL VPN connection on a Windows 10, Windows Server 2016 or 2019 with the FortiClient, it may be that the error message “Credential or ssl vpn configuration is wrong (-7200)” appears. The reason to drop connection to the endpoint during initializing caused by the encryption, which can be found in the settings of the Internet options.

Another symptom can be determined, the SSL-VPN connection and authentication are successfully established, but remote devices cannot be reached, and ICMP replies are also missing and result in a timeout.

How to solve ssl vpn failure

According to Fortinet support, the settings are taken from the Internet options. The Internet Options of the Control Panel can be opened via Internet Explorer (IE), or by calling inetcpl.cpl directly.

Press the Win+R keys enter inetcpl.cpl and click OK.

Select the Advanced tab

Click the Reset… button. If the Reset Internet Explorer settings button does not appear, go to the next step.

Click the Delete personal settings option

Click Reset

Open Internet Options again.

Go back to Advanced tab

Disable use TLS 1.0 (no longer supported)

Add website to Trusted sites

Add the SSL-VPN gateway URL to the Trusted sites. Usually, the SSL VPN gateway is the FortiGate on the endpoint side.

Go to the Security tab in Internet Options and choose Trusted sites then click the button Sites. Insert the SSL-VPN gateway URL into Add this website to the zone and click Add, here like https://sslvpn_gateway:10443 as placeholder.

Note: The default Fortinet certificate for SSL VPN was used here, but using a validated certificate won’t make a difference.

Furthermore, the SSL state must be reset, go to tab Content under Certificates. Click the Clear SSL state button.

The SSL VPN connection should now be possible with the FortiClient version 6 or later, on Windows Server 2016 or later, also on Windows 10.

Don’t get success yet ?

If you haven’t had any success up to this point, don’t despair now, there is more help available, may the following is the case!

If you may use an FortiClient 7 on Windows 10 or Windows 11, then create a new local user on the FortiGate and add it to the SSL-VPN group.

Add the user to the SSLVPN group assigned in the SSL VPN settings.

Try to verify the credentails using the web mode, for this in SSL-VPN Portals the Web Mode must my enabled.

Note that the group with the affected user is assigned under SSL-VPN Settings at Authentication/Portal Mapping.

Try to authenticate the vpn connection with this user.

It worked here with this attempt, but I haven’t yet been able to successfully carry out the authentication via LDAP server,

If your attempt was more successful and you know more ? please let us know and post your comment!

Issue using FortiClient on Windows 11

FortiClient SSL-VPN connects successfully on Windows 10 but not on Windows 11. An article by the staff was posted in the fortinet community they describes a potential cause for why SSL-VPN connections may fail on Windows 11 yet work correctly on Windows 10.

  SSL-VPN tunnel-mode connections via FortiClient fail at 48% on Windows 11, it appears: Credential or SSLVPN configuration is wrong (-7200). We remember, tunnel-mode connections was working fine on Windows 10.

Users are unable to authenticate if they are in a User Group that is configured in an SSL-VPN Authentication/Portal Mapping (also known authentication-rule in the CLI), but they can successfully authenticate when using the All Other Users/Groups catch-all authentication rule.

Windows 11 is uses TLS 1.3 by default for outbound TLS connections, whereas Windows 10 appears to use TLS 1.2 by default.

If TLS-AES-256-GCM-SHA384 is removed from the list, Windows 11/FortiClient will still be able to establish a TLS 1.3 connection using one of the alternative TLS Cipher Suites available. This will appear as a successful TLS connection in a packet capture tool such as Wireshark.

Windows 11 may be unable to connect to the SSL-VPN if the ciphersuite setting on the FortiGate has been modified to remove TLS-AES-256-GCM-SHA384, and an SSL-VPN authentication-rule has been created for a given User Group that has the cipher setting set to high (which it is by default).

The solution can be found with the following command using in the FortiGate CLI should solve the issue:

config vpn ssl settings
  unset ciphersuite
end

or possibly with the next command:

config vpn ssl settings
  append ciphersuite TLS-AES-256-GCM-SHA384
end

Note see Microsoft learn about TLS Cipher Suites in Windows 11