Troubleshoot a VPN That Is Up But Not Passing Traffic

Problem

• Description
• Environment

Solution

1. Check whether the VPN security association (SA) is active: show security ipsec security-associations

   content_copy zoom_out_map

   user@CORPORATE> show security ipsec security-associations  
     total configured sa: 1
     ID     Gateway         Port  Algorithm       SPI      Life:sec/kb  Mon vsys
     <32785 2.2.2.2         1398  ESP:3des/sha1   29e26eba 28735/unlim   -   0
     >32785 2.2.2.2         1398  ESP:3des/sha1   6d4e790b 28735/unlim   -   0   

   If the VPN gateway is listed, the tunnel is established and is up. The output displays two lines for each VPN tunnel displaying the SPI information for each direction of traffic.

   The MON field is used by VPN monitoring to show the status of the tunnel and has one of the following values:

   • - (hyphen): The VPN tunnel is active, and the VPN monitor optional feature is not configured.

   • U (up): The VPN tunnel is active, and the link (detected through the VPN monitor) is up.

   • D (down): The VPN tunnel is active, and the link (detected through the VPN monitor) is down.

   • Yes: The IPsec SA state is active or up. Proceed to Step 2.

   • No: The IPsec SA state is down. See How to troubleshoot a VPN tunnel that is down or not active.

2. Check whether the VPN is using the loopback interface lo0 as the external interface: show configuration security ike

   content_copy zoom_out_map

   root> show configuration security ike
   policy ike_pol {
      proposal-set compatible;
      pre-shared-key ascii-text "$9$tMwDuIESreWX7yr4aGDkqIEhcvWbs2";
   }
   gateway gate1 {
     ike-policy ike_pol;
     address 10.10.10.2;
     external-interface lo0.0;
   }

   • Yes: VPN is using the the loopback interface lo0 as the external interface. Proceed to Step 3.

   • No: VPN is not using the the loopback interface lo0 as the external interface. Proceed to Step 4.

3. Check whether the egress interface (physical interface) and lo0 used as the VPN external interface are in the same security zone.

   • Yes: Proceed to Step 4.

   • No: Update the security zone assignments so that both the VPN external interface and the physical egress interface are in the same security zone. See Traffic Loss when IPSec VPN is terminated on loopback interface.

4. If your VPN is a route-based VPN, proceed to Step 5. Proceed to Step 8 if it is a policy-based VPN. See What is the difference between a policy-based VPN and a route-based VPN?

5. Check whether a route is assigned to the remote network through the st0 interface: show route remote network

   content_copy zoom_out_map

   root@siteA > show route 192.168.20.10
   inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
   + = Active Route, - = Last Active, * = Both
   192.168.2.0/24    *[ARI-TS/5] 00:00:53
                              > via st0.0  <----------

   • Yes: Proceed to Step 6.

   • No: Assign a route to the remote network through the st0 interface. See Route-based VPN is up, but not passing traffic. Is a route missing?.

     Note:

     If you are using a dynamic routing protocol, such as BGP or OSPF, then check the routing protocol.

6. Based on the route assigned to the remote network in Step 5, check whether the VPN is pointing to the correct st0 interface: show security ike and show security ipsec

   1. First, check the IKE gateway using the show security ike command.

      content_copy zoom_out_map

      root@siteA # show security ike
      ...
      gateway gw-siteB {        <---------
           ike-policy ike-phase1-policy;
           address 2.2.2.2;
           external-interface ge-0/0/3.0;
      }

   2. Check the IPsec VPN for that IKE gateway using the show security ipsec command and in the output verify if bind-interface is pointing to st0 interface.

      In this example, the VPN ike-vpn-siteB is pointing to the st0.0 interface.

      content_copy zoom_out_map

      root@siteA # show security ipsec
      ...
      vpn ike-vpn-siteB {     
          bind-interface st0.0;
            ike {
               gateway gw-siteB;      <---------
               proxy-identity {
                   local 192.168.2.0/24;
                   remote 192.168.1.0/24;
                   service any;
                 }
                ipsec-policy ipsec-phase2-policy;
              }
           establish-tunnels immediately;
          }

   • Yes: Proceed to Step 7.

   • No: VPN is not pointing to the correct st0 interface. Delete the current route, and add the route to the correct st0 interface. See Route-based VPN is up, but not passing traffic. Is a route missing?.

7. Check whether there is a security policy that allows traffic from the internal zone to the st0 security zone: show security policies

   • Yes: Proceed to Step 8.

   • No: Create the appropriate security policy and test the VPN again. See How to configure a policy for a route-based VPN.

8. Check whether there is a VPN tunnel security policy to allow traffic: show security policies

   content_copy zoom_out_map

   root@siteA# show security policies
   ...
   from-zone trust to-zone untrust {
       policy vpn_egress {
           match {
               source-address local-net;
               destination-address remote-net;
               application any;
           }
           then {
               permit {
                   tunnel {                      <----------
                       ipsec-vpn ike-vpn-siteC;  <----------
                   }
               }
           }
       }
    }
   
   from-zone untrust to-zone trust {
       policy vpn_ingress {
           match {
               source-address remote-net;
               destination-address local-net;
               application any;
           }
           then {
               permit {
                   tunnel {                      <----------
                       ipsec-vpn ike-vpn-siteC;  <----------
                   }
               }
           }
       }
    }

   • Yes: Proceed to Step 9.

   • No: Verify the policy-based VPN configuration. See Policy-Based site-to-site VPN .

9. Check whether the traffic is matching in the policies identified in step 7 or step 8: show security flow session source prefix source address destination prefix destination address

   content_copy zoom_out_map

   root@siteA> show security flow session source-prefix 192.168.2.0/24 destination-prefix 192.168.1.0/24
   
   Session ID: 5801, Policy name: AtoB/2, Timeout: 1790, Valid
   In: 192.168.2.222/1 --> 192.168.1.13/23053;icmp, If: fe-0/0/2.0, Pkts: 59878, Bytes: 4602292
   Out: 192.168.1.13/23053 --> 192.168.2.222/1;icmp, If: st0.0, Pkts: 52505, Bytes: 4189289

   • Yes: Proceed to Step 10.

   • No: Verify the order of the security policies: show security match policies. See Understanding Security Policy Ordering.

     If the order is correct, see How to troubleshoot a security policy that is not passing data.

     Note:

     If only the pkts counter in the out direction of the session is incrementing, then validate with the VPN peer that the traffic is being received.

     This is to check the packet counters on the VPN peer with which this tunnel is formed to see whether the other end is receiving the packets.

10. Collect logs and flow trace options and open a case with the Juniper Networks support team:

    • See the IPsec VPN policy-based or route-based VPN sections in Data Collection Checklist - Logs/data to collect for troubleshooting.

    • For information regarding flow trace options, see How to use 'flow traceoptions' and the 'security datapath-debug'.

    • To open a JTAC case with the Juniper Networks support team, see Data Collection for Customer Support for the data you should collect to assist in troubleshooting before opening a JTAC case.