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:
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-keysset 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 “[email protected]”
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!
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 "[email protected]"; 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; } } } } }