Creating a Site to Site IPSec VPN with a Palo Alto Networks Application Firewall and a Cisco Router

A site to site VPN allows networks in multiple fixed locations (branch offices) to establish secure connections with a Headquarters Datacenter network over the Internet. In this example we will configure a Palo Alto Application Firewall to establish an IPSec tunnel with a Cisco Router. I will not go into Cisco ios configuration, since there are many guidelines over the internet about it.

Let’s suppose that the headquarters network is 10.1.1.0/24 and a local internet address that will be used for the tunnel is 195.35.111.1, additionally the remote network is 10.2.2.0/24 and the remote peer internet address is 195.35.222.2.

Example Networks

Example Networks

First open up Palo Alto Networks gui and goto Network – Interfaces and create a new tunnel interface, let’s say tunnel.2. Type in the standard MTU size of 1500 bytes, leave empty the IP address since this is used for dynamic routing and tunnel monitoring purposes, select the allow ping Management Profile, select your virtual router and Zone internal since we will bring the tunnel to an internal subnet and finally press ok to save the settings.

The tunnel Interface

The tunnel Interface

Then select Network – Zones at the menu and edit the internal zone (that is bound to the interface on the internal network). The internal ethernet interface and tunnel.2 should be checked. Press ok to save the settings.

The internal zone

The internal zone

Now let’s configure the IKE phase1 parameters by going to Network – Network Profiles – IKE Crypto and create a new IKE profile (e.g. name it IKE_BRANCH) that matches with the remote Cisco router ISAKMP profile (crypto isakmp policy command). For example let’s do the following DH Group 2, Encryption aes128 and 3des, Hash Algorithm sha1 and Lifetime 8 hours (indicative only values). Some options are more secure than others, but more resource hungry and less faster.

IKE phase 1 parameters

IKE phase 1 parameters

For IKE Phase2 parameters goto Network – Network Profiles – IPSec Crypto and create a new IPSec profile (e.g. name it IPSEC_BRANCH) that matches with the remote Cisco IPSec parameters (crypto ipsec transform-set command). For example let’s configure ESP authentication md5 and sha1, ESP encryption aes128 and 3des DH Group no-pfs and lifetime of 3 hours (indicative only values).

IKE phase 2 parameters

IKE phase 2 parameters

Now click on Network – Network Profiles – IKE Gateways to setup the configuration information necessary to perform IKE protocol negotiation between local and remote peer nodes. Input a name for IKE Gateway e.g. HQ_TO_BRANCH, select the internet interface of your firewall and select your internet ip address (in our case 195.35.111.1), at the peer address input the branch office’s router internet address (in our case 195.35.222.2), leave the dynamic checkbox unchecked (if a dynamic address is required, check the box and select the FQDN hostname at the Peer Identification selection at the advanced Phase 1 options below). Then input the pre-shared key defined on both firewall and router devices. Press the Show advanced Phase 1 options to display more settings and leave Local and Peer Identification to none and the local/peer IP address will be used as the local/peer identification value, otherwise choose the right setting. Choose main at the Exchange Mode (this should match to the Cisco router setting as well).

Phase 1 negotiation can occur using one of two modes: main mode and aggressive mode. The two modes serve different purposes and have different strengths. Main mode is slower than aggressive mode, but main mode is more secure and more flexible because it can offer an IKE peer more security proposals than aggressive mode. Aggressive mode is less flexible and not as secure, but much faster.

Select the previously created IKE Crypto Profile and finally leave checked the Dead Peer Detection checkbox.

IKE crypto profile

IKE crypto profile

Next goto Network – IPsec Tunnels and create a new setting to combine all the previously created elements of IPSec tunnel. Give it a name (e.g. VPN_TO_BRANCH), select the previously created tunnel.2 interface, leave type setting to the recommended Auto Key, select the previously created IKE Gateway and some of the following settings will autoupdate to the correct values. Then choose the previously created IPSec Crypto Profile (e.g. IPSEC_BRANCH). Next you must define the ProxyIDs (this is a must), these are actually the subnets or hosts that should talk to each other, for example in our case Local Id is 10.1.1.0/24 and Remote Id is 10.2.2.0/24. Here you may restrict subnets or protocols and ports but this depends on your needs. Finally check the Replay Protection setting to detect and neutralize replay attacks.

IPSec tunnel parameters

IPSec tunnel parameters

ProxyIDs setup

ProxyIDs setup

Till here we have configured the needed VPN IPSec tunnel settings, next we should route traffic between the subnets and restrict access permissions.

