Junos Pulse Remote access VPN with LDAP authentication

Recently I was tasked with a small Juniper SRX install for a client. One of their requirements was satellite remote access for connectivity into their production network. This had to tie into their AD environment for authentication just as the Cisco ASA did that I was replacing. I am going to do a small explanation on how to set this up and the configuration necessary to get it going. Small disclaimer, I am by no means a Microsoft expert so please forgive me If I use the wrong term, or explain something strangely.

One thing I never usually credit Junos OS for is JWeb, however for really basic remote access and site to site IPSEC VPNs, the wizard driven menu cuts down a lot of time spent and actually achieves the task rather well. In this post, i will not however be explaining the Jweb process, but the set configuration that the wizard generates.

First of all, we have the ipsec policy for the VPN.

set security ipsec policy ipsec_pol_wizard_dyn_vpn proposal-set compatible

The compatible proposal set includes a set on standard predefined parameters that are negotiated from the client application to the VPN terminator.

If you are move familiar with cisco or Juniper site to site VPNs, usually you would configure a phase 2 proposal like this

set security ipsec policy srx_nz_ipsec_policy proposals esp_aes256_sha1_3600
set security ipsec proposal esp_aes256_sha1_3600 protocol esp
set security ipsec proposal esp_aes256_sha1_3600 authentication-algorithm hmac-sha1-96
set security ipsec proposal esp_aes256_sha1_3600 encryption-algorithm aes-256-cbc
set security ipsec proposal esp_aes256_sha1_3600 lifetime-seconds 3600

However we don’t need to worry about this, the wizard creates the compatible proposal in the background. In the phase 1 setup the wizard also creates a compatible proposal. Again if you are more familiar with a static setup, it would look something like this

set security ike policy srx_nz_ike_policy proposals preshare_group5_aes256_sha1
set security ike proposal preshare_group5_aes256_sha1 authentication-method pre-shared-keys
set security ike proposal preshare_group5_aes256_sha1 dh-group group5
set security ike proposal preshare_group5_aes256_sha1 authentication-algorithm sha1
set security ike proposal preshare_group5_aes256_sha1 encryption-algorithm aes-256-cbc
set security ike proposal preshare_group5_aes256_sha1 lifetime-seconds 3600

What we are using in this example however is this:

set security ike policy ike_pol_wizard_dyn_vpn mode aggressive
set security ike policy ike_pol_wizard_dyn_vpn proposal-set compatible
set security ike policy ike_pol_wizard_dyn_vpn pre-shared-key ascii-text "$9$5F9tleM8L7Uj36CuIRdVw2aGQz3tuBLx2oZj.mzFn/tuEhy8x-cSbs2aGUjikPz3p0BSlK"

set security ike gateway gw_wizard_dyn_vpn ike-policy ike_pol_wizard_dyn_vpn
set security ike gateway gw_wizard_dyn_vpn dynamic hostname firewall01
set security ike gateway gw_wizard_dyn_vpn dynamic connections-limit 50
set security ike gateway gw_wizard_dyn_vpn dynamic ike-user-type group-ike-id
set security ike gateway gw_wizard_dyn_vpn external-interface lo0.0
set security ike gateway gw_wizard_dyn_vpn xauth access-profile dyn-vpn-ldap-xauth

The key points to note from the configuration above are the external interface and the access-profile. The external interface specifies the interface that you terminate the VPN on. This will usually be your “external” IP address, or the address that is routed over the internet. The access-profile is where we define how users are authenticated on the VPN.

