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 126.96.36.199 and a Cisco Meraki MX64 firewall with an external IP address of 188.8.131.52. 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: 184.108.40.206
- Subnet Range: 10.241.0.0/16
“Branch” Information – Cisco Meraki MX64 firewall –
- Gateway IP Address: 220.127.116.11
- 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’
Network -> Interfaces -> ‘Add’
Interface Name: tunnel.201
Config tab -
Virtual Router: 10.241 Virtual Router (renamed from ‘default’)
Security Zone: Branch_Zone
Go to Network -> Network Profiles -> IKE Crypto -> ‘Add’
DH Group: 2
Key Lifetime: 8 Hours
Go to Network -> Network Profiles -> IKE Gateway -> ‘Add’
General tab -
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: 18.104.22.168 (the external IP address associated with this interface that will be connecting to the ‘Branch side’)
Peer IP Address Type: IP
Peer Address: 22.214.171.124 (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 / 126.96.36.199
Peer Identification: IP Address / 188.8.131.52
Advanced Options Tab -
IKEv2 -> IKE Crypto Profile: Branch_IKE_Crypto
Go to Network -> Network Profiles -> IPSec Crypto -> ‘Add’
DH Group: no-pfs
Lifetime: 1 Hour
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
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.
Proxy ID – Branch_ID_01
Local – 10.241.0.0/16
Remote – 10.225.0.0/16
Click ‘Ok’ again to complete creating the tunnel.
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
Next Hop: None
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
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 – 184.108.40.206
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 email@example.com and share your thoughts.
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:
- Microsoft Azure
- 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
More to Explore
Check out these Fuel blog posts for further reading: