Juniper : Netscreen Remote Dial-UP VPN with AD Radius Authentication and route based VPN / tunnel interface

The following procedure explains how to set up a Juniper ScreenOS based firewall to accept Netscreen Remote Client VPN connections and authenticate users using Active Directory (Radius via Windows 2003 IAS or Windows 2008 NPS). 

We’ll assume that all traffic to from the client to the 192.168.0.0/16 networks needs to pass via the client VPN tunnel.  Clients will use dynamic IP addresses (either public or behind a nat router that is capable of handling IPSec passthrough)

The VPN connection must use the following encryption and hashing parameters  and PSK :

• Phase 1 :  aes-128, sha-1, DH Group2, PSK : This1sNot4GoodPSK3y
• Phase 2 :  aes-128, sha-1, replay protection, PFS with DH Group2

Network layout :

The Juniper firewall has 3 zones : Public (eth2, connected to the internet, static public IP), LAN (eth1, connected to the LAN) and a separate zone called VPNBuffer, not attached to any interface.  This is just an empty zone, a placeholder, so we can create proper policies (instead of defining policies from Public to LAN, we will be able to use policies from VPNBuffer to LAN, thus separating the internet-to-lan traffic policies from the vpn-to-lan policies.  It just looks better… )

All interfaces are in route mode.

In the LAN network, there is a Domain Controller at 192.168.0.6, which will be configured as IAS (Radius) server. (The IAS does not need to be a DC, just a domain member will do)

This is what needs to be done

• Juniper : Configure an auth server (Radius)
• Windows : Set up Radius 
• IAS on Windows 2003  or
• NPS on Windows 2008
• Juniper : Define IP Pool / Subnet
• Juniper : Create tunnel interface
• Juniper : Set up routing
• Juniper : Define IKE user/group and External Group for XAuth (Radius)
• Juniper : Set XAuth defaults
• Juniper : Configure Phase 1
• Juniper : Configure Phase 2
• Juniper : Configure policies
• Client : Configure Netscreen Remote
• Client : Connect

Configure auth server

Configuration – Auth – Auth Servers – New

• Set a name for the Auth Server
• Set IP address of server that will be running IAS (Radius)
• Set account type to XAuth
• Set Source Interface to the LAN interface (eth1)
• Enable Radius and set Shared Secret
• Save new Auth Server

Windows 2003 : Set up IAS/Radius

As explained in one of my previous blog posts, IAS is a part of Windows Server. At this point, I will assume you have been able to install the IAS Component on your server, and that you have changed the authentication port to 1645, and the accounting port to 1646 (and that you have restarted the IAS service)

Under IAS, open “Radius Clients”, right-click and add a new Radius client. Enter the IP address of the LAN interface of the firewall (192.168.0.30 in our case. Note : if you have defined a manage-ip that is different than the interface IP, you will need to use this IP).  Client-Vendor is Radius Standard.  Enter the Shared Secret that was entered in the Juniper Auth Server definition. Press Finish to complete the creation of the client.

The final step is to create a policy where you will determine whether a given user should be granted access to VPN or not. You can use Windows AD Groups for this.   First, in AD, create a group that will contain your VPN users. 

Let’s say we’ll use a group called Juniper.VPN.Users, and added a couple of user accounts in there.

The idea is now to create an IAS policy that will allow members of this group to be granted access.

