Palo Alto Networks Next-Generation Firewall

This tutorial includes the steps required to configure IPsec tunnels to connect a Palo Alto Networks Next-Generation Firewall (NGFW) to Cloudflare Magic WAN through a Layer 3 deployment.

​​ Software version tested

• PAN-OS 9.1.14-h4

​​ Use Cases

• Magic WAN: Connecting two or more locations with RFC-1918 Open external link private non-routable address space.
• Magic WAN with Cloudflare Zero Trust (Gateway egress): Same as Magic WAN, with the addition of outbound Internet access from Magic WAN protected sites egressing the Cloudflare edge network.

​​ Prerequisites

This tutorial assumes you have a standalone NGFW with two network interfaces:

• One in a trust security zone (Trust_L3_Zone) with an RFC-1918 Open external link non-Internet routable IP address (internal network);
• And the other in an untrust security zone (Untrust_L3_Zone) with a legally routable IP address (Internet facing).

Additionally, there must be a default gateway set on the Virtual Router (default) pointing to the router of your Internet service provider(s).

​​ Environment

The following IP addresses are used throughout this tutorial. Any legally routable IP addresses have been replaced with IPv4 Address Blocks Reserved for Documentation ( RFC5737 Open external link ) addresses within the 203.0.113.0/24 subnet.

​​ Cloudflare Magic WAN

​​ Magic IPsec Tunnels

Use the Cloudflare dashboard or API to configure two IPsec Tunnels. The settings mentioned in Add IPsec tunnels below are used for the IPsec tunnels referenced throughout the remainder of this guide.

These are the target IP addresses for bidirectional tunnel health checks:

• 172.64.240.253: Use with the primary IPsec tunnel.
• 172.64.240.254: Use with the secondary IPsec tunnel.

​​ Add IPsec tunnels

1. Follow the Add tunnels instructions to create the required IPsec tunnels with the following options:

   • Tunnel name: SFO_IPSEC_TUN01
   • Interface address: 10.252.2.96/31
   • Customer endpoint: 203.0.113.254
   • Cloudflare endpoint: 162.159.66.164
   • Health check rate: Low (default value is Medium)
   • Health check type: Reply
   • Health check target: Custom (default is Default)
   • Target address: 172.64.240.253

2. Select Add pre-shared key later > Add tunnels.

3. Repeat the process to create a second IPsec tunnel with the following options:

   • Tunnel name: SFO_IPSEC_TUN02
   • Interface address: 10.252.2.98/31
   • Customer endpoint: 203.0.113.254
   • Cloudflare endpoint: 172.64.242.164
   • Health check rate: Low (default value is Medium)
   • Health check type: Reply
   • Health check target: Custom (default is Default)
   • Target address: 172.64.240.254

​​ Generate Pre-shared keys

When you create IPsec tunnels with the option Add pre-shared key later, the Cloudflare dashboard will show you a warning indicator:

1. Select Edit to edit the properties of each tunnel.
2. Select Generate a new pre-shared key > Update and generate pre-shared key.

   

3. Copy the pre-shared key value for each of your IPsec tunnels, and save these values somewhere safe. Then, select Done.

   

​​ IPsec identifier - FQDN (Fully Qualified Domain Name)

After creating your IPsec tunnels, the Cloudflare dashboard will list them under the Tunnels tab. Select the arrow (>) on each of your IPsec tunnel to collect the FQDN ID value from each of them. The FQDN ID value will be required when configuring IKE Phase 1 on the Palo Alto Networks Next-Generation Firewall.

​​ Magic Static Routes

If you refer to the Environment section, you will notice there is one subnet within Trust_L3_Zone: 10.1.100.0/24.

Create a static route for each of the two IPsec tunnels configured in the previous section, with the following settings (settings not mentioned here can be left with their default settings):

​​ Tunnel 01

• Description: SFO_VLAN100_01
• Prefix: 10.1.100.0/24
• Tunnel/Next hop: SFO_IPSEC_TUN01

​​ Tunnel 02

