How to Build an IPSec Tunnel Between a Palo Alto Networks Firewall and an IPFire Firewall

Posted by Charles Buege on Mar 21, 2019 3:29:40 PM

Thursday, March 21, 2019

From Charles Buege, Fuel User Group Member

Continuing my series on how to setup IPSec tunnels on Palo Alto Networks firewalls, this article covers how to connect to an IPFire firewall. As I wrote in the initial article in this series, I realized not everyone would necessarily have access to the same resources I would. This got me thinking – how could someone with access to only one Palo Alto Networks firewall learn how to setup and configure IPSec tunnels? 

That’s when I remembered a conversation I had with a friend the other day. He wanted to setup a firewall at his home so he could have an IPSec tunnel to his work but didn’t have any firewall hardware.  He found an open source firewall, IPFire, that looked like it would work for his needs. 

While he hasn’t gotten around to implementing it yet, when I had the idea for this article, I figured I could kill two birds with one stone: Get familiar with IPFire to be able to help him later and to also use IPFire as a destination for this article. 

Future Articles

As you can see, this is going to be a series dealing with connectivity between Palo Alto Networks firewalls and other IPSec endpoints.  Here is a list of some of the next IPSec endpoints that will be covered in future articles:

  • Amazon Web Services
  • Cisco ASA 55XX
  • Cisco Meraki MX
  • Microsoft Azure
  • OPNsense
  • pfSense
  • A Palo Alto Networks firewall that will connect back to itself for those users with access to a single Palo Alto firewall
  • A Palo Alto Networks firewall virtual machine running under VMware ESXi
  • VyOS (open source fork of Vyatta) 

If there are any endpoints specifically that you, the reader, would like to see added to this list, please add a comment to this article on what topic you’d like covered and we’ll do our best to get it added to the list. 

Before We Begin – A Few Things to Know

Before starting to set up any tunnel, a couple items need to be decided on each end first. At a minimum, the following needs to be known by both parties for the proper configuration of a tunnel:

  • For Phase 1 of the connectivity, you need to know the DH Group, Authentication, and Encryption. You also need to know the key lifetime for the IKE crypto profile.
  • For Phase 2 of the connectivity, you need to know the Encryption, Authentication, and DH Group number. You also need to know the lifetime for the IPSec crypto profile.
  • You will want a pre-shared key/passphrase that both sides will use for the initial authentication and connection to each other.
  • You will need to know the range (or ranges) of IP addresses on both sides that will need to be able to communicate with each other. 

This article also presumes you’ve already gone through the process of building an IPFire system and are familiar with its navigation, usage, etc., as well have already configured the “Certificate Authorities and -Keys" within the Services -> IPSec menu. If you aren’t familiar with IPFire nor have done the certificate setup, I’d recommend starting with that before jumping into this article. If you’re in the process of learning IPSec tunnels as well as IPFire, you’ll be much better off getting familiar with IPFire first.  There are many links on YouTube and throughout the internet for setting up IPFire.  

In this example, we will be setting up a connection from a Palo Alto Networks firewall with an external IP addresses of 1.2.3.4 and an IPFire firewall with an external IP address of 6.7.8.9. Yes, those are fake IP addresses, but other than the obfuscation of the actual source and destination IP addresses of the tunnel, everything else is unchanged. 

“Office” Information – Palo Alto firewall –

  • Gateway IP Address: 1.2.3.4
  • Subnet Range: 10.241.0.0/16 

“Branch” Information – IPFire firewall –

  • Gateway IP Address: 6.7.8.9
  • Subnet Ranges: 10.222.10.0/24 

Shared Information –

  • IKE Crypto Information:
    • DH Group: 20
    • Authentication: sha512
    • Encryption: aes-256-cbc
    • Lifetime: 8 Hours
  • IKE Gateway:
    • Shared Key: AbCdEfGhIj123456@!
  • IPSec Crypto Information:
    • DH Group: 20
    • Authentication: sha512
    • Encryption: aes-256-cbc
    • Lifetime: 1 Hour 

With this information, we can now begin the process for building the IPSec tunnel.

Palo Alto Configuration 

First, we start by doing the configuration on the Palo Alto firewall for the “Office” side. 

Zone and Interface 
“Office” side –
Network -> Zones -> ‘Add’
Name:  Branch_Zone
Type:  Layer3
Click ‘Ok’.

Image1-1

