Thursday, October 24, 2019

By Charles Buege, Fuel User Group Member 

Up next in my series on how to setup IPSec tunnels on Palo Alto Firewalls is an article covering how to connect to a Cisco Meraki MX64 firewall.   

Before starting to set up any tunnel, a couple of items need to be decided on each end first. At a minimum, the following items need 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 is also presuming that you’ve already gone through the process of registering your Cisco Meraki MX64 system and are familiar with its web interface. If you aren’t familiar with Cisco Meraki MX64, I’d recommend starting with that before jumping into this article. If you’re in the process of learning IPSec tunnels as well as the Cisco Meraki MX64, you’ll be much better off getting familiar with just the Cisco Meraki MX64 first.  There are many links on YouTube and throughout the internet for setting up a Cisco Meraki MX64.

In this example, we will be setting up a connection from a Palo Alto firewall with an external IP addresses of 1.2.3.4 and a Cisco Meraki MX64 firewall with an external IP address of 6.7.8.9. Yes, those aren’t the real IP addresses I’m using, but other than the obfuscation of the actual source and destination IP addresses of the tunnel, everything else is accurate. Whenever possible, I try to choose the highest level of authentication and encryption that either side of the tunnel can support.  Sometimes I’ve had to drop it down a couple of levels, but for the most part, using the highest level of authentication and encryption on each end, you’ll get the most secure connection possible. In the case of the Cisco Meraki MX64, I’ve had to drop the Authentication down to SHA1 (the highest it can support) as well as the DH Group down to 2.

 “Office” Information – Palo Alto firewall –

-          Gateway IP Address: 1.2.3.4

-          Subnet Range: 10.241.0.0/16

“Branch” Information – Cisco Meraki MX64 firewall –

-          Gateway IP Address: 6.7.8.9

-          Subnet Ranges: 10.225.0.0/16

Shared Information –

           - IKE Crypto Information:

                  - DH Group: 2

                  - Authentication: sha1

                  - Encryption: aes-256-cbc

                  - Lifetime: 8 Hours

          - IKE Gateway:

                  - Shared Key: AbCdEfGhIj123456@!

          - IPSec Crypto Information:

                  - DH Group: No PFS

                  - Authentication: sha1

                  - Encryption: aes-256-cbc

                  - Lifetime: 1 Hour

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

Palo Alto Networks Configuration 

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

Zone and Interface

Go to Network -> Zones -> ‘Add’

Name: Branch_Zone

Type: Layer3

Click ‘Ok’.

Network -> Interfaces -> ‘Add’

Interface Name:  tunnel.201

Config tab -

Virtual Router: 10.241 Virtual Router (renamed from ‘default’)

Security Zone: Branch_Zone

Click ‘Ok’.

IKE Crypto

Go to Network -> Network Profiles -> IKE Crypto -> ‘Add’

Name: Branch_IKE_Crypto

DH Group: 2

Authentication: sha1

Encryption: aes-256-cbc

Key Lifetime: 8 Hours

IKE Gateway

Go to Network -> Network Profiles -> IKE Gateway -> ‘Add’

General tab -

Name: Branch_IKE_Gateway

Version: IKEv2 preferred 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

Advanced Options Tab -

IKEv2 -> IKE Crypto Profile: Branch_IKE_Crypto

Click ‘Ok’

IPSec Crypto

Go to Network -> Network Profiles -> IPSec Crypto -> ‘Add’

Name: Branch_IPSec_Crypto

Encryption: aes-256-cbc

Authentication: sha1

DH Group: no-pfs

Lifetime: 1 Hour

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 necessary on this screen.

 Go to 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

Now the ProxyID needs to be set to pair the respective subnets to each other for access.

Click on the ‘Proxy IDs’ tab.

Click ‘Add’.

Proxy ID – Branch_ID_01

Local – 10.241.0.0/16

Remote – 10.225.0.0/16

Click ‘Ok’.

Click ‘Ok’ again to complete creating the tunnel.

Static Routes

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

