Juniper Networks devices such as the Secure Access (SA) series 2000, 4000 or 6000 follow a similar setup pattern that will be roughly jotted down here for future reference. This guide will note the steps up to getting the VPN working via IPSec with bonus instructions on running the SA behind a firewall with all the necessary port forwarding. Most of the information here has been scavanged from a multitude of sources since even the official guides are incomplete - on the other hand the SA VPN devices are feature-loaded devices and probably too complex to cover back-to-back.

Juniper Network devices have been said to contain embedded NSA backdoors that have now been leaked and most likely acquired by third parties.

• Optional A router capable of NATing ESP/AH and TCP/UDP ports,
• A Juniper Networks device SA-series (2000, 4000, 6000, etc…) running JunOS IVE,
• A computer with a serial port or an FTDI serial to USB device.
  • In case a computer with a serial port is available, a simple female-to-female null-modem serial cable is needed.
• The openssl package and access to a command line (Linux or Windows via ports).
• A public IP address and a domain name.

Once you have received your Juniper Networks device, connect the internal ethernet port to a switch and then connect the female-to-female null modem cable to a PC.

Using either PuTTY or Termite, configure a serial connection using the following parameters:

• COM port: varies (use Device Manager on Windows to find out to which COM port your RS232 socket is bound to),
• Baud: 9600,
• Data Bits: 8,
• Parity: None,
• Stop bits: 1,
• Handshake: none

Open the connection to the serial port and tap carriage return (Enter) a few times to initialize the connection. If the cabling is correct, writing should show up on the terminal. If no writing shows up after tapping Enter, then most likely the connection parameters or cable is at fault.

A banner with a greeting will show up and a menu with options to pick from. Select System Operations, followed by Clear all configuration data at this Junos Pulse Secure Access Service - note that this will remove any licenses you may have installed so be sure to have a backup. Once confirmed, the SA should reboot itself and enter an initial configuration phase; mostly involving the administrative password and networking parameters.

Creating a certificate is part of the initial configuration phase but this certificate will be removed and recreated later during this guide so it is not that important how it is set up at this stage. Proceed with the initial configuration phase till the end and reboot if prompted.

Navigate to the URL http://<SA>/admin (where SA is the hostname or IP address of the SA device) and log in as an administrator.

When the administrative interface has loaded, follow the task guide to set the task guide and other options if you are so inclined. Since the device configuration has been wiped, all settings are now at their defaults and the device already has a working minimal configuration that must be adjusted.

Even thought the initial configuration through the serial port would have had generated a certificate, we will now replace the certificate with a custom certificate signed by a generated CA certificate. The reasons for doing this is that there is no access granted to the CA used to sign the certificate generated during the initial configuration phase over the serial port. By creating a custom CA and signing a certificate signing request (CSR), the custom CA can then be imported into trusted certificate stores for various operating systems.

In order to do so, navigate using the web interface to Configuration→Certificates→Device Certificates and click the New CSR… button. Fill in the fields as best as possible whilst entering the public domain name for the Common Name field - the other parameters are up to you.

Enter some random characters for entropy and then click Create CSR. The certificate signing request will now be available in a textfield so copy the text into a text editor and save it to a file named SA.csr.

Now the OpenSSL software package will be used to create a CA key:

openssl genrsa -out rootCA.key 4096

where:

• 4096 is the desired key length

and the matching CA certificate:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt

where:

• -days 1024 is the validity period of the CA in days; this parameter can be omitted if so desired

Now we have a CA certificate which we will use to sign the certificate signing request from the SA and generate the certificate for the SA:

openssl.exe x509 -req -in SA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out SA.crt -sha256

where:

• SA.csr is the certificate signing request obtained from the SA web interface,
• rootCA.crt is the CA certificate,
• rootCA.key is the CA certificate key,
• SA.crt is the certificate that will be generated for the SA,

Now open up the SA web interface, log-in as an admin and navigate back to Configuration→Certificates→Device Certificates. Click the certificate signing request that you have generated previously and upload the SA.crt file.

Finally, navigate to Configuration→Certificates→Trusted Server CAs and import the rootCA.crt file into the store.

The SA is now configured to present your custom certificate signed by a certificate authority (CA) that is under your control. One advantage is that if you have multiple hostnames that you wish to access the SA with, then a new CSR can be created and then signed with the same CA.

