Security
Showing results for 
Search instead for 
Do you mean 

SSL VPN configuration on SRX running 15.1X49-D80.4 or higher

by Distinguished Expert on ‎04-13-2017 08:03 AM - edited on ‎04-19-2017 11:14 AM by Administrator Administrator (1,501 Views)

 

Starting with version 15.1X49-D80.4 the Juniper SRX supports dialup vpn over a connection to port 443 with the NCP client. It needs some specific configuration to get that working and we found out the hard  way. So, we have decided to share it here.  Thank you Valentijn and Jasper for helping me.

The situation we want to achieve is this one:

SSL-VPN-Final.png To prepare for configuring a demo setup you need two things: A gateway running a Junos version that supports this feature and a NCP client. You should know how to get and install the SRX software, you can get the client here: https://www.ncp-e.com/en/resources/download-vpn-client/ The configuration we’re about to make gives us a dialup vpn where the client tries to connect to with standard IPsec. If that fails it will try to move the connection to SSL, which in many networks is allowed to travel freely… Two profiles are configured to authenticate the user:
1) lpdap-users: to authenticate against the AD control on 172.27.72.10, domain wsa.local 2) local-users: In which two local users are defined.
Both profiles hand out IP addresses and DNS servers from the address assignment pool dyn-vpn-address-pool.
Please note we use rather weak proposals, just for testing purposes, in real life adjust them to your (companies) policy! Phase 1 config
set security ike proposal my_ncp_proposals authentication-method pre-shared-keys set security ike proposal my_ncp_proposals dh-group group2 set security ike proposal my_ncp_proposals authentication-algorithm md5 set security ike proposal my_ncp_proposals encryption-algorithm aes-128-cbc set security ike proposal ncp-client authentication-method pre-shared-keys set security ike proposal ncp-client dh-group group2 set security ike proposal ncp-client authentication-algorithm md5 set security ike proposal ncp-client encryption-algorithm aes-128-cbc set security ike policy ike_ncp_client mode aggressive set security ike policy ike_ncp_client proposals my_ncp_proposals set security ike policy ike_ncp_client pre-shared-key ascii-text <key> set security ike gateway ncp_test ike-policy ike_ncp_client set security ike gateway ncp_test dynamic user-at-hostname "vpnuser@wsa.local" set security ike gateway ncp_test dynamic ike-user-type shared-ike-id set security ike gateway ncp_test external-interface ge-0/0/0.0 set security ike gateway ncp_test aaa access-profile ldap-users * set security ike gateway ncp_test version v1-only set security ike gateway ncp_test tcp-encap-profile ssl-vpn * You can change this to profile local-users to authenticate the users locally instead of against LDAP. The last line of configuration tells the device to accept TCP encapsulated traffic according the mentionedprofile. Here is how to configure that profile: set security tcp-encap profile ssl-vpn log Since ike and tcp encapsulated traffic will arrive at the external interface, both should be accepted as host inbound traffic: set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone untrust host-inbound-traffic system-services tcp-encap Because we want ssl vpn traffic on the interface no other listener should be enabled on the interface: make sure system service web-management https is not enabled on the external interface. Enabling it on that interface would be a bad idea anyway. Let’s take a look at the authentication profiles, starting with the ldap profile: set access profile ldap-users authentication-order ldap set access profile ldap-users authentication-order password set access profile ldap-users domain-name-server 172.27.72.16 set access profile ldap-users domain-name-server 172.27.72.17 set access profile ldap-users client mtepper firewall-user password "$9$.PQ30ORSyK36pB1hKv4aJ" set access profile ldap-users address-assignment pool dyn-vpn-address-pool set access profile ldap-users ldap-options base-distinguished-name DC=wsa,DC=local set access profile ldap-users ldap-options search search-filter sAMAccountName= set access profile ldap-users ldap-options search admin-search distinguished-name CN=administrator,CN=Users,DC=wsa,DC=local set access profile ldap-users ldap-options search admin-search password "$9$Cze7uIheK87NbM8ZUDjq.uOB1SreKM" set access profile ldap-users ldap-server 172.27.72.10 port 389 set access profile ldap-users ldap-server 172.27.72.11 port 389 As you can see the administrator account is used here for a lookup. In real life you might want to create an account with just the necessary rights in the Active Direcory domain. Also note that you need to adjust the base-distinguished-name to your own domain.
For a simple test you could use a profile with local users like this:
set access profile local-users client jverdonk firewall-user password "$9$m5nCOBESlMz3EyeW-dZUjkmTQFn/Ap" set access profile local-users client mtepper firewall-user password "$9$xXNNbYDjqf5FYgGiHmF3cyr" set access profile local-users address-assignment pool dyn-vpn-address-pool Both profiles use the same address pool for address assignment configuring this pool isn’t a hard task as well: set access address-assignment pool dyn-vpn-address-pool family inet network 192.168.3.0/24 set access address-assignment pool dyn-vpn-address-pool family inet xauth-attributes primary-dns 172.26.72.16/32 set access address-assignment pool dyn-vpn-address-pool family inet xauth-attributes secondary-dns 172.27.72.17/32
This makes the configuration complete for phase 1 and phase 1½ (meaning for Xauth, which asks for authentication between phase 1 and phase 2). Time to look at phase 2 config then. According the documentation about SSL VPN we found a route based VPN with tunnel interface in point to point mode is needed to get things working. So, we configured this: An interface in the security zone trust (best practice for production is creating a zone called VPN and use that to make clear what happing in your policies) and an intrazone security policy: set interfaces st0 unit 0 family inet set security zones security-zone trust interfaces st0.0 set security policies from-zone trust to-zone trust policy default-permit match source-address any set security policies from-zone trust to-zone trust policy default-permit match destination-address any set security policies from-zone trust to-zone trust policy default-permit match application any set security policies from-zone trust to-zone trust policy default-permit then permit Finally for the SRX we can configure the phase 2: (As in phase 1 in real use stronger proposols!) set security ipsec proposal dialup-ncp protocol esp set security ipsec proposal dialup-ncp authentication-algorithm hmac-md5-96 set security ipsec proposal dialup-ncp encryption-algorithm aes-128-cbc set security ipsec proposal dialup-ncp lifetime-seconds 3600 set security ipsec policy ipsec_ncp perfect-forward-secrecy keys group2 set security ipsec policy ipsec_ncp proposals dialup-ncp set security ipsec vpn Ipsec_ncp bind-interface st0.0 set security ipsec vpn Ipsec_ncp ike gateway ncp_test set security ipsec vpn Ipsec_ncp ike ipsec-policy ipsec_ncp set security ipsec vpn Ipsec_ncp traffic-selector test local-ip 0.0.0.0/0 set security ipsec vpn Ipsec_ncp traffic-selector test remote-ip 0.0.0.0/0 The gateway is ready now, time to move to the client. After installing the software, start it and go into the configuration of a profile. Configure things like shown here: any tab not shown is left default!
p1.png