In IAS, open “Remote Access Policies” and remove any default policies that may be in there.  (Just don’t delete the “Use Windows authentication for all users” under “Connection Request Policies” (which can be found under “Connection Request Processing”.

In the “Remote Access Policies” section, right-click and choose “New remote access policy”.

Click next at the welcome screen.  Next, choose “Set up a custom policy” and provide a relevant name

In the Policy Conditions Window, click “Add”. Select “Windows-Groups” and click “Add”. Click “Add” to add your newly created AD group. Click OK to save.

Click next. Select “grant remote access permission” and click next. 

Click “Edit profile”. Go to the authentication tab. Make sure only PAP/SPAP is selected.  In the Advanced Tab, remove the default attributes (Service-Type and Framed Protocol"). Click “Add” to add a new attribute. Select “Vendor-specific” and click Add to add a new attribute.   Click Add to add a new value.  Set Vendor Code to 3224, select “Yes, it conforms” and Click “Configure Attribute”

In the Configure VSA (RFC Compliant) screen, set Vendor-assigned attribute number to 3, set Attribute format to “string” and enter a string that will be sent to the Juniper firewall upon succesfull authentication. This string needs to match with the name of an external group that will be created on the Juniper. You are free to pick whatever string you like, but I usually use the name of the AD group (so I know that this group matches with an AD group).  So we’ll set the string to “Juniper.VPN.Users”

Click OK to save, Click OK, click Close, click OK. Accept the warning. Click next and click Finish.

At this point, the Windows environment is ready to authenticate VPN users.  If you want to set up Radius on a Windows 2008 server instead of 2003, read the next chapter (otherwise, you can skip the next chapter and jump right back to the Juniper configuration)

Windows 2008 : Set up NPS/Radius

Of course, if you are running Windows 2008, you can also use NPS (which replaces IAS) to achieve the same goal. This is how it works :

First, add the required roles on the server that will acts as Radius server. This does not need to be a DC. If the server is part of the domain, it will work just fine

Open Server Manager and add a role

Select Network Policy and Access Services and click next

Click next again

Select Network Policy Server (NPS) and click next

Click Install. Click ‘close’ when the installation has completed.

Open a MMC and add the NPS snap-in (Local Computer)

First, change the Radius port to 1645. Right-click on NPS (Local) and choose properties

Go to the ports tabsheet and set Authentication to port 1645 only,  and accounting to port 1646 only. Click OK to save. use the Action pane on the right to stop and start the NPS service (or use “Services” to restart the NPS service)

Open Radius Clients under NPS (Local) – RADIUS Clients and Servers, right-click and choose ‘New Radius Client’

Fill out the name, IP address of the Juniper firewall and set the Shared Secret. Leave the Vendor name as Radius Standard

Open “Network Policies” under “Policies” and remove the 2 default policies called “Connections to Microsoft Routing and Remote Access server” and “Connections to other access servers” (or just make sure they are disabled)

Then, add a new policy

Set a name and leave the type of network access server to Unspecified

Click Next

Under “Specify Conditions”, click “Add” and select “Windows Groups”. Click “Add” again

Click “Add Groups” and add the AD Group that contains the VPN users (Juniper.VPN.Users in my case)

Click OK

Click Next

Set Access Permission to “Access granted” and click Next

Authentication methods : deselect everything, except PAP, SPAP

Click Next. Click “No” when asked to see the corresponding Help Topic

Constraints : do not set constraints (unless you know what you are doing). Just Click next

Configure Settings :  Under “Standard”, remove the Framed-Protocol and Service-Type Attributes

Go to Vendor Specific and click Add

Set Vendor to All and select “Vendor-Specific” from the list. Click Add

Click Add again

Set Vendor Code to 3224. Select Yes. It Conforms

Click “Configure Attribute”

Set attribute number to 3, set format to String, and set Value to Juniper.VPN.Users

Click OK

Click OK again

Verify that the new attribute is in the list and click OK again

Click Close

Click Next. Review the configuration settings

Click Finish

That’s it

Juniper : Define IP Pool / Subnet

The goal is to assign IP addresses to Netscreen remote clients upon connecting to the Juniper via VPN. We’ll have to create an IP Pool for this.  We will use 192.168.99.1-192.168.99.254 (which is in fact the 192.168.99.0/24 network) :

Objects – IP Pools – New

Note : this IP Pool should not overlap with any addresses in your network !

Juniper : create tunnel interface

We will use route based VPN, so we need to create a tunnel interface.  This will allow us maximum flexibility, will allow us to put the VPN endpoint in the VPNBuffer zone, etc :

set int tunnel.3 zone VPNBuffer
set int tunnel.3 ip unnumbered interface eth0/2

get int tun.3
Interface tunnel.3:
  description tunnel.3
  number 20, if_info 1784, if_index 3, mode route
  link down
  vsys Root, zone VPNBuffer, vr trust-vr
  admin mtu 1500, operating mtu 1500, default mtu 1500
  *ip 0.0.0.0/0  unnumbered, source interface ethernet0/2
  *manage ip 0.0.0.0
  pmtu-v4 disabled
  ping disabled, telnet disabled, SSH disabled, SNMP disabled
  web disabled, ident-reset disabled, SSL disabled

  OSPF disabled  BGP disabled  RIP disabled  RIPng disabled  mtrace disabled
  PIM: not configured  IGMP not configured
  MLD not configured
  NHRP disabled
  bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
             configured ingress mbw 0kbps, current bw 0kbps
             total allocated gbw 0kbps

Juniper : set up routing

The IP Pool that we have created needs to be reachable.  So we need to create proper routing.  In fact, we need to send traffic towards the 192.168.99.0/24 network towards the new tunnel interface :

fw03-> set route 192.168.99.0/24 int tun.3
fw03-> get route | incl 192.168.99
         91    192.168.99.0/24          tun.3         0.0.0.0   S   20      1     Root

In addition to the route on the Juniper, all networks behind the Juniper need to be able to route back to the Juniper firewall in order to be communicate with hosts in the 192.168.99.0/24 network.  We’ll assume that all hosts in the 192.168.1.0/24 network use the Cisco router as default gateway, and the Cisco is configured to route everything to the Juniper firewall.  The Juniper firewall, in return, must have a route towards the 192.168.1.0/24 network, pointing to the Cisco.

fw03-> get route ip 192.168.1.1
 Dest for 192.168.1.1
--------------------------------------------------------------------------------------
trust-vr       : => 192.168.1.0/24 (id=87) via 192.168.0.8 (vr: trust-vr)
                    Interface ethernet0/1 , metric 0

Ok, routing looks good, let’s continue with the Juniper setup

Juniper : Define IKE user/group and External Group for XAuth via Radius

We’ll have to define an IKE user which will be used/shared by all Netscreen Remote clients. This will allow the client to set up Phase 1 of the VPN connection.  Since we want to allow multiple users to use the same IKE user at the same time, we’ll need to put this IKE user in a user group and set the number of simultaneous connections to a number larger than 1

This is how it works :

Objects – Users – Local – New

Set the username, select IKE User and Simple Identity.  Make sure the User Name and IKE Identity are the same.

Set the number of multiple logins to something higher than 1 (max. value is 25, if you need more, you’ll need to create multiple IKE users and spread the IKE users over your remote user base)

Set IKE ID Type to AUTO. Click OK to save

Next, create a group and place the ike user(s) in the group

Objects – Users – Local Groups – New

Next, go to Objects – Users – External Groups – New

The name of the group needs to match exactly with the value of the string that will be passed back from the Radius server upon authenticating.  This may or may not be the same name as the AD group (depending on how you have configured the attributes in IAS).  We have chosen to use the same name as the AD group name, which is Juniper.VPN.Users

Set the type to XAuth and press OK to save

Juniper : set XAuth Defaults

VPNs – AutoKey Advances – XAuth Settings

Set Authentication server to the Auth Server entry that was created earlier

Select the IP Pool and enter DNS/WINS settings. You need to set this because there is no other way to assign IP addresses to your VPN clients. If you don’t assign IP addresses, you will have lots of troubles getting the routing between VPN clients and your hosts to work properly.

Juniper : Configure Phase 1

VPNs – AutoKey Advanced – Gateway – New

Pick a name, select Dialup User Group and select the newly created IKE group

Click Advanced

Set the PreShared Key

Select the outgoing interface (which needs to be the public interface, so in our case this is eth0/2).  Set the Security Level to custom and select “pre-g2-aes128-sha).

Set the Mode to Aggressive. Enable NAT-T (this may not be required though – it depends on your setup)

Click Return and then OK to save

You may receive a similar warning :

Click OK to accept.  You should see the new Phase1 definition now.  Click on the Xauth link next to your new Phase1

Select XAuth Server, and set the Authentication type to Generic.

Enable External Authentication and pick the Auth server (for Radius) from the list

Select User Group and fill out the group name

Click OK to save

Juniper : Configure Phase 2

Go to VPNs – Autokey IKE – New

Set a new name and pick the Predefined Phase 1 that was created earlier

Click Advanced

Security Level : set to Custom and select g2-esp-aes128-sha from the list.

Enable Replay protection.  Bind the VPN to the tunnel interface that was created earlier. (tunnel.3 in our case)

Enable proxy ID. Set Local IP to 192.168.0.0/16 and Remote IP to 255.255.255.255/32

Make sure Service is set to ANY

Click Return and then OK to save

Juniper : Configure Policies

We want to allow remote clients to access 192.168.0.6 and 192.168.1.8

Since the tunnel interface is in zone VPN, we need a policy from VPNBuffer to LAN

We’ll create some objects first

fw03-> set address VPNBuffer NetscreenRemoteUsers 192.168.99.0/24
fw03-> set address LAN Server1 192.168.0.6/32
fw03-> set address LAN Server2 192.168.1.8/32

Next, create the policy (from VPNBuffer to LAN)

Source : NetscreenRemoteUsers

Destination : server1 (don’t add server2 yet)

Action : Permit (not tunnel !  We are using route based VPN, so action must be permit)

(screenshot contains entry for server2, but let’s assume it’s not there yet)

That’s it. We are now ready to configure the Netscreen Remote clients

Client : Configure Netscreen Remote

In the Security Policy Editor, create a new connection

Give the new connection a name (such as VPN to company)

Set the connection security settings to “Secure” and enable “Only connect manually”

Remote party ID : enter the IP subnet that is used in the Local IP Proxy ID of Phase 2

Enable Use Secure Gateway Tunnel and Set the IP Address to the public IP of the Juniper VPN (which is 1.1.1.1) in our case

Next, click on the + (plus) symbol next to the new “VPN to company” connection and select “My Identity”

Set Certificate to None. Set ID Type to Domain Name and fill out the IKE identity/IKE username string from the IKE user that was created earlier.

Click Pre-Shared Key and enter the Pre-Shared Key that was used when defining Phase 1

On the left hand side, select Security Policy

Select “Aggressive Mode”, enable PFS (DH Group2) and Enable Replay Detection

Open “Authentication (Phase 1)”, and select Proposal 1

Set authentication mode to Pre-Shared Key and Extended Authentication

Set Encrypt Alg to AES-128 and Hash alg to SHA-1

Set SA Life to seconds and enter 28800

Set Key Group to DH Group 2

On the left side, open “Key Exchange (Phase 2)” and select Proposal 1

Set SA Life to Seconds and enter 3600

Leave compression to none.  Enable ESP, set Encrypt Alg to AES-128 and Hash alg to SHA-1. Encapsulation = Tunnel. Leave AH (Authentication Protocol) disabled

Save the settings

Client : Connect

Try to connect : right-click on the Netscreen Remote Icon, choose “Connect” and select the new connection

You should get a User Authentication prompt. Enter a username (DOMAIN\User  or just the username) and the password of an account that is member of the AD Group

If you would have done a “debug auth radius” on the firewall while the Radius authentication took place, you should see that authentication was successful and that the XAuth group matches with the group that was passed back by the Radius server.

## 2009-01-22 21:41:12 : rad_parse() = rad_msg=0x02f50874{code=2, id=6, ...}
## 2009-01-22 21:41:12 : RadiusRecv: checking j:socket 75, socipv6 -1, sock 75, j:rad_id 6, rad_msg->id 6
## 2009-01-22 21:41:12 : RadiusRecv: Breaking for sock 75
## 2009-01-22 21:41:12 : is_resp_authenticator_valid: Valid Response authenticator
## 2009-01-22 21:41:12 : RadiusRecv: data on socket 75 for aq_ent 0x428db94, state 0x2, curr_server 1, curr_active 1
## 2009-01-22 21:41:12 : >>> rad_recv_auth(soc=3965916)
## 2009-01-22 21:41:12 : rad_attr_store_groups:adding first Juniper.VPN.Users
## 2009-01-22 21:41:12 : <<< rad_recv_auth() = rad_auth_resp=0x043123b0{authed=1 priv=0 role=0 id=6}
## 2009-01-22 21:41:12 : is_resp_authenticator_valid: Valid Response authenticator
## 2009-01-22 21:41:12 : radius_recv_auth_resp: RESPONSE AUTH VALID (was a Accept)
## 2009-01-22 21:41:12 : group_check_ok: ugx_name Juniper.VPN.Users, group_item_ptr 0x2c4f914, username corelan\peter
## 2009-01-22 21:41:12 : is_rad_group_in: compare Juniper.VPN.Users with Juniper.VPN.Users
## 2009-01-22 21:41:12 :  MATCHED
## 2009-01-22 21:41:12 : group_check_ok: ext group Juniper.VPN.Users present
## 2009-01-22 21:41:12 : radius_recv_auth_resp: auth 0x428db94, id 6,  GROUP MATCHED have Juniper.VPN.Users
## 2009-01-22 21:41:12 : radius_recv_auth_resp: auth 0x428db94, id 6,  AUTHENTICATED
## 2009-01-22 21:41:12 : rad_groups_free: freeing: next_item_ptr->group_name Juniper.VPN.Users
## 2009-01-22 21:41:12 : >>> RadiusRecv(aq_ent={un='corelan\peter', fl=3, as_id=2, rt=0, rt1=0, rt2=0})
## 2009-01-22 21:41:12 : <<< RadiusRecv(aq_ent={rad_state=7}) = 1
## 2009-01-22 21:41:12 : RadiusRecv: result 1
## 2009-01-22 21:41:12 : get_auth_radius_clnt_session_id: entered

Verify the VPN connection on the Juniper :

fw03-> get ike cookies 

IKEv1 SA -- Active: 1, Dead: 0, Total 1

1097182f/0006, 1.1.1.2:500->1.1.1.1:500, PRESHR/grp2/AES128/SHA, xchg(5) (IKE_NetscreenRemote/grp7/usr10)
resent-tmr 322 lifetime 28800 lt-recv 28800 nxt_rekey 28484 cert-expire 0
responder, err cnt 0, send dir 1, cond 0x30
nat-traversal map not available
ike heartbeat              : disabled
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 100
DPD seq local 0, peer 762132764

IKEv2 SA -- Active: 0, Dead: 0, Total 0

fw03-> get sa active
Total active sa: 1
total configured sa: 2
HEX ID    Gateway         Port Algorithm     SPI      Life:sec kb Sta   PID vsys
00008001<         1.1.1.2  500 esp:a128/sha1 a12260dd  3289 unlim A/-    -1 0
00008001>         1.1.1.2  500 esp:a128/sha1 1259e395  3289 unlim A/-    -1 0

fw03-> get sa id 0x8001
index 2, name ESP_NetscreenRemote, peer gateway ip 1.1.1.2. vsys<Root>
auto key. tunnel if binding node, tunnel mode, policy id in:<-1> out:<-1>
id hash: >00>ce>69>fb>fb>e3>2d>0e>76>44>4b>67>3c>9a>fa>0d>43>79>6d>b1
 vpngrp:<-1>. sa_list_nxt:<8>. parent_sa_id:<8>.
tunnel id 32769, peer id 0, NSRP Local.     dialup, dynamic member.   site-to-site. Local interface is ethernet0/2 <1.1.1.1>.
  esp, group 2, a128 encryption, sha1 authentication
  autokey, IN active, OUT active
  monitor<0>, latency: 0, availability: 0
  DF bit: clear
  app_sa_flags: 0x2400437
  proxy id: local 192.168.0.0/255.255.0.0, remote 192.168.99.1/255.255.255.255, proto 0, port 0
  ike activity timestamp: 887422404
  DSCP-mark : disabled
nat-traversal map not available
incoming: SPI a12260dd, flag 00004000, tunnel info 40008001, pipeline
  life 3600 sec, 3282 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x6, window 0x3f, idle timeout value <0>, idled 280 seconds
  next pak sequence number: 0x0
  bytes/paks:360/6; sw bytes/paks:360/6
outgoing: SPI 1259e395, flag 00000000, tunnel info 40008001, pipeline
  life 3600 sec, 3282 remain, 0 kb, 0 bytes remain
  anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 318 seconds
  next pak sequence number: 0x0
  bytes/paks:0/0; sw bytes/paks:0/0

Verify the XAuth sessions and verify that an IP was assigned to the VPN session :

fw03-> get xauth active

GW Name              Login           Auth By    GW IP           Private IP      Last Login     Session Timeout   Idle Timeout
IKE_NetscreenRemote   corelan\peter  AD Radius         1.1.1.2    192.168.99.1 255.255.255.255  2009-01-22 21:13:10         0      0 

Verify that the client can access resources in all networks :

Verify that it cannot access networks that are not allowed by the policy

Adjust the policy, add the 192.168.1.8/32 host (Server2) as allowed destination and see if traffic to the second network works as well :

---

Similar/Related posts:

Juniper Firewall ScreenOS Basics (CJFV) Using Active Directory and IAS based Radius for Netscreen WebAuth authentication Juniper ScreenOS BGP Basics : a simple iBGP test case IPSec VPN between Windows Server 2008 and Juniper ScreenOS Juniper ScreenOS : default route manipulations and redistributions