Monday, 23 September 2013

SRX IPSec VPN - Dynamic (Client VPN) Part 1

In this post dynamic client based IPSec will be configured. This exercise assumes that basic system and IP configuration are already present and only contains configuration related to this specific task.

Dynamic Client VPN can be used to allow remote clients to securely connect to the SRX (Branch Series Only). By default, two dynamic-vpn licenses are included with any branch SRX. Juniper has two types of clients, Junos Pulse and Junos Access Manager. When running Junos version 11.1 or later the Junos Pulse client is provided to the client by the SRX. There were also historical requirements which made it mandatory to use RADIUS for authentication, however this is no longer the case as of Junos 10.4.

Upon initial connection to the SRX https interface the client will be downloaded and launched. Subsequent connections can happen the same way or the client can be launched directly once already installed.

The diagram below outlines the lab topology.


 Configure SRX
1. Create Access Profile, Address Pool and Firewall Authentication 
In this step the username/password, IP addresses for clients and authentication profile are created. Some of these steps will look similar to steps when configuring firewall authentication in security policies. Although not part of this exercise, RADIUS could be configured at this step. The screenshot below outlines the commands.


2. Configure IPSec Phase 1 Policy
This step kicks off the traditional IPSec configuration. The next four steps will look very similar to the steps found in the previous IPSec posts. The screenshot below outlines the IKE policy configuration.


3. Configure IPSec Phase 1 Gateway
In this step the IKE gateway is configured. There are some key components to understand when configured IKE gateways for dynamic VPN clients. 'dynamic hostname' is needed as the public IP address of the client is not static and not known by the SRX. 'ike-user-type group-ike-id' is needed to allow many (in this case two) clients to share the same IPSec configuration. 'xauth access-profile' is needed to obtain username/password information and to push client IP/DNS information to the client. See below for details.


4. Configure IPSec Phase 2 Policy
This step outlines a typical IPSec policy configuration.


1. Configure IPSec Phase 2 VPN
This step outlines a typical IPSec VPN configuration.


5. Configure IPSec Dynamic VPN
This step is needed to associate the configured users with the IPSec VPNs. The access profile created in step 1 is referenced here. The command 'remote-protected-resources' outlines the prefixes that should use the IPSec tunnel on the client machine. The command 'remote-exceptions' outline prefixes which should NOT use the tunnel. Lastly the VPN is referenced along with the configured user. See below for CLI commands.


6. Create Security Policies
In this step the security policy is configured. Only policy based VPNs are supported for dynamic client VPN.


7. Configure Proxy-ARP
Proxy-arp is needed so the SRX can respond to ARP requests on behalf of the remote client. This will allow traffic destine for the remote client to be forwarded to the SRX.


8. Modify Host-Inbound-Traffic
Two services need to be allowed to the SRX device. IKE allows the IPSec VPN to form to the SRX device, and HTTPS allows the remote user to launch the initial session to the HTTPS portal page.

9. Enable HTTPS Service
The HTTPS daemon needs to be running for client VPN access to work. This service needs to be enabled under system services web-management. To ensure that only VPN access is used on the external interface (and not J-Web) the management interface can be specified. This ensures that J-Web can only be used on the internal interface of vlan.192 even though HTTPS is allowed on both internal and external interfaces. See the screenshot below for command details.

The chart below outlines the web-management behavior in releases 10.4 and later.


 Verify Operation
1. Launch VPN (Web)
The screenshot below outlines the external web page for connecting to the client VPN.


The client is launched and the remote user has access to the 192.168.1.0/24 segment. Alternatively the user can manually install the client from a link provided on this page if there were issues with the automatic launch in the previous step.

Junos Pulse can also be used to connect to the SRX. When using Junos Pulse you do not need to browse to the HTTPS site, you simply enter in the information and log in. When using Junos Pulse you will need to enter your credentials twice. Ensure the type is set to SRX. The server URL will be the public IP address of the SRX. Note: "HTTPS://" is not required, simply enter the IP address alone. Alternatively DNS could be used so that a DNS name could be used to connect.  



 Verify Operation
1. Show IKE/Phase 1 Security Associations
The screenshot below outlines the Phase1/IKE security association.


1. Show IPSec/Phase 2 Security Associations
The screenshot below outlines the Phase2 security association. We can assume that this remote client is functioning normally as both security associations are up.


 Conclusion
In this post dynamic client based IPSec VPNs were configured. This allows a remote user to connect and gain access to specific internal networks. Traditional client based VPN solutions would call this 'split-tunnel' VPN as only select destinations use the encrypted tunnel. Forcing all traffic down the encrypted tunnel is also possible and will be examined in the next post.



