Hot!Diagnose VPN

Author
JohnAgora
Silver Member
  • Total Posts : 94
  • Scores: 7
  • Reward points: 0
  • Joined: 2015/10/14 11:43:36
  • Status: offline
2016/04/15 15:29:23 (permalink) 5.2
0

Diagnose VPN

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!
#1

10 Replies Related Threads

    emnoc
    Expert Member
    • Total Posts : 5082
    • Scores: 311
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Diagnose VPN 2016/04/15 21:28:54 (permalink)
    0
    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 ) ;)
     

    PCNSE,  NSE , Forcepoint ,  StrongSwan Specialist
    #2
    JohnAgora
    Silver Member
    • Total Posts : 94
    • Scores: 7
    • Reward points: 0
    • Joined: 2015/10/14 11:43:36
    • Status: offline
    Re: Diagnose VPN 2016/04/18 08:29:30 (permalink)
    0
    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.
     
    #3
    AndreaSoliva
    Expert Member
    • Total Posts : 248
    • Scores: 76
    • Reward points: 0
    • Joined: 2014/02/10 05:41:00
    • Status: offline
    Re: Diagnose VPN 2016/04/19 00:17:44 (permalink)
    5 (1)
    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
     
     
    #4
    emnoc
    Expert Member
    • Total Posts : 5082
    • Scores: 311
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Diagnose VPN 2016/04/19 05:26:09 (permalink)
    0

    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
     
     
     

    PCNSE,  NSE , Forcepoint ,  StrongSwan Specialist
    #5
    ramunas
    New Member
    • Total Posts : 15
    • Scores: 0
    • Reward points: 0
    • Joined: 2015/02/20 04:10:52
    • Status: offline
    Re: Diagnose VPN 2016/12/20 06:36:39 (permalink)
    0
    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?
    #6
    boneyard
    Silver Member
    • Total Posts : 95
    • Scores: 4
    • Reward points: 0
    • Joined: 2014/07/30 11:15:18
    • Status: offline
    Re: Diagnose VPN 2017/01/06 11:47:52 (permalink)
    0
    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
    #7
    MikePruett
    Platinum Member
    • Total Posts : 676
    • Scores: 15
    • Reward points: 0
    • Joined: 2014/01/08 19:39:40
    • Location: Montgomery, Al
    • Status: offline
    Re: Diagnose VPN 2017/01/07 13:48:03 (permalink)
    0
    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

    Mike Pruett
    Fortinet GURU
    #8
    Sachin8094
    New Member
    • Total Posts : 6
    • Scores: 0
    • Reward points: 0
    • Joined: 2012/10/19 01:50:48
    • Status: offline
    Re: Diagnose VPN 2017/02/03 07:13:53 (permalink)
    0
    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 [R], 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
     
    #9
    boneyard
    Silver Member
    • Total Posts : 95
    • Scores: 4
    • Reward points: 0
    • Joined: 2014/07/30 11:15:18
    • Status: offline
    Re: Diagnose VPN 2017/02/03 11:10:20 (permalink)
    0
    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.
    #10
    Arshad Ali
    New Member
    • Total Posts : 5
    • Scores: 0
    • Reward points: 0
    • Joined: 2017/12/19 04:45:39
    • Status: offline
    Re: Diagnose VPN 2017/12/19 22:53:49 (permalink)
    0
    Is it possible to transmit broadcast via UDP ports while being connected on dialup VPN from Internet.
     
    We have custom dialup tunnel from our office to client end.
     
    VPN is connected but i need to find a way where my source IP should be that of server (generating broadcast) and destination address should be 255.255.255.255.
     
    When i run WIreshark on VPN i am unable to find any packet from my server's source address rather its the Vitual address of VPN in the source.
     
    please suggest.
     
     
    #11
    Jump to:
    © 2018 APG vNext Commercial Version 5.5