p2.png Replace the IP address (it’s so fake :) ) with your external address
p3.png PLEASE NOTE THE PATHFINDER SETTING HERE. THIS ENABLES SSL ON THE CLIENT SIDE! p4.png The ID matches the id you configured in phase 1. The preshared key should also match of course. You must select XAUTH but filling in the user id and password is optional. When you don’t fill them in, a pop-up box appears when connecting. By now the setup is completely done and we’re ready to connect! The relevant part of the config of the SRX should look like this:
security { ike { proposal my_ncp_proposals { authentication-method pre-shared-keys; dh-group group2; authentication-algorithm md5; encryption-algorithm aes-128-cbc; } proposal ncp-client { authentication-method pre-shared-keys; dh-group group2; authentication-algorithm md5; encryption-algorithm aes-128-cbc; } policy ike_ncp_client { mode aggressive; proposals my_ncp_proposals; pre-shared-key ascii-text "$9$MB7WdbUDk5T3P5M8"; ## SECRET-DATA } gateway ncp_test { ike-policy ike_ncp_client; dynamic { user-at-hostname "vpnuser@wsa.local"; ike-user-type shared-ike-id; } external-interface ge-0/0/0.0; aaa { access-profile ldap-users; } version v1-only; tcp-encap-profile ssl-vpn; } } ipsec { proposal dialup-ncp { protocol esp; authentication-algorithm hmac-md5-96; encryption-algorithm aes-128-cbc; lifetime-seconds 3600; } policy ipsec_ncp { perfect-forward-secrecy { keys group2; } proposals dialup-ncp; } vpn Ipsec_ncp { bind-interface st0.0; ike { gateway ncp_test; ipsec-policy ipsec_ncp; } traffic-selector test { local-ip 0.0.0.0/0; remote-ip 0.0.0.0/0; } } } policies { from-zone trust to-zone trust { policy default-permit { match { source-address any; destination-address any; application any; } then { permit; } } } } tcp-encap { profile ssl-vpn { log; } } zones { security-zone untrust { host-inbound-traffic { system-services { ike; tcp-encap; } } } security-zone trust { interfaces { st0.0; } } } } interfaces { ge-0/0/0 { unit 0 { family inet { address 1.2.3.4/24; } } } st0 { unit 0 { family inet; } } } access { profile ldap-users { authentication-order [ ldap password ]; domain-name-server { 172.27.72.16; 172.27.72.17; } client mtepper { firewall-user { password "$9$.PQ30ORSyK36pB1hKv4aJ"; ## SECRET-DATA } } address-assignment { pool dyn-vpn-address-pool; } ldap-options { base-distinguished-name DC=wsa,DC=local; search { search-filter sAMAccountName=; admin-search { distinguished-name CN=administrator,CN=Users,DC=wsa,DC=local; password "$9$Cze7uIheK87NbM8ZUDjq.uOB1SreKM"; ## SECRET-DATA } } } ldap-server { 172.27.72.10 port 389; 172.27.72.11 port 389; } } profile local-users { client jverdonk { firewall-user { password "$9$m5nCOBESlMz3EyeW-dZUjkmTQFn/Ap"; ## SECRET-DATA } } client mtepper { firewall-user { password "$9$xXNNbYDjqf5FYgGiHmF3cyr"; ## SECRET-DATA } } address-assignment { pool dyn-vpn-address-pool; } } address-assignment { pool dyn-vpn-address-pool { family inet { network 192.168.3.0/24; xauth-attributes { primary-dns 172.26.72.16/32; secondary-dns 172.27.72.17/32; } } } } }

 

Comments
by Distinguished Expert
on ‎04-18-2017 02:56 PM

Nice work Michel - this is something I've been meaning to investigate thanks for sharing your config!

According the documentation about SSL VPN we found a route based VPN with tunnel interface in point to point mode is needed to get things working. So, we configured this:

Does this mean that remote-access VPN on the SRX is now route-based instead of policy-based, regardless of whether you connect via SSL or IPSEC?  (Finally!!)

by Distinguished Expert
on ‎04-19-2017 07:07 AM

Hi Ben,

 

Yes: finally the dial-up vpn is route based. So happy with it! The only thing I don't really get is that the tunnel interface must be in point to point mode, but you still can use mulitple connections at the same time. I would think that that sounds as point to multimpoint mode. Maybe someone has details about this?

 

Michel

Contributors