Go to Network -> Virtual Routers -> 10.241 Virtual Router -> Static Routes -> Add

Name: Branch-Remote-01

Destination: 10.225.0.0/16

Interface: tunnel.201

Next Hop: None

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.

Go to Policies -> Security -> Add

General tab –

Name: Office to Branch - Bidirectional

Source tab –

Source Zone: Internal – 10.241 and Branch_Zone

Destination tab –

Destination Zone: Internal – 10.241 and Branch_Zone

Click Ok.

One other item to do is to go to the ‘Service/URL Category’ tab and change the ‘application-default’ above the word ‘Service’ to ‘any’. If you don’t, trying to access any resources on non-standard ports (like accessing HTTPS on port 54321, for example) will be blocked.

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

Cisco Meraki MX64 Configuration

Next, we go to the Cisco Meraki MX64 configuration steps.

Please keep in mind that this article was written in August of 2019, so some of the menu titles and labels may have changed between when this article was written and now.

Go to account.meraki.com/secure/login/dashboard_login and login with your credentials. Click on ‘Security & SD-WAN’, ‘Appliance Status’. If you have more than one security appliance on your account, select it. Make sure that the appliance is working and live on the internet.

After verifying that the device is online, click on ‘Security & SD-WAN’ and then ‘Site-to-site VPN’. When you get to this site initially, be sure that the ‘Type’ that you have selected is ‘Hub (Mesh)’. If you had to change this setting, be sure to click the ‘Save Changes’ button that will appear.

After setting the system for ‘Hub’, scroll down to the section called ‘Organization-wide settings’ and under ‘Non-Meraki VPN peers’, click on ‘Add a peer’.

Fill out the fields that have appeared.

Name – Office Tunnel

Public IP – 1.2.3.4

Private Subnets – 10.241.0.0/16

Preshared secret – AbCdEfGhIj123456@!

Availability – If you don’t want all of your subnets to be accessible, change this option now.

IPsec policies –

Under Phase 1:

               Encryption – AES 256

               Authentication – SHA1

               Diffe-Hellman group – 2

               Lifetime (seconds) – 28800

               Under Phase 2:

               Encryption – AES 256

               Authentication – SHA1

               PFS group – Off

               Lifetime (seconds) – 3600

After you’ve set these settings, be sure to click ‘Save Changes’ to put the changes into effect.

You should be able to ping across the tunnel at this point. If you’re unable to, I’d recommend going back and verifying that the IKE and IPsec tunnels match on both sides.

Looking at the Palo Alto firewall’s IPSec Tunnels screen, you should see that the tunnel is up and running.

Image shows a successful tunnel connection where the green circles show that Phase 1 (box 2) and Phase 2 (box 7) have been completed successfully.

Congratulations! You’ve now got a tunnel set up between your office and your branch using Cisco Meraki MX64 and your Palo Alto firewall.

Thank you for reading this article. If there are any “how-to” topics that are of interest — not limited to only IPSec tunnels — please reach out to the Fuel for Thought blog managing editor at editor@fuelusergroup.org and share your thoughts.

Coming Up 

The next articles I will be writing will continue in this vein with regards to connecting to other firewalls – both commercial and open source. Here is a list of the topics that I will be covering in future articles with regards to IPSec tunnels to Palo Alto firewalls:

• AWS
• Microsoft Azure
• OPNsense
• Palo Alto Networks firewall back to itself for those users with a single Palo Alto firewall
• Palo Alto firewall virtual machine
• VyOS (open source fork of Vyatta)

Interested in learning how to build other IPSec tunnels? Check out these blog posts in the series:

• How to Build an IPSec Tunnel Between a Palo Alto Networks Firewall and a pfSense Firewall
• How to Build an IPSec Tunnel Between a Palo Alto Networks Firewall and a Cisco ASA (Adaptive Security Appliance
• How to Build an IPSec Tunnel Between a Palo Alto Networks Firewall and an IPFire Firewall
• How to Build an IPSec Tunnel Between Two Palo Alto Networks Firewalls