First add a static route to your Virtual Router to route the traffic from the Headquarters to the Branch Office, as follows.

Virtual router static route

Virtual router static route

Then you should configure the access permissions between the peer nodes by going to Policies – Security. The minimum configuration should be the icmp, ike, ipsec and ping permissions between the peer nodes, as follows.

Peer nodes access permissions

Peer nodes access permissions

Finally configure the permissions between the subnets. For example your may open up the traffic from the Headquarters subnet to the Branch Office subnet, or give access to workstations in Branch Office to specific services at the Headquarters.

Services access permissions

Services access permissions

If you configure the Cisco router accordingly the tunnel should come up. Check it out by going to Network – IPSec Tunnels, the status icons should have turn green!

IPSec tunnel status

IPSec tunnel status

You may need to goto Monitor – System to view the system log during IKE negotiations. This will help you to troubleshoot the IPSec tunnel errors on Palo Alto Firewall side.

VPN IPSec tunnel system logs

VPN IPSec tunnel system logs

On Cisco side use the show crypto isakmp, show crypto ipsec and show crypto map commands with the relevant flags for troubleshooting.

Advertisements

Integrating Duo Security two factor authentication in Palo Alto Network’s SSL VPN

A few days ago we configured SSL VPN in Palo Alto Networks Next-Generation Firewall. Now we will modify the setup to introduce Duo Security’s two factor authentication. Duo’s two factor authentication enables users to secure their SSL VPN portal logins using their smartphones. A free smartphone application (for iPhone, Android, Blackberry or Windows device) can generate passcodes (just like the hardware token devices) or can use Push technology for one-tap login approval. Duo Security’s website is full of information on how this technology works!

We will start with the installation of Duo Security’s Authentication Proxy and we will modify our Palo Alto setup to implement two-factor authentication. A detailed integration manual is available at this link, but it misses an important setting that took me a long time to figure it out.

First signup for a Duo account, goto integration page and create a Palo Alto SSL VPN integration to get the key, the secret key and the API hostname. Then download the Duo Authentication Proxy for Windows. In our example, we installed the application on a Windows 2008R2 server by following the wizard setup screens. After that, we configured the proxy by editing the “C:\Program Files (x86)\Duo Security Authentication Proxy\conf\authproxy.cfg” configuration file and following the guidelines of the aforementioned integration manual to configure the various parameters. But there is a more detailed reference guide for the authentication proxy at this link.

A simple configuration file looks like this:

[main]
client=ad_client
server=radius_server_iframe

[ad_client]
host=192.168.1.1 (the ip of the primary DC)
host_2=192.168.1.2 (the ip of a secondary DC)
service_account_username=serviceaccount (the AD account that runs AuthProxy service and reads from AD)
service_account_password=******** (the password of the previous account)
search_dn=OU=MyOrganization,DC=MyCompany,DC=local (your base DN that your SSL VPN accounts live in)

[radius_server_iframe]
type=paloalto
api_host=api-abcdefg.duosecurity.com (provided by Duo Security)
ikey=************* (provided by Duo Security)
skey=************* (provided by Duo Security)
failmode=secure
radius_ip_1=192.168.1.3 (Active High Available PA node)
radius_secret_1=************ (RADIUS key)
radius_ip_2=192.168.1.4 (Secondary High Available PA node)
radius_secret_2=************ (RADIUS key)

When we used this configuration, our SSL VPN connections failed due to wrong credentials. Further examination of the log files showed that the problem resided on the Active Directory authentication. We had to edit the log on parameter of “Duo Security Authentication Proxy” service and replace the Local System account to the configured  AD serviceaccount in order to authenticate us properly! Unfortunately this is not mentioned in Duo Security’s integration manual.

Setting up the service account

Setting up the service account

The setup on Palo Alto’s side is pretty straight forward. First goto Device – Server Profiles – RADIUS and make a new one, for example Duo RADIUS Profile and type in the server the Duo Security Authentication Proxy service resides, the shared key for the communication between the two devices and leave the port to 1812.

RADIUS Profile

RADIUS Profile

RADIUS Profile Overview

RADIUS Profile Overview

Next create a new Authentication Profile e.g. SSLVPN_RADIUS_w_DUO, insert your desired lockout parameters and edit the allow list by inserting your SSL VPN users. Finally select Authentication “RADIUS” and as a Server Profile, the one that we created before, Duo RADIUS Profile.

Authentication Profile

