Support Support Downloads Knowledge Base Apex Support Portal 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

[SRX] How to troubleshoot a VPN that is up, but is not passing traffic

0

0

Article ID: KB10093 KB Last Updated: 20 Apr 2021Version: 13.0
Summary:
 

Although the VPN tunnel status is active, several factors can prevent traffic from passing through the tunnel. This article helps identify what might be preventing data from passing through the VPN.

This article is part of the troubleshooting guide: KB10100 - [SRX] Resolution Guide - How to troubleshoot Problem Scenarios in VPN tunnels.

 

Symptoms:
 

The VPN is up, but it is not passing traffic in one or both directions.

 

Solution:
 

Use the following steps to troubleshoot a VPN tunnel that is active, but not passing data:

Note: If your VPN is down, then go to KB10100 - [SRX] Resolution Guide - How to troubleshoot Problem Scenarios in VPN tunnels. If your VPN is going up and down, then proceed with the following steps.

  1. Is the IPsec SA (Security Association) listed in show security ipsec security-associations?

If it is not listed, then the SA is not active or up.

For assistance, consult: KB10090 - How do I tell if a VPN Tunnel SA (Security Association) is active?

  1. Is the VPN using the loopback Lo0 as the external interface?

root> show configuration security ike
policy ike_pol {
   proposal-set compatible;
   pre-shared-key ascii-text "$ABC123";
}
gateway gate1 {
  ike-policy ike_pol;
  address 10.10.10.2;
  external-interface lo0.0;
} 
  • Yes - Continue with Step 3.

  • No - Jump to Step 4.

  1. Based on route to destination, are the egress interface and the lo0 interface, which is used as the VPN external interface, in the same security-zone?

  • Yes - Continue with Step 4.

  • No - Update security zone assignments so that both the VPN external interface and the physical egress interface are in the same security-zone.

For assistance, consult KB22129 - [SRX] Traffic loss when IPsec VPN is terminated on loopback interface.

  1. Is this a route-based VPN or a policy-based VPN?

For information about determining the difference, consult KB10105 - Difference between a policy-based VPN and a route-based VPN.

  • Route-based VPN - Continue with Step 5.

  • Policy-based VPN - Jump to Step 8.

  1. [Route-based VPN] Does a route for the remote network exist via the st0 interface in show route <remote network>?

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    *[Static/5] 00:00:53
                           > via st0.0  <----------

If you are using route-based VPNs with traffic selectors, Auto Route Insertion (ARI) automatically inserts a static route for the remote network and hosts protected by a remote tunnel endpoint. A route is created based on the remote IP address configured in the traffic-selector. In the case of traffic selectors, the configured remote address is inserted as a route in the routing instance associated with the st0 interface that is bound to the VPN.

Ref : Route Based VPN with Traffic Selectors

Note: If running dynamic routing protocols, like BGP or OSPF, investigation into the routing protocol will be necessary.

  1. [Route-based VPN] Looking at the route located in Step 5, is the next-hop for the route pointing to the correct st0 interface? 

    1. First, locate the IKE gateway by using show security ike.

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;
}
  1. Then locate the IPsec VPN for that IKE gateway by using show security ipsec.

root@siteA # show security ipsec
...
vpn ike-vpn-siteB {     
    bind-interface st0.0;
      ike {
         gateway gw-siteB;      <---------
         proxy-identity {
             local 192.168.1.0/24;
             remote 192.168.2.0/24;
             service any;
           }
          ipsec-policy ipsec-phase2-policy;
        }
     establish-tunnels immediately;
    }
  1. Review the bind-interface located in Step 6b to locate the st0 interface.

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

  • Yes – Continue with Step 7.

  • No - The VPN is not bound to the correct st0 interface.

Delete the current route and add the route to the correct st0 interface. For more information, consult KB10107 - [SRX] Route-based VPN is up, but not passing traffic. Is a route missing?

  1. [Route-based VPN] Is there a security policy that allows traffic from the internal zone to the st0 security zone in show security policies?

  1. [Policy-based VPN] Is there a VPN tunnel security policy to allow traffic in show security policies?

root@siteA# show security policies
...

from-zone trust to-zone untrust {
    policy vpn-policy-siteB {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit {
                tunnel {
                    ipsec-vpn ike-vpn-siteB;              <<<<<
                    pair-policy vpn-policy-return-siteB;  <<<<<
                }
            }
        }
    }
}

from-zone untrust to-zone trust {
    policy vpn-policy-return-siteB {
        match {
            source-address any;
            destination-address any;
            application any;
        }                               
        then {
            permit {
                tunnel {
                    ipsec-vpn ike-vpn-siteB;       <<<<<
                    pair-policy vpn-policy-siteB;  <<<<<
                }
            }
        }
    }
} 
  • Yes - A VPN tunnel security policy exists – Continue with Step 9.

  • No  - Verify the policy-based VPN configuration. Consult: Policy-Based IPsec VPNs.

  1. Is the traffic matching the policy identified in Step 7 or 8?

Use the operational command show security flow session source prefix <source address> destination prefix <destination address> to locate the matched policy.

root@siteA> show security flow session source-prefix 192.168.1.0/24 destination-prefix 192.168.2.0/24

Session ID: 5801, Policy name:vpn-policy-siteB/2, Timeout: 1790, Valid 
In:  192.168.1.222/1 --> 192.168.2.13/23053;icmp, If: ge-0/0/2.0, Pkts: 59878, Bytes: 4602292
Out: 192.168.2.13/23053 --> 192.168.1.222/1;icmp, If: st0.0,      Pkts: 52505, Bytes: 4189289

If the order is correct, then consult: KB10113 - [SRX] 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.

  1. Collect logs and flow traceoptions, and open a case with your technical support representative.

Consult: KB21781 - [SRX] Data Collection Checklist (see the IPsec VPN Policy-based or Route-based VPN sections).

For flow traceoptions information, consult: KB16233 - [SRX] How to use "flow traceoptions" and "security datapath-debug".

 

Modification History:
 
  • 2020-06-29: Removed J-Series references

  • 2021-04-20: Edited outputs, corrected reference links, updated article to reflect current information

 

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