FortiOS 5.4 Online Help Link FortiOS 5.2 Online Help Link FortiOS 5.0 Online Help Link FortiOS 4.3 Online Help Link

Home > Online Help

> Chapter 15 - IPsec VPN > Gateway-to-gateway configurations > Testing

Testing

The best testing is to look at the packets both as the VPN tunnel is negotiated, and when the tunnel is up.

Determining what the other end of the VPN tunnel is proposing
  1. Start a terminal program such as PuTTY and set it to log all output.
    When necessary refer to the logs to locate information when output is verbose.
  2. Logon to the FortiGate unit using a super_admin account.
  3. Enter the following CLI commands.
  4. Display all the possible IKE error types and the number of times they have occurred:

 

diag vpn ike errors

 

  1. Check for existing debug sessions:

 

diag debug info

 

If a debug session is running, to halt it enter:

diag debug disable

 

  1. Confirm your proposal settings:

 

diag vpn ike config list

 

  1. If your proposal settings do not match what you expect, make a change to it and save it to force an update in memory. If that fixes the problem, stop here.
  2. List the current vpn filter:

 

diag vpn ike filter

 

  1. If all fields are set to any, there are no filters set and all VPN IKE packets will be displayed in the debug output. If your system has only a few VPNs, skip setting the filter.
    If your system has many VPN connections this will result in very verbose output and make it very difficult to locate the correct connection attempt.
  1. Set the VPN filter to display only information from the destination IP address for example 10.10.10.10:

 

diag vpn ike log-filter dst-addr4 10.10.10.10

 

To add more filter options, enter them one per line as above. Other filter options are:

clear erase the current filter
dst-addr6 the IPv6 destination address range to filter by
dst-port the destination port range to filter by
interface interface that IKE connection is negotiated over
list display the current filter
name the phase1 name to filter by
negate negate the specified filter parameter
src-addr4 the IPv4 source address range to filter by
src-addr6 the IPv6 source address range to filter by
src-port the source port range to filter by
vd index of virtual domain. 0 matches all
  1. Start debugging:

 

diag debug app ike 255

diag debug enable

 

  1. Have the remote end attempt a VPN connection.
    If the remote end attempts the connection they become the initiator. This situation makes it easier to debug VPN tunnels because then you have the remote information and all of your local information. by initiate the connection, you will not see the other end’s information.
  2. If possible go to the web-based manager on your FortiGate unit, go to the VPN monitor and try to bring the tunnel up.
  3. Stop the debug output:

 

diag debug disable

 

  1. Go back through the output to determine what proposal information the initiator is using, and how it is different from your VPN P1 proposal settings.

Things to look for in the debug output of attempted VPN connections are shown below.

Important terms to look for in VPN debug output
initiator Starts the VPN attempt, in the above procedure that is the remote end
responder Answers the initiator’s request
local ID In aggressive mode, this is not encrypted
error no SA
proposal chosen
There was no proposal match — there was no encryption-authentication pair in common, usually occurs after a long list of proposal attempts
R U THERE and
R U THERE ack
dead peer detection (dpd), also known as dead gateway detection — after three failed attempts to contact the remote end it will be declared dead, no farther attempts will be made to contact it
negotiation
result
lists the proposal settings that were agreed on
SA_life_soft and SA_life_hard negotiating a new key, and the key life
R U THERE If you see this, it means Phase 1 was successful
tunnel up the negotiation was successful, the VPN tunnel is operational