• Description: SFO_VLAN100_02
• Prefix: 10.1.100.0/24
• Tunnel/Next hop: SFO_IPSEC_TUN02

​​ Palo Alto Networks Next-Generation Firewall

​​ Tags

While Tags are optional Open external link , they can greatly improve object and policy visibility. The following color scheme was implemented in this configuration:

Use the Palo Alto Networks Next-Generation Firewall command-Line to set the tags:

​​ Objects

The use of Address and Address Group objects wherever possible is strongly encouraged. These objects ensure that configuration elements that reference them are defined accurately and consistently.

Any configuration changes should be applied to the objects and will automatically be applied throughout the remainder of the configuration.

​​ Address Objects

Use the Palo Alto Networks Next-Generation Firewall command-Line to set the objects:

​​ Address Group object

The Address Group object used in this configuration provides a single object representation of the entire Cloudflare IPv4 public address space.

Use the Palo Alto Networks Next-Generation Firewall command-Line to set the address group object:

​​ Interface Mgmt - Network Profiles

Interface Mgmt profiles control what traffic is allowed to the firewall, as opposed to through the firewall.

Adding an Interface Mgmt profile to the tunnel interfaces will provide the ability to ping the Virtual Tunnel Interface on your firewall(s).

​​ Set up via dashboard

You can define an Interface Management Profile to allow ping from the dashboard:

1. Go to Network Profiles > Interface Mgmt.
2. In the Network tab select Add.
3. Create profiles to allow Ping, and in the Network Services group select Ping.

​​ Set up via command line

You can also use the command line to allow ping:

​​ Network Interfaces

Palo Alto Networks Next-Generation Firewall (NGFW) is configured with two Ethernet interfaces:

​​ Set up via dashboard

Follow the guidance on the images below to set up the Ethernet interfaces through the dashboard.

​​ ethernet1/1: Trust_L3_Zone

​​ ethernet1/2: Untrust_L3_Zone

After setting up your Ethernet interfaces, they should show up on the overview page:

​​ Set up via command line

You can also use the command line to set up the Ethernet interfaces.

​​ Tunnel interfaces

Establishing IPsec Tunnels to Cloudflare Magic WAN requires two tunnel interfaces - one to each of the two Cloudflare Anycast IP addresses. You also have to ensure that Allow_Ping is bound to both tunnel adapters in Advanced > Managementt Profile.

Review the images below for more information.

​​ Set up via dashboard

​​ tunnel.1 - Cloudflare_L3_Zone

​​ tunnel.2 - Cloudflare_L3_Zone

After setting up your Tunnel interfaces, they should show up on the overview page:

​​ Set up via command line

You can also set up your tunnels in the command line:

​​ Zones

The Palo Alto Networks Next-Generation Firewall (NGFW) used to create this tutorial includes the following zones and corresponding network interfaces:

The tunnel interfaces are placed in a separate zone to facilitate the configuration of more granular security policies. The use of any other zone for the tunnel interfaces will require adapting the configuration accordingly.

​​ Set up via dashboard

​​ Trust_L3_zone

​​ Untrust_L3_zone

​​ Cloudflare_L3_zone

​​ Set up via command line

You can also use the command line to associate zones and interfaces:

​​ Apply Changes

This would be a good time to save and commit the configuration changes made so far. Once complete, make sure you test basic connectivity to and from the firewall.

​​ IKE crypto profile Phase 1

Add a new IKE crypto profile to support the required parameters for Phase 1.

Multiple DH groups and authentication settings are defined in the desired order. Palo Alto Networks Next-Generation Firewall (NGFW) will automatically negotiate the optimal settings based on specified values.

​​ Set up via dashboard

​​ Set up via command line

You can also set up the crypto profile for Phase 1 via the command line:

​​ IPsec crypto profile Phase 2

Add a new IPsec crypto profile to support the required parameters for Phase 2.

Multiple Authentication settings are defined in the desired order. Palo Alto Networks Next-Generation Firewall (NGFW) will automatically negotiate the optimal settings based on specified values.

​​ Set up via dashboard

