VPN troubleshooting tips

VPN troubleshooting tips

More in-depth VPN troubleshooting can be found in the Troubleshooting guide.

Attempting hardware offloading beyond SHA1

If you are trying to off-load VPN processing to a network processing unit (NPU), remember that only SHA1 authentication is supported. For high levels of authentication such as SHA256, SHA384, and SHA512 hardware offloading is not an option — all VPN processing must be done in software.

Enable/disable IPsec ASIC-offloading

Much like NPU-offload in IKE phase1 configuration, you can enable or disable the usage of ASIC hardware for IPsec Diffie-Hellman key exchange and IPsec ESP traffic. By default hardware offloading is used. For debugging purposes, sometimes it is best for all the traffic to be processed by software.

config sys global

set ipsec-asic-offload [enable | disable]

end

Check Phase 1 proposal settings

Ensure that both sides have at least one Phase 1 proposal in common. Otherwise they will not connect. If there are many proposals in the list, this will slow down the negotiating of Phase 1. If its too slow, the connection may timeout before completing. If this happens, try removing some of the unused proposals.

NPU offloading is supported when the local gateway is a loopback interface.

Check your routing

If routing is not properly configured with an entry for the remote end of the VPN tunnel, traffic will not flow properly. You may need static routes on both ends of the tunnel. If routing is the problem, the proposal will likely setup properly but no traffic will flow.

Try enabling XAuth

If one end of an attempted VPN tunnel is using XAuth and the other end is not, the connection attempt will fail. The log messages for the attempted connection will not mention XAuth is the reason, but when connections are failing it is a good idea to ensure both ends have the same XAuth settings. If you do not know the other end’s settings enable or disable XAuth on your end to see if that is the problem.

General troubleshooting tips

Most connection failures are due to a configuration mismatch between the FortiGate unit and the remote peer. In general, begin troubleshooting an IPsec VPN connection failure as follows:

1. Ping the remote network or client to verify whether the connection is up. See General troubleshooting tips on page 1831.

2. Traceroute the remote network or client. If DNS is working, you can use domain names. Otherwise use IP addresses.

3. Check the routing behind the dialup client. Routing problems may be affecting DHCP. If this appears to be the case, configure a DHCP relay service to enable DHCP requests to be relayed to a DHCP server on or behind the FortiGate server.

4. Verify the configuration of the FortiGate unit and the remote peer. Check the following IPsec parameters:

• The mode setting for ID protection (main or aggressive) on both VPN peers must be identical.
• The authentication method (preshared keys or certificates) used by the client must be supported on the FortiGate unit and configured properly.
• If preshared keys are being used for authentication purposes, both VPN peers must have identical preshared keys.
• The remote client must have at least one set of Phase 1 encryption, authentication, and Diffie-Hellman settings that match corresponding settings on the FortiGate unit.
• Both VPN peers must have the same NAT traversal setting (enabled or disabled).
• The remote client must have at least one set of Phase 2 encryption and authentication algorithm settings that match the corresponding settings on the FortiGate unit.
• If you are using manual keys to establish a tunnel, the Remote SPI setting on the FortiGate unit must be identical to the Local SPI setting on the remote peer, and vise versa.

5. To correct the problem, see the following table.

VPN trouble-shooting tips

Configuration problem           Correction

Mode settings do not match.

Select complementary mode settings. See Phase 1 parameters on page 1624.

Peer ID or certificate name of the remote peer or dia- lup client is not recognized by FortiGate VPN server.

Check Phase 1 configuration. Depending on the Remote Gateway and Authentication Method settings, you have a choice of options to authen- ticate FortiGate dialup clients or VPN peers by ID or certificate name (see Phase 1 parameters on page 1624).

If you are configuring authentication parameters for FortiClient dialup cli- ents, refer to the Authenticating FortiClient Dialup Clients Technical Note.
Preshared keys do not match.

Reenter the preshared key. See Phase 1 parameters on page 1624.

Phase 1 or Phase 2 key exchange proposals are mismatched.

Make sure that both VPN peers have at least one set of proposals in com- mon for each phase. See Phase 1 parameters on page 1624 and Phase 2 parameters on page 1642.
NAT traversal settings are mismatched.

Select or clear both options as required. See Phase 1 parameters on page 1624 and Phase 1 parameters on page 1624.

A word about NAT devices

When a device with NAT capabilities is located between two VPN peers or a VPN peer and a dialup client, that device must be NAT traversal (NAT-T) compatible for encrypted traffic to pass through the NAT device. For more information, see Phase 1 parameters on page 1624.