Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] How to troubleshoot a VPN monitoring issue - IPSec SA status is A/D (active/down)

0

0

Article ID: KB11131 KB Last Updated: 20 Mar 2020Version: 8.0
Summary:

This article explains how to troubleshoot a VPN monitoring issue. After the SA is established if the status of tunnel is shown as A/D, it means that the SA by itself is active; but the tunnel is down due to the VPN monitoring feature being enabled on the SA.

Symptoms:

Symptoms and Errors:

  • VPN tunnel is down
  • VPN tunnel is active, but VPN monitor is DOWN
  • Traffic is not passing thru VPN


This article addresses the troubleshooting of a VPN tunnel that has the status of A/D (Active/Down); in the output of get sa as below:

Test-> get sa
total configured sa: 1
HEX ID    Gateway         Port Algorithm     SPI      Life:sec kb Sta   PID vsys
00000001<    172.19.51.62  500 esp:3des/sha1 58be8a0b  2055 unlim A/D   -1 0
00000001>    172.19.51.62  500 esp:3des/sha1 d795655d  2055 unlim A/D    -1 0
Solution:
There are two reasons why a VPN tunnel has the status A/D (VPN tunnel is Active, but the link (detected through VPN Monitor) is DOWN):
  1. The remote gateway is a non Juniper device and not able to understand the proprietary VPN monitoring packets sent by the Juniper device, and the remote gateway is dropping the packets. 
    To correct this problem, configure the Source interface and Destination IP in the VPN monitor, so that a host (which can reply for a regular ICMP request) behind the non Juniper device is tracked.
    VPN monitor periodically sends ICMP requests to the end host and expects a reply, so make sure the end host has ping enabled and is not down.  Also, ICMP needs to be enabled/permitted by the remote VPN gateway to allow the VPN Monitor packets.

  2. Both gateways are Juniper devices but still the VPN monitoring says the SA is down.

      To set the source interface and Destination IP in the VPN Monitor, refer to KB9503 - Configuring the Source Interface and Destination IP options of VPN Monitor.
 

To troubleshoot the problem further enable the following debug to understand why the VPN monitoring is down:

debug sa-mon all
debug flow basic

Two scenarios with these debugs are provided below:

Scenario 1

With only "debug sa-mon all" you will see the following result.
NOTE: You cannot apply any filters for "debug sa-mon all".
 
sa index(0) send count = 52, avail = 52, tunnel_info = 40000001
vpn monitor pkt is received: cookie = 0, result = 1

sa index(0) send count = 53, avail = 53, tunnel_info = 40000001
Vpn monitor pkt is received: cookie = 0, result = 1

Test-> get sa
total configured sa: 1
HEX ID    Gateway         Port Algorithm     SPI      Life:sec kb Sta   PID vsys
00000001<    172.19.51.62  500 esp:3des/sha1 58be8a0b  2055 unlim A/U    -1 0
00000001>    172.19.51.62  500 esp:3des/sha1 d795655d  2055 unlim A/U    -1 0

There are 2 VPN monitoring packets shown in the output, the first line shows the packet is sent with a count of 52, which means there were 52 monitoring packets sent since the SA is UP.

Tunnel_info shows on which SA the packets are sent, this will be helpful if you are troubleshooting one particular SA, while there are several others configured

The second line shows the reply packet is received with a result = 1, which means a success.
If the result = 3, then it is unsuccessful, meaning the remote gateway was either not able to reply to the ICMP request sent or the packet was dropped in the path.
 

Scenario 2

If the same debug is enabled with debug flow basic, you will see the following, this will give you much more info, as to which tunnel the packet is going, whether or not the packet was encrypted and sent on the tunnel.

NOTE: you can apply the flow filter when running debug flow basic, apply the flow filter as the destination IP address of the remote gateway OR the host IP address behind the remote firewall, if the source interface and destination IP is used.


****** 02210.0: <Self/self> packet received [44]******
  ipid = 1446(05a6), @c2534db4
flow_self_vector2: send pack with current vid =0, enc_size:0
  handle raw/no_session packet.
  send no session packet
  flow_if_ip_send_fwd: switch vectors: packet src 172.19.51.123, dst  172.19.51.62

**** jump to packet:172.19.51.123->172.19.51.62
  skipping pre-frag 
  going into tunnel 40000001.
  flow_encrypt: pipeline.
chip info: PIO. Tunnel id 00000001
(vn2)  doing ESP encryption and size =48
ipsec encrypt prepare engine done
ipsec encrypt set engine done
  **** pak processing end.
ipsec encrypt engine released
ipsec encrypt done
        put packet(453abe0) into flush queue.
        remove packet(453abe0) out from flush queue.

**** jump to packet:172.19.51.123->172.19.51.62
  out encryption tunnel 40000001 gw:172.19.51.62
  no more encapping needed
  send out through normal path.
  flow_ip_send: 05a8:172.19.51.123->172.19.51.62,50 => ethernet3(96) flag 0x898, vlan 0
  mac 0010db17f0b6 in session
  **** pak processing end.

sa index(0) send count = 109, avail = 109, tunnel_info = 40000001

****** 02210.0: <Untrust/ethernet3> packet received [96]******
  ipid = 1443(05a3), @d785a110
  packet passed sanity check.
  ethernet3:172.19.51.62/22718->172.19.51.123/35339,50<Root>
  existing session found. sess token 6
  flow got session.
  flow session id 64061
  flow_decrypt: 3bc7608(b),   flow_decrypt: 3bc7608(b)pipeline.
  IPv4 encrypted pak.
  Dec: SPI = 58be8a0b, Data Len = 96
  SA tunnel id=0x00000001, flag<000021e3>
  chip info: DMA. Tunnel id 00000001
  ipsec decrypt prepare done
  ipsec decrypt set engine done
  ipsec decrypt engine released, auth check pass!
  packet is decrypted
  ipsec decrypt done
        put packet(453abe0) into flush queue.
        remove packet(453abe0) out from flush queue.
             
**** jump to packet:172.19.51.62->172.19.51.123
  tunnel.1:172.19.51.62/1024->172.19.51.123/12300,1(0/0)<Root>
  no session found
  flow_first_sanity_check: in <tunnel.1>, out <N/A>
   copy to stack (flag 0x302).
  **** pak processing end.

vpn monitor pkt is received: cookie = 0, result = 1


In the above debug we can see the self packet generated to the remote gateway address, packet is encrypted and sent on tunnel "40000001".
The "debug sa-mon all" shows the send count as 109.
The next debug flow output shows the ESP packet received, and after decryption we see the ICMP reply packet for the same gateway address.
The "debug sa-mon all" shows the packet received with a result=1 which is success.
If the result=3, then you may or you may not see the second part of the debug flow, depending on the situation.


If the issue is still not resolved, refer to KB9520 - How do I troubleshoot a Site-to-Site VPN where the SA is Up, but the status is Down?
Modification History:

2020-03-20: Minor, non-technical updates.
2017-12-07: Article reviewed for accuracy. Minor grammatical changes. Rest of the Article is correct and complete.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search