Skip to main content

VPN Debug

(2018-08-02)

Problem

Site to site VPN not coming up.

Solution

it depends what you would like to troubleshoot. If you like to troubleshoot the Phase1/2 of a VPN your command is the way to go which means:

diag debug reset
diag debug disable
diag debug application ike -1

The -1 means all message of debug in Phase1/2 but there are more debug levels

for specific information: Level Means
2 Shows config changes
4 Shows connections which will be established
8 Only Phase-1 as Phase-2 comunications messages
16 Shows only NAT-T (Nat-Traversal)
32 Shows only DPD
64 Shows only Encryption/Decryption Key's
128 Shows only Encryption Traffic payload

You can set as you already mentioned a filter for ike which means:

# diagnose vpn ike log-filter ?

            clear        Erase the current filter.
            dst-addr4    IPv4 destination address range to filter by.
            dst-addr6    IPv6 destination address range to filter by.
            dst-port     Destination port range to filter by.
            interface    Interface that IKE connection is negotiated over.
            list         Display the current filter.
            name         Phase1 name to filter by.
            negate       Negate the specified filter parameter.
            src-addr4    IPv4 source address range to filter by.
            src-addr6    IPv6 source address range to filter by.
            src-port     Source port range to filter by.
            vd           Index of virtual domain. -1 matches all.

If you run the log-filter with different parameters, they are added to the existing filter in an AND configuration.

Active VPN Tunnels

# di vpn tunnel list [name $PHASE1NAME]

Force Renegotiation

List your current Phase-1s:

# di vpn ike gate list

Bounce a phase 1:

# di vpn ike gate flush name Phase1-Name

Renegotiate all phase-2s on a particular Phase-1:

# diag vpn tunnel flush

Renegotiate a specific phase-2:

# diag vpn tunnel flush Phase1-Name

You can also do it manually:

# diag vpn tun down Phase2-Name
# diag vpn tun up Phase2-Name

Sniffer

Keep in mind that application ike only shows Phase1/2 traffic nothing else. If you like to too look to the particular traffic from a user you can use the sniffer command which you will run on the ipsec interface and also there you can use different filters like the source IP of the user (IP Pool address). The sniffer command is used in following way:

# diagnose sniffer packet <interface_name> <‘filter’> <verbose> <count> a

       <interface_name>
       Name of the interface to run the sniffer like wan1 etc. you can use also any for all interfaces!

       <‘filter’>
       Definition for filter. The filter must be defined within "quotes" but you can use ‘ ' ". If you define none no filter
       is applied any everthing is shwon

       <count>
       Definition of counter which means how many packets will be shown

       Syntax: '[ [src|dst] host<host_name_or_IP1> ] [ [src|dst] host<host_name_or_IP2> ] [ [arp|ip|gre|esp|udp|tcp] [port_no] ] [ [arp|ip|gre|esp|udp|tcp] [port_no] ]'

       Example:

       Not Port 443            = '!port 443'
       Port 443                  = 'port 443'
       Host                      = 'host 192.168.1.1'
       Host und Host             = 'host 192.168.1.1 and host 192.168.1.2'
       Host und Port 443         = 'host 192.168.1.1 and port 443'
       Host und nicht Port 443   = 'host 192.168.1.1 and !port 443'
      Host oder Port 443        = 'host 192.168.1.1 or port 443'
       Nur udp Traffic           = 'udp'
       Nur SYN Flag              = 'tcp[13]&2==2'
       Nur ARP Packete           = 'arp'

       <verbose>
       Definiert den Level der "Verbosity":
       1 - Shows the header of a packet
       2 - Shows the header and data of IP packets
       3 - Shows the header and data of  Ethernet Packets (Frames ACSII und HEX)
       4 - Shows the header and Interface Name of Packets
       5 - Shows the header and data of IP Packets with Interface Name
       6 - Shows the headerund and of Ethernet Packets with Interface Name

'a' is the time to display:
    a      -- use UTC absolute
    l      -- use local time
    <none> -- use time relative to the start of the sniff

This information is from following KB:

http://kb.fortinet.com/kb/documentLink.do?externalId=11186

Actually the sniffer command is working like a tcpdump on linux/unix systems.

I only use capturing if you need application based information this means if a application is not working. If the access itself is a problem like destination is not answering or interrupt like you will find out who is sending a reset use sniffer command. You can also deeply troubleshoot based on TCP headers like follwoing example which shows only RST packets:

# diagnose sniffer packet any "tcp[13] & 4 != 0"

The "tcp[13] & 4 != 0" is indicating RST. How to get there see attached file (needs deeply tcp knowledge)! Below some examples:

'tcp[13]==1'       Only packets with FIN bit value with 1
'tcp[13]&4==4'     All packets with RST bit value with  1
'tcp[13]&8==8'     All packets with PSH bit value with  1
'tcp[13]==16'      Only packets with ACK bit value with  1
'tcp[13]&32==32'   All packets with URG bit value with  1
'tcp[13]&64==64'   All packets with ECE bit value with 1
'tcp[13]&128==128' All packets with CWR bit value with  1
'tcp[13]==24'      Only packets with PSH und ACK bit value with 1

(Source, post by AndriaSoliva)