Diagnose VPN

[JohnAgora]

Hello,

I have a device running 5.2.7 with over 1,000 dialup VPNs at every moment.

I need to debug a VPN that is not being properly stabilished.

Anyhow if I do:

diagnose debug enable

diagnose debug application ike -1

I see lots of information.

Especially all the (R-U-THERE) messages (lots and lots).

If I use diagnose vpn ike log-filter src-addr4 x.x.x.x I can't get all the relevant info.

Any idea on how can I make a more effective debug through cli?

Thanks!

[emnoc]

why not execute  packet capture with the  fiter set for udp 500 or 4500  and the src ( client  4.x.x.x ) than you can analyze the traffic

or

get the client to capture from his end ( this would be easier ) ;)

[JohnAgora]

The problem with packet capture is that it requieres additional tools (wireshark, etc.) and it not as easy to see the error as with the diagnose debug.

Capture from the client side not always give the full information.

For example, on a dial up VPN. If the user/password is not in the central FW, that can only be detected from the central FW.

[AndreaSoliva]

Hi

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:

              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.

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

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

Hope this helps

have fun

Andrea

[emnoc]

The problem with packet capture is that it requieres additional tools (wireshark, etc.) and it not as easy to see the error as with the diagnose debug.

Hogwash is what I would say. Every thing Andrea point out above would be present in  the  pcap to include information pertaining  phase1 IKE cookies, IKE-KAs, IKE-NAT-T, etc...... phase2 ipsec ESP ( spi#, seq#,etc...)

How do you think we actually debugged  traffic event before diagnostic commands even existed ? ;) Free tools like wireshark/tshark are actually more useful than  what persons give it credit for most just flat out don't know or too lazy to use them imho.

Capture from the client side not always give the full information.

And that's the main reason why you  would diagnose the client connect on the client side. You stated early you have hundreds if not thousands of  connections but only one connect that your having problems with. You probably need to inspect that one connection and see what happening at the  clientside as it pertains to ike and/or ESP

[ramunas]

Hello,

I guess it is 5.41 OS bug. ike log filter src-addr4 doesn't give useful output any more, it shows "ike shrank heap by ":

FGT90D3Z13002576 # diag debug reset FGT90D3Z13002576 # diag debug app ike -1 FGT90D3Z13002576 # diag vpn ike log filter clear FGT90D3Z13002576 # diag vpn ike log filter src-addr4 10.10.20.13 FGT90D3Z13002576 # diag vpn ike log filter list vd: any name: any interface: any IPv4 source: 10.10.20.13 IPv4 dest: any IPv6 source: any IPv6 dest: any source port: any dest port: any

FGT90D3Z13002576 # diag debug en FGT90D3Z13002576 # ike shrank heap by 131072 bytes ike shrank heap by 122880 bytes FGT90D3Z13002576 #

whereas filter by "name" works fine (but it can't filter all messages from other ipsec tunnels). Any idea how to disable "shrink" functionality?

[boneyard]

i don't believe that is something you disable, it seems to indicate something about memory management of the ike proces.

i have a similar experience with diag vpn ike log filter, support said diag vpn ike log filter dst-addr4 should show you everything of one tunnel based on the remote end point

[MikePruett]

Yeah, keep doing what you are doing and just stick to destination ip (remote gw ip)....about the only way to cleanly filter IPSEC debugs

[Sachin8094]

SSL vpn users --->Fortigate <-----------------------------------------------> Checkpoint ------> servers

                                           IPSEC VPN route based

What we are finding the SSL vpn client users are facing issues in completing the three way handshake syn is going syn ack is getting received while the client machine is sending the RST immediately

Error observed in the debug on fortigate is

func=print_pkt_detail line=4378 msg="vd-root received a packet(proto=6, 192.168.94.1:50780->172.29.30.16:3389) from local. flag , seq 71587710, ack 0, win 0"

# diagnose sniffer packet any "host 172.29.30.16 and tcp port 3389" 4 0 a interfaces=[any] filters=[host 172.29.30.16 and tcp port 3389] 2017-02-02 05:54:38.755580 ssl.root in 192.168.94.1.51266 -> 172.29.30.16.3389: syn 3838243965 2017-02-02 05:54:38.755619 Avenue_Ecom_Mum out 192.168.94.1.51266 -> 172.29.30.16.3389: syn 3838243965 2017-02-02 05:54:38.802968 Avenue_Ecom_Mum in 172.29.30.16.3389 -> 192.168.94.1.51266: syn 3317155358 ack 3838243966 2017-02-02 05:54:38.803017 Avenue_Ecom_Mum out 192.168.94.1.51266 -> 172.29.30.16.3389: rst 3838243966 2

[boneyard]

might be wiser to start a new thread, jumping on another thread confuses things.

also this seems to be more a network issue then a VPN one. in the new thread you might want to combine the IPs and interface names to the first drawing.