What more can my firewall do? Virtual Private Networks!

We've come a long way since first unpacking that awesome firewall. Now you're ready to set up Virtual Private Networks (VPNs). Where do you start? Tom's prepared not only the step-by-step procedures for setup, but a checklist for your prework, too. Let's take a closer look at Virtual Private Networks and how to configure them on your Palo Alto Networks firewall. We'll highlight a couple of differences that will help you set up an encrypted tunnel with route-based or policy-based VPN peers and show you a some troubleshooting tricks to get you up and operational quickly.

A VPN is a technology that creates a secured network connection over a traditional network by encrypting all communication between two hosts. We'll take a look at how to set up a site-to-site tunnel that uses strong IPSec encryption.

When preparing for a site-to-site VPN configuration, many times you will need to have a conversation with the remote administrator, which can be a coworker or a complete stranger. You first need to negotiate how you will be setting up your tunnel, which protocols to use, and so on. To facilitate this process, it is a good idea to prepare a little checklist:

• Does the remote peer have a static IP address or a dynamic one?
• What is the remote subnet?
• IKEv1 or IKEv2?
• Pre-shared key or certificate authentication?
• Is NAT traversal required (is one of the peers located behind another gateway that performs NAT)?
• Is the remote peer route-based or policy-based?

and 2 sets of the following attributes, one for the IKE configuration and one for the IPSec.

• Which authentication algorithm will be used (sha1, sha256, ...)?
• Which encapsulation algorithm will be used (3des, aes, ... )?
• How strong does the key in the key exchange need to be (Diffie-Hellman group 1, 20, .. )?
• What will the key lifetime be?

Knowing the details will make the configuration much easier. I'll highlight what implications some of these can have in the configuration examples below:

One of the first things you can do after negotiating with your counterpart, or having decided for yourself if you are able to manage both points, is to prepare the Crypto profiles.

Go to the network tab and add a new profile in both the IPSec Crypto and IKE Crypto profiles:

Next you will need to create the peer object representing the remote gateway and the IKE properties shared with this gateway to allow IPSec to be negotiated. Go to IKE Gateways profiles on the Network tab and create a new IKE gateway object.

On the General tab, you can select which version of IKE to choose. If it is unclear which version is used by the remote peer, you can opt to set IKEv2 as preferred, which allows fallback to IKEv1 if the remote peer does not support IKEv2.

An important option to choose from is the Peer IP type: a static peer has a static IP address and allows for the simplest configuration. A dynamic peer, for example, the peer has a DHCP IP, will not have the option to set an IP address. A dynamic peer requires some other form of identification to ensure the gateway is negotiating with the correct host.

In this case, select which alternate Peer Identification method is used by selecting one of the options from the dropdown and setting the value in the field next to it. If the remote peer requires additional Peer Identification or if your host has a dynamic IP address, you can set the local Peer ID here as well.

The Authentication method can be set to a pre-shared key to be used on both peers to initiate negotiation, or a certificate can be imported to authenticate the handshake.

 On the IKE Gateway, under Advanced Options, several options can be set to accomodate certain situations:

• Passive Mode prevents this gateway from making outbound negotiations and respond to only negotiation requests.
• NAT Traversal enables UDP encapsulation on IKE protocols in case at least one of the gateways is behind a NAT gateway.
• Exchange Mode is on auto by default, but can be set to Main if both peers are on a static IP address or Agressive if either peer is on a dynamic IP address.
• IKE Crypto Profile should be set to the profile you created earlier.
• Dead Peer Detection is a heartbeat that identifies unavailable VPN peers to help restore resources.
• The IKEv2 liveness check work similar to DPD, but each packet is counted during activity and only after the peer has been idle for the configured amount of time an empty packet is sent to ascertain liveness.

Note: The Ike Gateway interface can also be set to a loopback interface (instead of a physical interface). It is recommended to put this loopback interface in the same zone as the external interface. 

Next, you will need to create a tunnel interface: go to the Interfaces and open the Tunnel tab. Create a new interface to  serve as a virtual interface to the Virtual Private Network. It is recommended to place the tunnel interface in it's own zone so Security policies can be used to control access between the vpn tunnel and the local zones.

After the interface is configured, you can proceed to create phase 2 of the VPN tunnel. Go to the IPSec Tunnels menu and create a new IPSec Tunnel.

On the General tab of the IPSec Tunnel object, you will need to assign this profile to the Tunnel Interface, IKE Gateway and Crypto profile you created. If the remote peer supports it, you can also enable tunnel monitor to allow failover to an alternate route in case the tunnel goes down and a backup is available.

On the Proxy IDs tab, you may need to add Proxy IDs for all the local and remote subnet pairs allowed to traverse the tunnel. This is usually required only if the remote peer uses policy-based VPN.

In short:

• A policy-based VPN peer negotiates VPN tunnels based on policies, typically in smaller subnets and directs traffic onto a tunnel as result of a policy action.
• A route-based VPN peer, like a Palo Alto Networks firewall, typically negiotiates a supernet (0.0.0.0/0) and lets the responsibility of routing lie with the routing engine. The Virtual Router takes care of directing traffic onto the tunnel while security policies take care of access, and so on.

If Proxy IDs are not used, routes will need to be added to the virtual router to ensure traffic can be forwarded between the local and remote network.

To allow traffic between both sites, a Security Policy will need to be created between the local Security Zone and the VPN tunnel Security Zone

After the above process is completed, go ahead and commit this change and implement the same configuration, with the IP information reversed, on the remote end.

When both ends have been configured, the VPN tunnel should establish and the status icons in the IPSEc tunnels  turn green to indicate connection. Get additional information by clicking the status links.

The System log can also contain key information about the VPN connection:

From a troubleshooting perspective, it is easiest if your local device is the initiator, as this will allow you a view into messages being sent out and potential error messages received from the remote peer to help determine if there has been a mistake. A simple way to initiate the negotiation is via the test command in the CLI:

for Phase1 IKE

> test vpn ike-sa 
+ gateway test for given IKE gateway
 | Pipe through a command
 <Enter> Finish input

> test vpn ike-sa 

Initiate IKE SA: Total 1 gateways found. 1 ike sa found.

and Phase2 IPSec

> test vpn ipsec-sa 
+ tunnel test for given VPN tunnel
 | Pipe through a command
 <Enter> Finish input

> test vpn ipsec-sa 

Initiate 1 IPSec SA.

 This could help resolve common mistakes like a mismatch in the pre-shared secret:

Or mismatches in the Crypto profiles

I hope you liked this edition of Getting Started. Please feel free to leave a comment or check out the previous episodes at the Getting Started series.

Tom