Description

Troubleshooting steps to get your Pulse client (Dynamic VPN) accessing the protected resources on your network.

This article is a part of the Dynamic VPN Resolution Guide:  KB17220 - Resolution Guide - SRX - Troubleshoot Pulse VPN connections to SRX [juniper.net] .


Symptoms

Symptoms:

  • Pulse client can't reach protected resources.
  • Pulse client can't ping or access protected resources.

Solution

Perform the following steps:

Step 1.   This article assumes that the Pulse client is connected to the SRX.  If the Pulse client PC is not connected or you are not sure if it is connected to the SRX, refer to KB17220 - Resolution Guide - SRX - Troubleshoot Pulse VPN connections to SRX [juniper.net] .


Step 2.   On the Pulse PC client, enter the command ipconfig from a DOS prompt. Look at the IP address assigned to the Ethernet Adapter Juniper Network Agent Virtual Adapter. 
alt

Step 3.   Determine which of the following describes the IP address assigned to the PC's virtual adapter:
Below is an example of how to tell.  In the network diagram, the IP address assigned to the PC client user1 is 18.18.18.200, and the IP address assigned to the PC client user2 is 192.168.2.200. The protected resource that the clients are trying to access is the server IP 192.168.2.3.  In this case, the PC client user1 and server are on different IP networks. The PC client user2 and server are on the same IP networks.  (It is recommended to assign IP addresses on a different network than the protected resources.)
alt  

Step 4.   On the SRX device, follow the steps below to capture the traffic between the Pulse client (user1 in this example) and the protected resource (server).

a.  Set up the security flow traceoptions:

root@srx# set security flow traceoptions file flow-debug
root@srx# set security flow traceoptions flag basic-datapath
root@srx# set security flow traceoptions packet-filter <filter name> source-prefix <client virtual adapter IP address> destination-prefix <protected resource IP address>
root@srx# set security flow traceoptions packet-filter <different filter name> source-prefix <protected resource IP address> destination-prefix <client virtual adapter IP address>  
root@srx# commit

        For example:

root@srx# set security flow traceoptions file flow-debug
root@srx# set security flow traceoptions flag basic-datapath
root@srx# set security flow traceoptions packet-filter filter1 source-prefix 18.18.18.200 destination-prefix 192.168.2.3
root@srx# set security flow traceoptions packet-filter filter2 source-prefix 192.168.2.3 destination-prefix 18.18.18.200
root@srx# commit

b.  Clear the log file:
root@srx# clear log flow-debug


c.  Then have the Pulse client attempt to access the server.



Step 5.   View the traceoptions output file, matching on the client's virtual adapter IP address:

root@srx> show log flow-debug match <client virtual adapter IP address>

Do you see traffic coming from the client's virtual adapter IP address?
  • Yes - Continue with Step 6.
  • No   -  Skip to Step 9.  


Step 6.   View the traceoptions output file, matching on the protected resource IP address. 

root@srx> show log flow-debug match <protected resource IP address>

Do you see traffic coming from the protected resource IP address?
  • Yes - Skip to Step 8.
  • No  - Continue with Step 7.


Step 7.   On the protected resource (i.e., the internal server), check for a route to the Dynamic VPN client's virtual adapter IP address.  

One way to check for a route is to use the traceroute command. 
From Windows systems, run the command:   tracert < client virtual adapter IP address >
From Linux systems, run the command:   traceroute < client virtual adapter IP address >

For example, in the topology example above, make sure the server has a route to the Pulse Client address (18.18.18.200), with a next-hop of the SRX trust IP address:
route add 18.18.18.200/32 next-hop 192.168.2.1

To add routes for two additional IP addresses:
route add 18.18.18.201/32 next-hop 192.168.2.1 
route add 18.18.18.202/32 next-hop 192.168.2.1

To add a route to a network range of IP addresses:
route add 18.18.18.200/24 next-hop 192.168.2.1 
If after correcting a route the client still can't connect, restart at KB17220 - Troubleshoot Pulse VPN connections to SRX [juniper.net] ; otherwise, skip to Step 10.



Step 8.   Review the traceoptions output for any other clues.   Traffic might be dropped because of a security policy. The security policy should be configured as source-address any , destination-address any , and application any .  The security policy for the dynamic VPN behaves differently than a security policy for traffic traversing the SRX. For Dynamic VPN security policies, the restriction of resources is handled by the dynamic-vpn configuration section.

Note:   Dynamic VPN tunnel policies should be listed after clear-text policies and recommended to be near or at the bottom of the policy list. Careful consideration of policy creation and ordering must be taken to ensure that clear-text traffic does not match VPN ingress (out-of-tunnel) policies.

                          root@srx#  show security policies from-zone untrust to-zone trust 
            policy vpn-user1 {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit {
                        tunnel {
                            ipsec-vpn dyn-vpn-user1;
                        }
                    }
Step 9.   Confirm that the remote-protected-resources is defined in the Dynamic VPN configuration for that user by running show security dynamic-vpn . 
root@srx# show security dynamic-vpn

access-profile radius-server;
clients {
    user1 {
        remote-protected-resources {
            192.168.2.0/24;
        }
        remote-exceptions {
            0.0.0.0/0;
        }
        ipsec-vpn dyn-vpn-user1;
        user {
            user1;
        }
    }
}
If this is defined correctly, then check for any devices between the client and SRX that would block ESP traffic.


Step 10.   If the problem is still not resolved after completing the steps above, collect the information listed in KB21781 - [SRX] Data Collection Checklist - Logs/data to collect for troubleshooting [juniper.net] , along with the debugs captured above, and open a case with your technical support representative.

Related Information