​​ Set up via command line

You can also set up the IPsec crypto profile for Phase 2 via the command line:

​​ IKE Gateways

Define two IKE Gateways to establish the two IPsec tunnels to Cloudflare. Make sure to define the following values:

​​ Set up via dashboard

​​ Tunnel 1 settings: CF_Magic_WAN_IKE_01

​​ Tunnel 2 settings: CF_Magic_WAN_IKE_02

​​ Set up via command line

​​ Tunnel 1 settings: CF_Magic_WAN_IKE_01

​​ Tunnel 2 settings: CF_Magic_WAN_IKE_02

​​ IPsec Tunnels

With the IKE Gateways defined, the next step is to configure two IPsec Tunnels - one corresponding to each of the two IKE Gateways configured in the previous section.

​​ Prerequisites

There are a few prerequisites you should be aware of before continuing:

• Do not configure Proxy IDs. Magic WAN IPsec tunnels are based on the route-based VPN model. Proxy IDs are used with policy-based VPNs.
• Disable Replay Protection, under the Advanced Options.
• Disable Tunnel Monitor. It can cause undesirable results. Tunnel Monitor is a Palo Alto Networks proprietary feature that assumes there are Palo Alto Networks Next-Generation Firewall devices on both sides of the IPsec tunnel. Also, Tunnel Monitor is intended for use with IPsec tunnels based on IKEv1 (Magic WAN IPsec tunnels are based on IKEv2).

​​ Set up via dashboard

​​ Tunnel 1 settings: CF_Magic_WAN_IPsec_01

​​ Tunnel 2 settings: CF_Magic_WAN_IPsec_02

​​ Set up via command line

​​ Tunnel 1 settings: CF_Magic_WAN_IPsec_01

​​ Tunnel 2 settings: CF_Magic_WAN_IPsec_02

​​ Apply Changes

This would be a good time to save and commit the configuration changes made thus far. Once complete, make sure you test basic connectivity across the IPsec tunnels.

​​ IPsec tunnel connectivity tests

This is a good time to ensure the IPsec tunnels are established and to validate basic connectivity.

​​ Verify IKE Phase 1 Communications

The first step is to verify IKE Phase 1 completed successfully:

​​ Syntax

​​ Example for CF_Magic_WAN_IKE_01

​​ Example for CF_Magic_WAN_IKE_02

​​ Troubleshooting IKE Phase 1 Communications

Magic WAN IPsec tunnels expect the customer device will initiate the IPsec tunnels. The tunnels may not establish if there is no traffic that would traverse the tunnel under normal conditions. In this case, it may be necessary to force IKE Phase 1.

​​ Syntax

​​ Example for CF_Magic_WAN_IKE_01

​​ Example for CF_Magic_WAN_IKE_02

Repeat these commands for the respective tunnel to ensure the IKE SA(s) display as expected.

​​ Verify IPsec Phase 2 Communications

To ensure the IPsec tunnels are established, ping the remote Virtual Tunnel Interface (Cloudflare side) from the​ command line on the Palo Alto Networks Next-Generation Firewall. Ensure you specify the source IP address of the ping from the local side of the Virtual Tunnel Interface:

​​ Syntax

​​ Example for CF_Magic_WAN_IPsec_01

​​ Example for CF_Magic_WAN_IPsec_02

​​ Troubleshooting IPsec Phase 2 Communications

Magic WAN IPsec tunnels expect the customer device will initiate the IPsec tunnels. The tunnels may not establish if there is no traffic that would traverse the tunnel under normal conditions. In this case, it may be necessary to force IPsec Phase 2. This is typically unnecessary as once IKE Phase 1 negotiates successfully, IPsec Phase 2 automatically establishes the tunnel. The test is still worth performing.

​​ Syntax

​​ Example for CF_Magic_WAN_IPsec_01

​​ Example for CF_Magic_WAN_IPsec_02

Repeat these commands for the respective tunnel to ensure the IPsec SA(s) display as expected.

​​ Ping Remote Virtual Tunnel interfaces