On Windows, the CA can be imported into the Trusted Root Certification Authorities by using the import wizard. Press the start menu, and run mmc.exe to open up the Microsoft Management Console. On the menu, click File followed by Add/Remove Snap-In… and select Certificates. When prompted, select Computer account to open up the computer certificate store. Follow the wizard till the end by accepting the default settings till you see the Console Root tree listed in the left pane of the MMC.

Expand Certificates (Local Computer)→Trusted Root Certification Authorities→Certificates and right-click the expanded Certificates folder. Select All Tasks→Import… and select the rootCA.crt generated in the previous step. Follow the wizard till the end by accepting the default settings.

By default, the SA is configured to use Network Connect which has some serious issues on more modern machines due to requiring Java which has been removed from all major browsers. Nevertheless, the Junos Pulse Client can be used instead which is a self-standing application that can be downloaded by your clients.

Using the web interface, navigate to Users→Resource Policies→Split-tunneling Networks and click New Policy…. Enter a name you desire for the policy, for instance Local Network and enter the IP and netmask for your local network in the Resources box (ie: 192.168.1.0/255.255.255.0). All other defaults are alright so click Save Changes to save the changes.

Follow the menus Users→Resource Policies→Connection Profiles and click New Profile… to create a new profile. Enter a name you desire, for instance Local Network and then proceed to the IP address assignment. When clients connect to the SA VPN, they will have to be assigned an IP address - otherwise, Junos Pulse will report that no IP address could be assigned to connecting VPN clients. There are two ways to assign IP addresses: by proxying DHCP requests to a DHCP server on the local network or by creating a new address pool. After configuring the IP assignment, all the other defaults are fine so click Save Changes to store the modifications.

From the web interface, follow the menus Users→User Roles and click the Users role. Scroll down to enable IKEv2 and save the changes. Follow the menus Users→User Roles→Network Connect and switch from Network Connect to Junos Pulse. Enable split tunneling and optionally route monitoring. If you wish to set the SA as the default route for connecting clients then optionally switch the Route Override to Yes from No - otherwise, if you just want to allow clients to access resources via the SA, leave the Route Override to No. All other defaults are fine, so click Save Changes.

To create a user, navigate the menus to Users→Auth. Servers and click System Local - "System Local" is the built-in SA accounting authentication server and it is local to the SA machine you have configured. Alternatively, you can also use Active Directory Services (AD) or RADIUS for authentication, however, the KISS principle is maintained for this guide.

After clicking System Local, change the absurd Maximum length limitation by removing the digit from the textbox and tick the box Allow users to change their passwords (if you would like to allow that). Finally, click Save Changes to apply the settings.

Navigate to Users→Auth. Servers→System Local→Users and click New… in order to add a new user.

There is very little documentation pertaining to running the Juniper SA behind a firewall. It is perhaps possible to use Apache to reverse proxy the connection to the domain name for the SA but a safe choice is to pass all HTTP(s) traffic to the SA itself from the public interface.

If Linux is the front facing firewall, then NAT-ing the SA can be achieved via the rules:

iptables -t nat -A PREROUTING -i <EXT>-p tcp -m multiport --dport 80,443 -j DNAT --to <SA>
 
iptables -t nat -A PREROUTING -i <EXT> -p ah -j DNAT --to <SA>
iptables -t nat -A PREROUTING -i <EXT> -p esp -j DNAT --to <SA>
iptables -t nat -A PREROUTING -i <EXT> -p udp --dport isakmp -j DNAT --to <SA>
iptables -t nat -A PREROUTING -i <EXT> -p udp --dport ipsec-nat-t -j DNAT --to <SA>

where:

• <EXT> is the external interface and,
• <SA> is the internal IP address of the SA.

Log out from the admin website and navigate to https://<SA>/ in order to reach the user login. Log in with the newly created user, download the Junos Pulse Client for your platform and install it.

When running Junos Pulse, the client will require you to enter an URL, the URL is just the URL to the user login of your SA: https://<SA>/. Enter the username and password and connect.

The SA tends to log extensively and all logs can be found by navigating to the menus: System→Log/Monitoring - of particular interest whilst testing, perhaps, is the User Access log that will reveal more details on failed logins.