Description

Dynamic VPN client is connected to the SRX, but the client can't get to protected resources.  Because the client IP address is on the same network as the protected resources, Proxy ARP must be configured on the SRX.

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 is connected to SRX, but the client can't ping or access protected resources (i.e. a server).  Also, the virtual IP address assigned to the Pulse client is on same network as the protected resource

Solution


Perform the following steps:

Step 1. This article assumes that you already determined in KB17660 - Pulse client is connected, but can't get to protected resources [juniper.net] that the Pulse client Virtual Adapter IP address is on the same IP network as the protected resource (i.e. internal server).  Is that correct?

For example, the IP address assigned to Client Virtual Adapter is 192.168.2.200 and the IP address of the protected resource is 192.168.2.3 with a subnet of 255.255.255.0 (/24).


Step 2.   On the SRX, is the Proxy ARP option configured?
  • Yes - Continue with Step 3
  • No or not sure - Configure the Proxy ARP option:       
The Proxy ARP option allows for the SRX to respond to ARP requests for addresses that are not configured on the SRX interface such as NAT IPs.
The use of Proxy ARP is necessary when the Client and Internal host IPs are on the same subnet, as the Internal host will send an ARP request for the client IP. 
      Note: You can configure this even if not using NAT.

Proxy ARP is configured as follows:

To configure Proxy ARP:
user@srx# set security nat proxy-arp interface <interface> address <client virtual adapter IP address>   

where <interface> is the interface facing the protected resources


Important Note:  Only configure Proxy ARP for the IP addresses that will be assigned to the Dynamic VPN clients that do not conflict with hosts on internal network. 
                           If you setup proxy-arp for hosts other than the Dynamic VPN clients, IP conflicts will appear.


For example, to configure Proxy ARP for two Dynamic VPN Pulse clients assigned the IP address 192.168.2.200 and 192.168.2.200, use the following command:

user@srx# set security nat proxy-arp interface ge-0/0/1.0 address 192.168.2.200 to 192.168.2.201

user@srx> show configuration security nat

proxy-arp {
     interface ge-0/0/1.0 {
          address {
               192.168.2.200/32;
               192.168.2.201/32;
          }
     }
}

If after configuring Proxy ARP the client still can't connect, continue with Step 3 .


Step 3.   On the SRX device, follow the steps below to capture the traffic between the Pulse client and the protected resource (Server).

a.  Setup 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 F1 source-prefix 192.168.2.200 destination-prefix 192.168.2.3

root@srx# set security flow traceoptions packet-filter F2 source-prefix 192.168.2.3 destination-prefix 192.168.2.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 4.   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 5
  • No  -  Jump to Step 7

Step 5.   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 - Jump to Step 6
  • No  - Verify on protected resource that an arp entry exists for VPN client's virtual IP.  Mac Address should be that of the SRX interface facing protected resource.

Step 6. Review the traceoptions output for any other clues. Traffic may be dropped because of a security policy. The security policy must match the 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. Refer to the Dynamic VPN application note for an explanation. 
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 7. Confirm that the remote-protected-resources is defined in the Dynamic VPN configuration for that user by running show security dynamic-vpn . Refer to Step 4 of the Dynamic VPN application note for an explanation.

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 8.   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