Use ping to source traffic from the IP address of the Virtual Tunnel interface on Palo Alto Networks Next-Generation Firewall (NGFW) to the IP address of the Virtual Tunnel Interface on the Cloudflare side of the IPsec tunnel.

​​ Syntax

​​ Example for Tunnel 1

​​ Example for Tunnel 2

​​ Virtual Router

While we will leverage policy-based forwarding to implement policy-based routing, it is still a good idea to configure routing on the Virtual Router.

Cloudflare Magic WAN implements equal-cost multi-path (ECMP) routing to steer traffic across IPsec tunnels. The default behavior is to load balance traffic equally across both tunnels.

​​ Enable ECMP

First, ensure the General tab displays both the Ethernet and tunnel interfaces. If any of the interfaces are not displayed, either use Add to specify the missing interface(s), or visit the Interfaces menu to ensure the relevant Virtual Router is selected.

1. Open the Router settings for the default Virtual Router and select the ECMP tab.
2. Select the checkboxes next to Enable, Symmetric Return, and Strict Source Path (all three checkboxes should be selected).
3. Under Load Balance, change the Method from IP Modulo to Weighted Round Robin and add both tunnel interfaces. Ensure the weights match the weights defined in Magic WAN Static Routes (reference the Cloudflare Dashboard).

You can also use the command line to make these changes:

​​ Add static routes

Add two static routes for each Magic WAN Protected Network - one for each of the two tunnel interfaces.

The environment used for this tutorial assumes two Magic WAN Protected Networks:

• VLAN0010: 10.1.10.0/24
• VLAN0020: 10.1.20.0/24

​​ VLAN0010 (10.1.10.0/24) via tunnel.1

​​ VLAN0010 (10.1.10.0/24) via tunnel.2

​​ VLAN0020 (10.1.20.0/24) via tunnel.1

​​ VLAN0020 (10.1.20.0/24) via tunnel.2

You can also configure these settings via command line:

​​ VLAN0010 - 10.1.10.0/24

​​ VLAN0020 - 10.1.20.0/24

​​ Magic health checks

Cloudflare crafts ICMP probes which are sent through the IPsec tunnels from random servers across Cloudflare’s global Anycast network. These ICMP probes are unique because an ICMP reply packet is sent (as opposed to an ICMP Request).

Cloudflare Magic WAN customers must configure IPsec tunnels to use custom Anycast IP addresses for the health check endpoints:

• CF_Health_Check_Anycast_01: 172.64.240.253
• CF_Health_Check_Anycast_02: 172.64.240.254

​​ Security Policy - Tunnel health checks

You must define a rule to allow the ICMP reply probes as Palo Alto Networks Next-Generation Firewall’s default behavior will drop the health checks.

​​ Setup via dashboard

​​ Setup via command line

​​ Policy-based forwarding - tunnel health checks

Traffic matching the Security Rule defined in the last step must be routed symmetrically across the tunnel the ingress traffic was received through. Two policy-based forwarding rules ensure the traffic is routed accordingly.

Ensure have the following:

• Source Zone: Cloudflare_L3_Zone
• Source Addresses: CF_Health_Check_Anycast_01 and CF_Health_Check_Anycast_02
• Destination Zone: Cloudflare_L3_Zone
• Destination Addresses: Cloudflare_IPv4_Static_Grp
• Application: icmp and ping

​​ Set up via dashboard tunnel.1

​​ Set up via dashboard tunnel.2

​​ Set up via command line tunnel.1

​​ Set up via command line tunnel.2

​​ Troubleshooting tunnel health checks

​​ Security Policy

Use the Traffic log viewer to ensure that the health check traffic is allowed. Start by adding a rule to filter the logs based on the name of the Security Policy rule permitting the applicable traffic.

​​ Filter by rule name

If you do not see any traffic matching the filter, replace the filter with one that displays log entries based on the addresses associated with the CF_Health_Check_Anycast_01 and CF_Health_Check_Anycast_02 Address objects.

​​ Filter by health check Anycast IPs

​​ Policy-based forwarding