Sunday, 22 September 2013

SRX IPSec VPN - Certificate Authentication

In this post digital certificates will be used to authenticate IPSec VPN tunnels. This exercise builds off of the existing configuration steps completed in the previous posts [SRX IPSec VPN - MultipointSRX IPSec VPN - Multipoint with OSPF, SRX IPSec VPN - Route Based]. Please feel free to reference these for additional IPSec details.

Public Key Infrastructure (PKI) is a set of components which allow you to use and manage digital certificates. We will only focus on a subset of PKI, specifically the components needed to securely authenticate VPN peers.

The diagram below outlines the lab topology.



Configure Certificate/PKI
1. Create CA Profile
The certificate authority (CA) is an entity that can sign digital certificates. The CA is a trusted source and it will contain a chain of trust all the way to a root CA. For the internet a root CA might be Entrust or VeriSign. For the example of this lab I used a Windows 2008R2 server with the role Active Directory Certificate Services running to act as the trusted CA. This CA needs to be configured on the SRX devices, the commands below outline the steps to configure a trusted CA. Keep in mind that in this example I used the server name as the ca-identity, this could also be a domain name/suffix. The screenshots below outline the commands.



2. Set CA Profile Revocation Check
Certificate revocation allows the CA to 'recall' certificates it has already issued. This could be for a number of reasons such as the device is no longer trusted. In the case of this exercise revocation is not used and the commands below outline the steps to disable revocation.



3. Generate Key Pair
In this step each SRX needs to generate a key-pair. In public key cryptography there are two parts, the private key which always remains on the device, and the public key which is sent to communicating parties. Getting into the details of public key crypto is out of the scope of this post. To keep it simple -  if one part of the key encodes (or signs) the other can decode and vice versa. The screenshots below outline the steps to generate key pairs on the SRX devices. Note that this is done from the operational command line interface (CLI).



4. Generate Certificate Request (CSR)
The next step is for the SRX devices to have a certificate signed by the trusted CA. To do this a request must be sent to the CA for processing. In the request device/organizational parameters can be specified, one domain name, email address or IP address must be specified. Optionally you can include subject items. Once processed the CA will return a signed certificate to the SRX device. In the case of this exercise this was done out of band (files were copied to USB and moved), but in real world deployments would happen in band via email or automated methods. The screenshots below outline the CLI command to generate the CSR.



5. Load CA Certificate
Once the CSR step is complete and the CA has generated the certificates they will need to be loaded on each SRX device. The first one is the CA certificate. Installing the CA certificate allows the device to validate the chain of trust. The screenshots below outline the commands to import the certificate. The certificates were copied from the CA to the SRX with a USB stick.



6. Load Local (signed) Certificate
The second certificate is the CA signed certificate for the local device. This allows the local device to contain a certificate which is trusted/signed by the CA. As in the previous step this certificate was copied from the CA with a USB stick and loaded on to the SRX devices. The commands below import this certificate.




7. Show Local Certificates
The command below displays the local signed certificate information on the SRX devices.



8. Verify CA & Local Certificates
The commands below allow the certificates to be verified against the CA to ensure proper chain of trust. This concludes the steps related to PKI configuration, the remaining steps are IPSec VPN configuration.




Configure IPSec VPN
1. Create Phase 1 Proposal
In previous posts the 'standard' proposal has been used. In this post a custom proposal is used to outline that the authentication method is now rsa-signatures (instead of pre-shared key). The following screenshot outlines the commands to create the phase 1 proposal.



2. Create Phase 1 Policy
In this step the phase 1 policy is created. Local and peer certificates are configured (instead of pre-shared key values).



3. Create Gateways
In the following screenshot IKE gateways are configured. IP addresses are not mandatory as certificates are being used, in the example below host-name is used instead of IP address. In this case DNS on all devices must be configured properly so that the name can be resolved to an IP address.




4. Create Phase 2 Policy, VPN and Security Policies
See details in post SRX IPSec VPN - Multipoint for detailed steps. These steps will be the same regardless of pre-shared key vs. certificate based authentication.


Verify IPSec Operation
1. Show Phase 1 Security Associations
The screenshots below outline that Phase 1&2 security associations have formed properly.




Conclusion
Certificate based IPSec VPNs are more complex and require more infrastructure to operate. Large VPN deployments or deployment with specific requirements may want to use certificate based VPNs for some large scale efficiency gains, for the average small scale deployment pre-shared key is the simplest and might be the best way to go.