set access profile dyn-vpn-ldap-xauth authentication-order ldap
set access profile dyn-vpn-ldap-xauth authentication-order password
set access profile dyn-vpn-ldap-xauth client admin firewall-user password "$9$.5n90OIcSrPf9pBEeKDiHkfT"
set access profile dyn-vpn-ldap-xauth client admin2 firewall-user password "$9$m5z6pu1yrvFnCuOBEhdbw"
set access profile dyn-vpn-ldap-xauth address-assignment pool dyn-vpn-address-pool
set access profile dyn-vpn-ldap-xauth ldap-options base-distinguished-name DC=int,DC=example,DC=co,DC=nz
set access profile dyn-vpn-ldap-xauth ldap-options search search-filter sAMAccountName=
set access profile dyn-vpn-ldap-xauth ldap-options search admin-search distinguished-name CN=SRXLDAP,CN=Users,DC=int,DC=example,DC=co,DC=nz
set access profile dyn-vpn-ldap-xauth ldap-options search admin-search password "$9$WPRLxN4aZUHquOxN-V4oJGUiH.QF/AtOJGT39Cu07-d"
set access profile dyn-vpn-ldap-xauth ldap-server 192.168.100.19 port 389

This piece of configuration is what the SRX uses to query active directory for an LDAP server. Now the specify LDAP tree configuration above I’m not an expert on, by no means am I a windows person but it helps demonstrate the full picture. Some other key points here is the authentication order and the address-assignment pool.
- Auth order: specifies order of authentication that the SRX uses. First LDAP and if unavailable, then use local auth. You can see the fullback usernames and passwords specified under “client”
- address-assignment pool: specifies the network details assigned to authenticated clients. IP/DNS etc.

The address assignment pool looks like this:

set access address-assignment pool dyn-vpn-address-pool family inet network 172.16.1.0/24
set access address-assignment pool dyn-vpn-address-pool family inet xauth-attributes primary-dns 192.168.100.19/32

Now one thing I don’t quite agree with on with the junos remote access VPN with this LDAP profile is the requirement to still configure each user configured in the LDAP server on the SRX configuration.

set security dynamic-vpn access-profile dyn-vpn-ldap-xauth
set security dynamic-vpn clients wizard-dyn-group ipsec-vpn wizard_dyn_vpn
set security dynamic-vpn clients wizard-dyn-group user admin
set security dynamic-vpn clients wizard-dyn-group user jeff
set security dynamic-vpn clients wizard-dyn-group user bob

Perhaps I’m missing something here but this seems like unnecessary double handling.

Junos requires the user to specify which remote networks the connected VPN user is able to access

set security dynamic-vpn clients wizard-dyn-group remote-protected-resources 192.168.1.0/24
set security dynamic-vpn clients wizard-dyn-group remote-protected-resources 192.168.100.0/24
set security dynamic-vpn clients wizard-dyn-group remote-protected-resources 192.168.77.0/24

The last part of this setup is the policy control for the remote user to the network resources. We need to make a policy from the external zone, to the zone where the the networks are within.

set security policies from-zone external to-zone internal policy policy_in_wizard_dyn_vpn match source-address any
set security policies from-zone external to-zone internal policy policy_in_wizard_dyn_vpn match destination-address any
set security policies from-zone external to-zone internal policy policy_in_wizard_dyn_vpn match application any
set security policies from-zone external to-zone internal policy policy_in_wizard_dyn_vpn then permit tunnel ipsec-vpn wizard_dyn_vpn

I always place this policy at the very end of the “from-zone external to-zone internal” because this policy catches source any, dest any and I don’t want to catch traffic that isn’t from a remote VPN.

Screen Shot 2014-02-17 at 10.36.37 pm
Now to test:

C:\Users\Perrin>ping 192.168.1.250
Pinging 192.168.1.250 with 32 bytes of data:
Reply from 192.168.1.250: bytes=32 time=55ms TTL=62
Reply from 192.168.1.250: bytes=32 time=60ms TTL=62
Reply from 192.168.1.250: bytes=32 time=128ms TTL=62
Reply from 192.168.1.250: bytes=32 time=124ms TTL=62
Ping statistics for 192.168.1.250:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 55ms, Maximum = 128ms, Average = 91ms
C:\Users\Perrin>

Have fun

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

WordPress spam blocked by CleanTalk.