Troubleshooting policy-based forwarding can be a bit challenging. The ideal way to determine if traffic is flowing through the intended path is to select the detailed view for a log entry.

1. Select the magnifying glass next to one of the log entries with source IP address 172.64.240.253.

2. Traffic originating from CF_Health_Check_Anycast_01 (172.64.240.253) should ingress and egress interface tunnel.1.

3. Select the magnifying glass next to one of the log entries with source IP address 172.64.240.254.

4. Traffic originating from CF_Health_Check_Anycast_02 (172.64.240.254) should ingress and egress interface tunnel.2.

If the traffic is not ingressing/egressing the same interface, you likely have an issue with the policy-based forwarding rule(s) not matching.

​​ Security Policies - Production Traffic

As mentioned earlier, this tutorial includes examples for two different use-cases:

• Magic WAN: permit traffic between two or more locations with RFC-1918 Open external link private non-routable address space.
• Magic WAN with Cloudflare Zero Trust (Gateway egress): same as Magic WAN with the addition of outbound Internet access from Magic WAN protected sites egressing the Cloudflare edge network.

​​ Magic WAN only

Rules must be defined to facilitate traffic from the trust network to the Magic WAN protected sites. While it may be possible to define one rule for traffic in both directions, this example includes two rules:

• From Trust to Magic WAN protected sites.

• From Magic WAN protected sites to Trust.

​​ Trust to Magic WAN dashboard

​​ Trust to Magic WAN command line

​​ Magic WAN to Trust dashboard

​​ Magic WAN to Trust command line

​​ Policy-based forwarding - production traffic

Whether traffic ingresses or egresses ​​Palo Alto Networks Next-Generation Firewall​​, it is important to ensure that traffic is routed symmetrically. This is accomplished through the use of policy-based forwarding.

Policy-based forwarding rules are only required for egress traffic.

Any traffic destined for Magic WAN protected sites or Magic WAN protected sites with Gateway egress must be routed across the IPsec tunnels.

​​ Dashboard policy-based forwarding - Magic WAN production traffic via tunnel.1

​​ Command line policy-based forwarding - Magic WAN production traffic via tunnel.1

​​ Dashboard policy-based forwarding - Magic WAN production traffic via tunnel.2

​​ Command line policy-based forwarding - tunnel.2

​​ Magic WAN with Cloudflare Zero Trust (Gateway egress)

This section covers adding in support for the use of Cloudflare Gateway. Adding Cloudflare Gateway allows you to set up policies to inspect outbound traffic to the Internet through DNS, network, HTTP and egress filtering.

This use case can be supported in one of two ways:

• Option 1

  • Security Rule: Extend the scope of the Trust_to_Cloudflare_Magic_WAN_Allow rule to allow any destination address.
  • Policy-Based Forwarding: Extend the scope of PBF_Magic_WAN_Sites_01 and PBF_Magic_WAN_Sites_02 to allow any destination address.

• Option 2

  • Security Rule: Add a new rule below Trust_to_Cloudflare_Magic_WAN_Allow called Trust_to_MWAN_Gateway_Egress_Allow to allow traffic to any destination address except for the Magic WAN Protected Sites (using the Negate option).
  • Policy-Based Forwarding: Add a new rule below PBF_Magic_WAN_Sites_01 and PBF_Magic_WAN_Sites_02 to allow any destination address except for the Magic WAN Protected Sites (using the Negate option).

The following examples are based on Option 2.

​​ Security Rule: Trust to Gateway Egress

​​ Dashboard

​​ Command line

​​ Policy-based forwarding: Trust to Gateway egress via tunnel.1

​​ Dashboard

​​ Command line

​​ Policy-based forwarding: Trust to Gateway egress via tunnel.2

​​ Dashboard

​​ Command line

​​ Troubleshooting

Cloudflare recommends you consult PAN-OS 9.1 Administrators Guide - Interpret VPN Error Messages Open external link and PAN-OS 10.2 Administrators Guide - Interpret VPN Error Messages Open external link for general troubleshooting.