Network -> Interfaces -> ‘Add’
Interface Name:  tunnel.201
Config tab -
Virtual Router:  10.241 Virtual Router (renamed from ‘default’)
Security Zone:  Branch_Zone
Click ‘Ok’.

Image2-1

IKE Crypto 

“Office” side –
Network -> Network Profiles -> IKE Crypto -> ‘Add’
Name:  Branch_IKE_Crypto
DH Group:  20
Authentication: 
Encryption: 
Key Lifetime:  8 Hours

Image3-1

IKE Gateway 

“Office” side –
Network -> Network Profiles -> IKE Gateway -> ‘Add’
General tab -
Name:  Branch_IKE_Gateway
Version:  IKEv2 only mode
Interface:  ethernet1/1  (the interface associated with the ‘outside’ IP address that will be connecting to the ‘Branch side’)
Local IP Address:  1.2.3.4  (the external IP address associated with this interface that will be connecting to the ‘Branch side’)
Peer IP Address Type:  IP
Peer Address:  6.7.8.9  (the external IP address at the ‘Branch Side’ that will be connected to)
Authentication:  Pre-Shared Key
Pre-shared Key:  AbCdEfGhIj123456@!
Confirm Pre-shared Key:  AbCdEfGhIj123456@!
Local Identification:  IP Address / 1.2.3.4
Peer Identification:  IP Address / 6.7.8.9

Image4-2

Advanced Options Tab -
IKEv2 -> IKE Crypto Profile:  Branch_IKE_Crypto
Click ‘Ok’

Image5-1

IPSec Crypto 

“Office” side –
Network -> Network Profiles -> IPSec Crypto -> ‘Add’
Name:  Branch_IPSec_Crypto
Encryption:  aes-256-cbc
Authentication:  sha512
DH Group:  Group 20
Lifetime:  1 Hour

Image6-1

IPSec Tunnel
At this point, we have all of the components that we need to build the tunnel.  Remember that since the ‘IKE Crypto’ options are assigned at the ‘IKE Gateways’, those options are not available on this screen. 

“Office” side –
Network -> IPSec Tunnels -> Add
Name:  Branch_Tunnel
Tunnel Interface:  tunnel.201
Type:  Auto Key
Address Type:  IPv4
IKE Gateway:  Branch_IKE_Gateway
IPSec Crypto Profile:  Branch_IPSec_Crypto
Click ‘Ok’.

Image7-1

Static Routes 

The next step is to set up the necessary static routes so the traffic will traverse the proper tunnel. 

 “Office” side –
Network -> Virtual Routers -> 10.241 Virtual Router -> Static Routes -> Add
Name:  Branch-Remote-01
Destination:  10.222.10.0/24
Interface:  tunnel.201
Next Hop:  None

Image8-1

Security Policy

Once the static routes are in place, you want to set the Security Policy to grant access across the tunnel for the subnets you want to be able to traverse the subnet. 

“Office” side –
Policies -> Security -> Add
General tab –
Name:  Office to Branch - Bidirectional

Image9

Source tab –
Source Zone:  Internal – 10.241 and Branch_Zone

Image10

Destination tab –
Destination Zone:  Internal – 10.241 and Branch_Zone

Image11

Click Ok.

One other item to do, especially since you’ll probably want to administer the IPFire firewall across the IPSec tunnel: Go to the ‘Service/URL Category’ tab.  Change the ‘application-default’ above the word ‘Service’ to ‘any’.  If you don’t, trying to access the IPFire firewall at its standard administration port of 444/HTTPS will be blocked.

Image12

At this time, perform a commit to the firewall to put all of the changes into effect. IPFire Configuration 

Next, we go to the IPFire configuration steps. 

Go to https://[IPFireIPAddress]:444/ and login with your credentials that you defined upon installation of the firewall. 

Global Settings

Be sure that the Global Settings section of the menu option ‘Services’ -> ‘IPSec’ is filled out. For me, I have my set in the following way: 

Public IP or FQDN for RED interface or <%defaultroute>:  External IP Address
Delay before launching VPN (seconds):  0
Host-to-Net Virtual Private Network (RoadWarrior):  Leave blank
Enabled:  Checked
Click ‘Save’.

Image13

Connection Status and -Control

Click ‘Add’.
Select ‘Net-to-Net Virtual Private Network’ and click ‘Add’.

Image14

Connection and Authentication

Connection –
Name:  Enter the name for the Connection
Enabled:  Checked
Local subnet:  10.222.10.0/255.255.255.0
Remote host/IP:  1.2.3.4
Remote subnet:  10.241.0.0/255.255.0.0
Local ID:  6.7.8.9
Remote ID:  1.2.3.4

Edit advanced settings when done:  Keep this unchecked. We will come back to do this later. 

Authentication –
Use a pre-shared key – select the Radio button.
Enter the pre-shared key into the box to the right of this option. 
For our example, we are using this:  AbCdEfGhIj123456@!
Click ‘Save’.


Image15

Once you click ‘Save’, IPFire will sometimes take a long time for it to load/process/move back to the Services -> IPSec screen. In my experience, I wait about three to four minutes and if it doesn’t move you back to the main screen, then I manually go to Services -> IPSec and my entry is normally there.

 Image16

 

Here is where we are going to set the advanced settings mentioned earlier.  It is where we specify the phase 1 and phase 2 information, etc.  In the above image, click on the ‘pencil’ icon to edit the entry.  After the Connection ‘basic page loads, click ‘Advanced’.

Image17

Now we come to the Phase 1/Phase 2 entries for the firewall. I’m not a fan of this screen as it has too much going on and could look neater, but you take what you can get. One thing I will point out – if you are looking for a particular Encryption, Integrity and/or Grouptype, notice that there are scrollbars for each of the sections under both IKE and ESP. Again, with the list boxes right up against each other, it’s a little difficult to see, which is why I point it out. 

As previously mentioned, we want to use the following settings:

IKE –
Keyexchange:  IKEv2
Encryption:  256 bit AES-CBC
Integrity (Authentication):  SHA2 512 bit
Lifetime:  8 Hours
Grouptype:  ECP-384 (NIST)

ESP –
Encryption:  256 bit AES-CBC
Integrity (Authentication):  SHA2 512 bit
Lifetime:  8 Hours
Grouptype:  ECP-384 (NIST)

When done, click ‘Save’.  You will be taken back to the Services -> IPSec screen after a moment.

Image18

For those of you newer to IPSec tunnels than others, you may wonder why I chose ‘ECP-384 (NIST)’ for my group to match the earlier Palo Alto firewall choice of ‘group20’. I was not sure what to select the first time I came to this screen but I figured that there should be a list somewhere that gives a better break down on the differences between ‘group1’, ‘group2’, etc. and the ‘Grouptype’ list in the above screen. I used this site to help me make my proper selection: http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-10

Here’s a screen shot of the relevant section as of March, 2019.

Image19

Being a page maintained by the Internet Assigned Numbers Authority (IANA), I figured the authenticity of the page to be pretty legit so I went with it. Pairing the integer value of the group number, ‘20’, with the value on the list, I can see that it says ‘384-bit random ECP group’, meaning I had two possible matches with regards to selecting Grouptype in IPFire – ‘ECP-384 (NIST)’ or ‘ECP-384 (Brainpool)’. After doing a web search for ‘Brainpool’, since I already knew about the National Institute of Standards and Technology (NIST), I found that Brainpool could either be referring to a German television production company, a Swedish pop group, or the standard curves in elliptic curve cryptography. Granted, while I figured very quickly that it was the last of the three, I also figured that with my experience and knowing more about NIST than Brainpool, I chose that selection and that worked for me. 

At this point, you should be all set and able to traverse the tunnel.  

Once the commit is complete, try to do anything that will cause traffic to traverse the travel. Go back to Network -> IPSec Tunnels and check the status lights to confirm that the tunnel is up.

“Office” side –

Image20

On the IPFire, go to Services -> IPSec.

“Branch” side –

Image21

As you can see, you are up and running. Presuming your rules are correct on the Palo Alto firewall, you should have no problem accessing the IPFire web interface remotely. 

Thank you for reading this article. If there are any topics that anyone would like a ‘how-to’ written, please let us know. We write these articles for you, the users, so if there is something specific you’d like, please don’t hesitate to ask.

Have suggestions for future "how to" topics? Reach out to the Fuel editor, Kristin Fields, at kfields@fuelusergroup.orgOr, start a discussion among your Fuel peers in the Discussion Forum

 

Topics: Charles Buege, Palo Alto Networks Next-Generation Firewall, IPSec Tunnel, how-to articles, IPFire

Posts by Topic

see all

Subscribe to Blog Updates

Recent Posts

Posts by Topic

see all