Sat. Oct 1st, 2022

To solve
What else can my firewall do? Virtual private network!

We’ve come a long way since we first tore apart that awesome firewall. You are now ready to set up a virtual private network (VPN). Where do you start? Tom has prepared not only a step-by-step program for setup, but also a checklist for your upfront work. Let’s take a closer look at virtual private networks and how to configure them on the Palo Alto Network firewall. We’ll highlight some of the differences that will help you set up an encrypted tunnel using routing or policy-based VPN peers, and show you some troubleshooting tips to help you get up and running quickly.

A VPN is a technology that creates a secure network connection over a traditional network by encrypting all communication between two hosts. We’ll learn how to set up a site-to-site tunnel with strong IPSec encryption.

When preparing a site-to-site VPN configuration, there are many times when you need to have a conversation with a remote administrator, either a colleague or a complete stranger. You first need to negotiate how to set up the tunnel, which protocols to use, and so on. To facilitate this process, it’s a good idea to have a small checklist:

Does the remote peer have a static or dynamic IP address?
What is a remote subnet?
IKEv1 or IKEv2?
Pre-shared key or Certificate authentication?
Is NAT traversal required (is one of the peers behind another gateway where NAT is performed)?
Is the remote peer based on routing or policy?
Two groups of the following attributes: one group for IKE configuration and the other group for IPSec.

Which authentication algorithm will be used (SHA1, SHA256,…) ?
Which encapsulation algorithm will be used (3DES, AES,…) ?
How strong the key needs to be in the key exchange (Diffie-Hellman group 1, 20,..) ?
What is the lifetime of the key?

Knowing the details will make configuration easier. I’ll highlight some of these possible effects in the following configuration examples:

The first thing you can do after negotiating with the other party or deciding for yourself whether you can manage either point is to prepare the encryption configuration file.

Go to the Network TAB and add a new profile to the IPSec Crypto and IKE Crypto profiles:

Next, you will need to create peers representing the remote gateway and IKE attributes shared with that gateway to allow IPSec negotiation. Go to the IKE Gateway profile on the Network TAB and create a new IKE gateway object.

On the general TAB, you can select the IKE version you want to select. If you do not know which version the remote peer uses, you can set IKEv2 as the preferred version. If the remote peer does not support IKEv2, IKEv1 can be rolled back.

One important option to choose from is the peer IP type: static peers have static IP addresses and allow the simplest configuration. Dynamic peers (for example, peers with DHCP IP addresses) do not have the option to set IP addresses. Dynamic peers require some other form of identity to ensure that the gateway is negotiating with the correct host.

In this case, choose which alternative peer identification method to use by selecting an option from the drop-down list and setting the value in the field next to it. You can also set the local peer ID here if the remote peer requires additional peer identification, or if your host has a dynamic IP address.

The Authentication method can be set to a pre-shared key for both parties to use to start negotiations, or a certificate can be imported to verify the handshake.

Under the advanced options of the IKE gateway, you can set several options to adapt to certain situations:

Passive mode prevents this gateway from conducting outbound negotiation and only responding to negotiation requests.
NAT Traversal Enables UDP encapsulation on IKE in case at least one gateway is behind NAT.
By default, Exchange mode is automatic, but if both peers are on static IP addresses, you can set it to Main. If both peers are configured with dynamic IP addresses, the value can be Agressive.
The IKE encryption profile should be set to the profile you created earlier.
Dead Peer Detection is a Detection signal that identifies unavailable VPN peers to help recover resources.
IKEv2 activity check works in a similar way to DPD, but counts each packet during activity and only sends empty packets to determine activity after the peer is idle for the configured time.
Note: The Ike Gateway interface can also be set as a loopback interface (rather than a physical interface). You are advised to put the loopback interface in the same area 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

On the general TAB of the IPSec tunnel object, you need to assign this profile to the tunnel interface, IKE gateway, and encryption profile that you create. If the remote peer supports it, you can also enable tunnel monitor to allow failover to alternate routes in case the tunnel fails and backup is available.

On the proxy ID TAB, you may need to add proxy ids for all local and remote subnet pairs that are allowed through tunnels. This is usually only required when remote peers are using a policy-based VPN.

In short:

Policy-based VPN peers negotiate VPN tunnels based on the policy, usually on a smaller subnet, and direct traffic to the tunnel as a result of the policy operation.
Routing-based VPN peers, such as Palo Alto Networks firewalls, typically negotiate a hypernetwork (, with the routing engine taking responsibility for giving way. Virtual routers are responsible for directing traffic to tunnels, security policies are responsible for access, and so on.

If you do not use a proxy ID, you need to add routes to the virtual router to ensure that traffic can be forwarded between the local and remote networks.

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 complete, continue to commit this change and implement the same configuration on the remote side, but with the IP information reversed.

After both ends are configured, a VPN tunnel should be established, and the status icon of the IPSEc tunnel turns green to indicate the connection. Click the status link for more information.

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.

By admin

Leave a Reply

Your email address will not be published.