Authentication Profile

Authentication Profile Overview

Authentication Profile Overview

Finally, Goto SSLVPN Profile and select the new Authentication Profile we just created, SSLVPN_RADIUS_w_Duo. Commit the changes and you are ready to go!

Don’t forget to insert your SSL VPN users in your Duo Security website account, insert their mobile phones and enable the Duo Push action following the detailed guides on Duo’s website.

Configuring SSL VPN in Palo Alto Networks Next-Generation Application Firewall

An SSL VPN (Secure Sockets Layer virtual private network) is a form of VPN that can be used with a standard Web browser. It is used to give remote users with access to internal network services, client/server applications, intranet web services etc. It provides a secure communications mechanism for data transmitted between two endpoints since the traffic is encrypted by the SSL protocol. Palo Alto Networks‘ devices provide an integrated SSL VPN service. In this post we are going to configure such a service.

First, download and activate the SSL VPN client in the PAN device, by selecting Device – SSL VPN Client.

Downloading and activating the SSLVPN Client

Downloading and activating the SSLVPN Client

Next, go to Network settings – Interfaces and configure the external ip address that the SSL VPN portal will listen by creating a new loopback interface (loopback.1 in this example).

Configuring the external ip address

Configuring the external ip address

Let’s select MTU=1500, Management profile=allow ping, ip address 195.35.125.220 and select the already configured virtual router that PAN device uses, vr1 in this example. Next, go to Network – Zones and create a new SSL VPN Zone.

Creating the SSLVPN Zone

Creating the SSLVPN Zone

Give a relevant name to the zone (e.g SSL-VPN), select Type=Layer3 and check out the interface created previously (loopback.1). In this screen you can define any ACL lists you may need to. Next, go to Device – Authentication Profiles and create a new one.

Creating a new Authentication Profile

Creating a new Authentication Profile

In this screen, give a relevant Profile Name (SSL-VPN Profile) and define the Lockout settings (e.g. after 5 unsuccessful attempts lock the user for 5 minutes). Also you should define the users that can authenticate in the SSL VPN Portal by unselecting the All checkbox and editing the Allow List with the users imported from a local Active Directory. This means that you have already imported the user list using a PAN Agent running as a service at a local server. In this example, we will configure users from the local DB, so at the bottom of the screen, select Local DB and leave the Allow List to All setting. Next, go to Network – SSLVPN Profiles and create a new one.

Creating a new SSLVPN Profile - General

Creating a new SSLVPN Profile – General

Select a Server SSL Certificate (for testing reasons you can create a test certificate from PAN device, but in production environments you must purchase a SSL Certificate from a 3rd Party CA). Unfortunately, PAN device cannot create a request CSR file to submit to a Certification Authority, so you need to create a CSR from a server or another device. I prefer to create such a CSR file and the corresponding private key file from a Citrix Netscaler virtual appliance, but this is another story. Then select the Authentication Profile created previously. Set the max users and check Enable IPsec and Redirect HTTP traffic to HTTPS login checkboxes. Select Loopback.1 interface and now you can choose the external ip address of the SSL Portal, i.e. 195.35.125.220 in this example. The final settings in this screen configures the login lifetime and inactivity logout parameters. Then select the Client Configuration tab.

Creating a new SSLVPN Profile - Client Configuration

Creating a new SSLVPN Profile – Client Configuration

In this page type in the ips of the internal DNS servers and the DNS suffix of your internal domain. The IP Pool is the address space that each SSl VPN client pc take a seat (like a DHCP address space) and the Access Route is the address space of your internal domain that the VPN client will access to. Since we use a Local DB authentication type we must create a local user in PAN device, so go to Device – Users and create one.

User creation at local DB

User creation at local DB

Finally you must set up the static routes at your virtual router (from the Pool network to your internal one and vice versa)

Virtual Router Settings

Virtual Router Settings

and permit the connected SSL VPN clients to access the services of your internal network. At least, you should open the DNS application from IP Pool network (192.168.110.0/24) to your DNS servers and then any other applications that you need to expose to the SSL VPN client pcs. In the next example the first rule permits only the adsl ip to connect to the SSL VPN Portal enabling IPSec as well, and the other two rules expose DNS and Web services to VPN clients.

Permissions Rules

Permissions Rules

SSL VPN can be secured by using a two-factor authentication mechanism, using 3rd party services such as Phonefactor or Duo Security. These services provide free trial solutions for 10 to 25 people by authenticating VPN access using a land or mobile phone.