`
-
-### Configure IPsec Phase 1
-
-Add a new IPsec tunnel [Phase 1 entry](https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure-p1.html), with the following settings:
-
-- **General Information**
- - **Description**: `CF1_IPsec_P1`
-- **IKE Endpoint Configuration**
- - **Key exchange version**: _IKE_v2_
- - **Internet Protocol**: _IPv4_
- - **Interface**: _WAN_
- - **Remote gateway**: Enter your Cloudflare Anycast IP address.
-- **Phase 1 Proposal (Authentication)**
- - **Authentication method**: _Mutual PSK_
- - **My identifier**: _User Fully qualified domain name_ > `ipsec@long_string_of_letters_and_numbers`
(You can get this identifier from your Cloudflare IPsec tunnel configuration > **User ID**)
- - **Peer identifier**: _Peer IP Address_ (your Cloudflare Anycast IP)
- - **Pre-Shared Key**: Enter the PSK you have on your Cloudflare IPsec tunnel.
-- **Phase 1 proposal (Encryption algorithm)**
- - **Encryption algorithm**: _AES 256 bits_
- - **Key length**: _256 bits_
- - **Hash algorithm**: _SHA256_
- - **DH key group**: _20_
- - **Lifetime**: `86400`
+---
-### Configure IPsec Phase 2
-
-Add a new IPsec tunnel [Phase 2 entry](https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure-p2.html), with the following settings. You need to create an entry for tunnel 1 and 2, making the appropriate changes for the IP addresses for local and remote network:
-
-- **General Information**
- - **Description**: `CF1_IPsec_P2`
- - **Mode**: _Routed (VTI)_
-- **Networks**
- - **Local Network**: _Address_ > Upper IP address in the `/31` assigned in Cloudflare tunnel. For example, `10.252.2.27` for tunnel 1 and `10.252.2.29` for tunnel 2.
- - **Remote Network**: _Address_ > Lower IP address in the `/31` for Cloudflare side. For example, `10.252.2.26` for tunnel 1, and `10.252.2.28` for tunnel 2.
-- **Phase 2 Proposal (SA/Key Exchange)**
- - **Protocol**: _ESP_
- - **Encryption algorithm**: _AES 256 bits_
- - **Hash algorithm**: _SHA256_
- - **DH key group**: _20_
- - **Lifetime**: `28800`
-
-When you are finished, apply your changes. If you go to **Status** > **IPsec**, you should be able to check that both Phase 1 and Phase 2 are connected.
-
-
-
-
-
-
-
-### Interface assignments
-
-In **Interfaces** > **Assignments** > **Add**, create a new interface to assign to the first IPsec tunnel, with the following settings:
-
-- **General configuration**
- - **Description**: `CF1_IPsec_1`
- - **MSS**: `1446`
-- **Interface Assignments**
- - **WAN**: Add your WAN interface. For example, `vnet1`.
- - **LAN**: Add your LAN interface. For example, `vnet0`.
- - Add your **CF_IPsec_1** that you have created above for Phase 1.
-
-Select **Save** when you are finished.
-
-
-
-
-
-
-
-
-
-
-
-
-
-### Gateway
-
-In **System** > **Routing** > **Gateways** there should already be a gateway. For this example, it is named `CF1_IPSEC_1_VTIV4`.
-
-
-
-
-
-
-
-### Firewall Rules IPsec
-
-1. In **Firewall Rules** > **IPsec interface**, allow any type of traffic.
-
-
-
-
-
-
-
-2. Navigate to **Status** > **Gateways**. `CF1_IPSEC_1_VTIV4` should now be online.
-
-
-
-
-
-
-
-### Firewall Rules LAN
-
-1. In **Firewall** > **Rules** > **LAN**, allow any type of traffic.
-2. Expand the **Advanced** section.
-3. Change the Gateway to `CF1_IPSEC_1_VTIV4`.
-
-
-
-
+import { Render } from "~/components";
-
+
diff --git a/src/content/docs/magic-wan/configuration/manually/third-party/sonicwall.mdx b/src/content/docs/magic-wan/configuration/manually/third-party/sonicwall.mdx
index aa7fbfe7b55887..19864e9a4812f2 100644
--- a/src/content/docs/magic-wan/configuration/manually/third-party/sonicwall.mdx
+++ b/src/content/docs/magic-wan/configuration/manually/third-party/sonicwall.mdx
@@ -1,202 +1,18 @@
---
title: SonicWall
pcx_content_type: integration-guide
+
---
import { Render } from "~/components";
-This tutorial shows you how to use Magic WAN with the following versions of the SonicWall appliances:
-
-- **Hardware tested**:
- - SonicWall NSv 470
- - SonicWal 3700
-- **Software versions tested**:
- - SonicOS 7.0.1
-
-You can connect your SonicWall appliance through [IPsec tunnels](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/) to Magic WAN. Generic Routing Encapsulation (GRE) is not supported on SonicWall.
-
-## Topology
-
-
-
-The following instructions show how to setup an IPsec connection on your SonicWall device. We will use the IP ranges from the above topology example to create the connections needed. Settings not explicitly mentioned can be left with their default values.
-
-## 1. Create an IPsec tunnel on your Cloudflare account
-
-1. Start by [creating your IPsec tunnels](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/#add-tunnels) on Cloudflare. Name and describe the tunnels as needed, and add the following settings:
-
- - **Interface address**: Enter the internal tunnel IP on the Cloudflare side of the IPsec tunnel. In this example, it is `10.200.1.0/31`.
- - **Customer endpoint**: Enter the WAN IP address of your SonicWall device. In our example, this is `198.51.100.2`.
- - **Cloudflare endpoint**: Enter the IP address provided by Cloudflare. In our example, this is `1.2.3.4`.
- - **Pre-shared key**: Select **Use my own pre-shared key** and paste a secure key of your own.
-
-2. Select **Add tunnels** when you are finished.
-
-3. After you create your tunnel, Cloudflare dashboard will load a list of tunnels set up for your account. Select the arrow to expand the tunnels you have just created, and check the following settings:
-
- - **Customer endpoint**: Refers to the SonicWall WAN IP that the VPN policy is bound to (in red).
- - **Cloudflare endpoint**: Refers to the anycast IP provided by Cloudflare (in blue).
- - **FQDN ID**: The ID used in the VPN policy for the SonicWall's Local IKE ID. Copy this ID and save it. You will need it when configuring the tunnel on your SonicWall (in green).
-
- 
-
-:::note
-The interface address on the Cloudflare side of the tunnel is `10.200.1.0/31`. You will need to use `10.200.1.1/31` on the SonicWall side of the tunnel.
-:::
-
-## 2. Create static routes on Cloudflare dashboard
-
-Static routes are required for any networks that will be reached via the IPsec tunnel. In our example, there are two networks: `172.31.3.0/24` and the tunnel network `10.200.1.0/31`.
-
-1. [Create your static routes](/magic-wan/configuration/manually/how-to/configure-routes/#create-a-static-route). Name and describe them as needed, and add the following settings:
-
- - **First tunnel**: Following our example, add `10.200.1.0/31` as the **Prefix** and `10.200.1.1` for the **Tunnel/Next hop**.
- - **Second tunnel**: Following our example, add `172.31.3.0/24` as the **Prefix** and `10.200.1.1` for the **Tunnel/Next hop**.
-
-2. Select **Add routes** when you are finished.
-
-## 3. Add a VPN configuration in SonicWall
-
-1. Go to **Network** > **IPsec VPN** > **Rules and Settings**.
-2. Select **Add**.
-3. In **General** > **Security Policy** group, add the following settings:
- - **Authentication Method**: _IKE Using Preshared Secret_.
- - **IPsec Primary Gateway Name or Address**: Enter Cloudflare's anycast IP address for the primary gateway (in blue).
-4. In the **IKE Authentication** group, add the following settings:
- - **Shared secret**: Paste the pre-shared key you use to create the IPsec tunnel in step 1 (in purple).
- - **Local IKE ID**: Select _Domain name_ from the dropdown menu, and paste here the **FQDN ID** you saved from step 1, after creating the IPsec tunnel (in green).
- - **Peer IKE IDE**: Select _IPv4_ Address from the dropdown menu, and enter the Cloudflare anycast IP address (in blue).
-
-
-
-
-
-
-
-5. Select **Proposals**. VPN Policy is somewhat flexible. Adjust these settings to match your organization's preferred security policy. As an example, you can use the settings in the examples below.
-6. In the **IKE (Phase 1) Proposal** group, select the following settings:
- - **Exchange**: _IKEv2 Mode_
- - **DH Group**: _Group 20_
- - **Encryption**: _AES-256_
- - **Authentication**: _SHA256_
- - **Life Time (seconds)**: `86400`
-7. In the **IPsec (Phase 2) Proposal** group, add the following settings:
- - **Protocol**: _ESP_
- - **Encryption**: _AESGCM16-256_
- - **Authentication**: _None_
- - **Enable Perfect Forward Secrecy**: Enabled
- - **DH Group**: _Group 20_
- - **Life Time (seconds)**: `28800`
-8. Select **Advanced**.
-9. Enable **Disable IPsec Anti-Replay**.
-10. In **VPN Policy bound to** select your WAN interface from the dropdown menu, to bind it to your VPN.
-11. Select **Save**.
-
-
-
-
-
-
-
-## 4. Add a VPN tunnel interface
-
-SonicOS requires a VPN tunnel interface to route traffic via Magic WAN. When creating the interface, use the prefix `10.200.1.1/31`. This matches with the Cloudflare side for this tunnel, which is `10.200.1.0`.
-
-:::note
-You will need to use a different IP pair for each tunnel/site.
-:::
-
-1. Go to **Network** > **System** > **Interfaces**.
-2. Select **Add interface** > **VPN Tunnel Interface**.
-3. For IP Address, use `10.200.1.1`.
-4. Enable **Ping**. This is required so the interface can be pinged for debugging and Magic WAN health checks.
-
-
-
-
-
-
-
-5. Select **Advanced**.
-6. Enable the **Enable Asymmetric Route Support** option. This is required for the Magic WAN tunnel health check.
-
-
-
-
-
-
-
-7. Select **OK**.
-
-## 5. Add address object(s)
-
-Address objects are necessary for route policies. In our example, we have one other site that will be reached via Magic WAN. First, you need to create address objects for each network. Then, you need to create an address group that contains all the remote networks. This address group will be used in the next step to create the correct route policies.
-
-To add an address object:
-
-1. Select **Object** > **Match Objects** > **Addresses**
-2. Select **Address Objects** > **Add**.
-3. Enter the information for your address object - refer to the topology image for the examples this tutorial is using. Since the addresses are in the VPN zone, set the **Zone Assignment** for the object to _VPN_.
-4. Select **Save**. The window will stay on to facilitate multiple entries. Select **X** to close it.
-
-
-
-
-
-
-
-5. Select **Address Groups** > **Add** to add a new address group.
-6. Enter a **Name** for your address group.
-7. Select the individual network objects you have created on the left menu, and add them to the group by selecting the right-facing arrow in the middle column.
-8. Select **Save**.
-
-
-
-
-
-
-
-## 6. Set up routing
-
-Add a route using the address object or group just created as the destination.
-
-1. Select **Policy** > **Rules and Policies** > **Routing Rules**.
-2. Select **Add** to add your route policy.
-3. The **Next Hop** should be the VPN tunnel interface that was previously created in the interface panel.
-
-## 7. Add access rule for health checks
-
-An additional access rule is required for Magic WAN health checks to work properly. This will enable the WAN IP to receive ICMP pings via the tunnel, and return them over the WAN.
-
-1. Select **Policy** > **Rules and Policies**.
-2. Select **Access Rules** > **Add**.
-3. Enter a descriptive name for your policy.
-4. In **Source / Destination** > **Destination > Port/Services**, select _ICMP_ from the dropdown.
-5. Select **Optional Settings**.
-6. In **Others**, enable **Allow Management traffic**.
-
-## 8. Setup health checks
-
-You have to [configure Magic WAN health checks](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/#add-tunnels) correctly. Here is an example of how to set up health checks:
-
-```bash
-curl --request PUT \
-https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels/{tunnel_id} \
---header "X-Auth-Email: " \
---header "X-Auth-Key: " \
---header "Content-Type: application/json" \
---data '{
- "health_check": {
- "direction": "bidirectional",
- "enabled": true,
- "type": "request",
- "rate": "low"
- }
-}'
-```
-
-Health checks might take some time to stabilize after the configuration is changed.
-
-## 9. Verify tunnel status on Cloudflare dashboard
-
-The Cloudflare dashboard monitors the health of all anycast tunnels on your account that route traffic from Cloudflare to your origin network. Refer to [Check tunnel health in the dashboard](/magic-wan/configuration/common-settings/check-tunnel-health-dashboard/) for more information.
\ No newline at end of file
+
diff --git a/src/content/docs/magic-wan/configuration/manually/third-party/sophos-firewall.mdx b/src/content/docs/magic-wan/configuration/manually/third-party/sophos-firewall.mdx
index 366116bb94fdd1..60ba6dd563e701 100644
--- a/src/content/docs/magic-wan/configuration/manually/third-party/sophos-firewall.mdx
+++ b/src/content/docs/magic-wan/configuration/manually/third-party/sophos-firewall.mdx
@@ -1,264 +1,17 @@
---
title: Sophos Firewall
pcx_content_type: integration-guide
+
---
import { Render } from "~/components";
-This tutorial shows you how to use Magic WAN with the following versions of the Sophos Firewall:
-
-- **Sophos form factor tested:**
-
- - Sophos Firewall XGS and XG series hardware
- - Sophos Firewall virtual appliance on VMware
-
-- **Sophos software versions tested:**
- - SFOS Version 19.0 MR2-Build 472
- - SFOS Version 19.5.1 MR1-Build 278
-
-You can connect through[ Generic Routing Encapsulation (GRE) or IPsec tunnels](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/) to Magic WAN.
-
-## IPsec connection
-
-The following instructions show how to setup an IPsec connection on your Sophos Firewall device. Settings not explicitly mentioned can be left with their default values.
-
-### 1. Add an IPsec profile
-
-1. Go to **System** > **Profiles**.
-2. In **IPsec profiles**, select **Add**.
-3. In the **General settings** group, make sure you have the following settings:
- - **Name**: Give your profile a descriptive name.
- - **Key exchange**: **IKEv2**
- - **Authentication mode**: **Main mode**
-4. In the **Phase 1** group, make sure you have the following settings:
- - **DH group (key group)**: _20_
- - **Encryption**: _AES256_
- - **Authentication**: _SHA2 256_
-5. In the **Phase 2** group, select the following:
- - **PFS group (DH group)**: _Same as phase-1_
- - **Key life**: _28800_
- - **Encryption**: _AES256_
- - **Authentication**: _SHA2 256_
-6. Enable **Dead Peer Detection**.
-7. In **When peer unreachable**, select _Re-initiate_.
-8. Select **Save**.
-
-### 2. Create IPsec connection tunnel
-
-The next step involves configuring a site-to-site IPsec VPN connection on your Sophos Firewall device.
-
-1. Go to **Configure** > **Site-to-site VPN**.
-2. In **IPsec**, select **Add**.
-3. In the **General settings** group, make sure you have the following settings:
- - **Name**: Give your site-to-site VPN a descriptive name.
- - **Connection type**: _Tunnel interface_
- - **Gateway type**: _Initiate the connection_
-4. In the **Encryption** group, make sure you have the following settings:
- - **Authentication type**: **Preshared key**
-5. In **Gateway settings**, make sure you have the following settings:
- - **Gateway address**: Enter your Cloudflare anycast IP address provided by Cloudflare.
- - **Local ID type**: Add the [IKE ID](/magic-wan/reference/gre-ipsec-tunnels/#supported-ike-id-formats) provided by Cloudflare.
-
-
-
-After setting up your IPsec tunnel, it will show up on the IPsec connections list with an **Active** status.
-
-
-
-### 3. Assign the XFRM interface address
-
-You must use an interface address from the `/31` subnet required to [configure tunnel endpoints](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/) on Magic WAN.
-
-1. Go to **Configure** > **Network**.
-2. In **Interfaces**, select the corresponding interface to the IPsec tunnel you created in [step 2](#2-create-ipsec-connection-tunnel).
-3. Edit the interface to assign an address from the `/31` subnet required to [configure tunnel endpoints](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/). When you are finished, it should look similar to the following:
-
-
-
-### 4. Add a firewall rule
-
-1. Go to **Protect** > **Rules and policies**.
-2. In **Firewall rules**, create a firewall rule with the criteria and security policies from your company that allows traffic to flow between Sophos and Magic WAN.
-
-
-
-### 5. Disable IPsec anti-replay
-
-You will have to disable IPsec Anti-Replay on your Sophos Firewall. Changing the anti-replay settings restarts the IPsec service, which causes tunnel-flap for all IPsec tunnels. This will also disable IPsec anti-replay protection for all VPN connections globally. Plan these changes accordingly.
-
-Below are instruction on how to achieve this on SFOS version 19 and SFOS version 19.5:
-
-#### SFOS 19.0 MR2-Build 472 or 19.5 MR1-Build278 or later versions:
-
-1. Sign in to the CLI.
-2. Enter **4** to choose **Device console**, and enter the following command:
-
- ```bash
- set vpn ipsec-performance anti-replay window-size 0
- ```
-
- 
-
-#### Older SFOS versions
-
-Contact Sophos support.
-
-## GRE connection
-
-### 1. Configure a GRE tunnel between SFOS and Cloudflare
-
-Start by configuring a GRE tunnel between SFOS and the Cloudflare anycast IP address.
-
-1. Sign in to the CLI.
-2. Enter **4** to choose **Device console**, and enter the following command:
-
- ```bash
- system gre tunnel add name local-gw remote-gw local-ip remote-ip
- ```
-
- 
-
- For more details, refer to the [Sophos Firewall knowledge base](https://support.sophos.com/support/s/article/KB-000035813?language=en_US).
-
-### 2. Add a GRE or SD-WAN route to redirect traffic through the GRE tunnel
-
-The detailed information on how to add a GRE or SD-WAN route to redirect traffic through the GRE tunnel, is in the next section ([Traffic redirection mechanism on Sophos Firewall](#traffic-redirection-mechanism-on-sophos-firewall)).
-
-### 3. Add a firewall rule for LAN/DMZ to VPN
-
-Create a firewall rule with the criteria and security policies from your company that allows traffic to flow between Sophos and Magic WAN. This firewall rule should include the required networks and services.
-
-1. Go to **Protect** > **Rules and policies**.
-2. In **Firewall rules**, select **IPv4** > **Add firewall rule**.
-
-
-
-## Traffic redirection mechanism on Sophos Firewall
-
-To redirect traffic, you can add a static or an SD-WAN route.
-
-### IPsec
-
-#### Static route
-
-Go to **Configure** > **Routing** > **Static routes** to add an XFRM interface-based route. The interface will be automatically created when you set up a tunnel interface based on IPsec (such as the Cloudflare_MWAN example from above).
-
-
-
-#### SD-WAN route
-
-1. Go to **Configure** > **Routing** > **Gateways** to create a custom gateway on the XFRM interface. The interface will be automatically created when you set up a tunnel interface based on IPsec (such as the Cloudflare_MWAN example from above).
-
-
-
-2. In **Configure** > **Routing** > **SD-WAN routes**, select **Add** to add the desired networks and services in the route to redirect traffic to Cloudflare. Enter a descriptive name for your connection, and the IP addresses you set up for your IPsec tunnels in **Incoming interface** and **Source networks**. Do not forget to choose the correct **Primary gateway** option.
-
-
-
-### GRE
-
-Add a GRE or SD-WAN route or both.
-
-#### GRE route
-
-Add the route on the CLI.
-
-1. Sign in to the CLI.
-2. Enter **4** to choose **Device console**, and enter the following command to create the tunnel:
-
-```bash
-system gre route add net tunnelname
-```
-
-
-
-#### SD-WAN route
-
-1. Add a custom gateway on GRE with the peer IP address (from the `/31` subnet you chose earlier) as the Gateway IP address, and disable **Health check**.
-
-
-
-2. Add an SD-WAN route with the desired networks and services in the route to redirect traffic to Cloudflare.
-
-
-
-## Verify tunnel status on Cloudflare dashboard
-
-The Cloudflare dashboard monitors the health of all anycast tunnels on your account that route traffic from Cloudflare to your origin network. Refer to [Check tunnel health in the dashboard](/magic-wan/configuration/common-settings/check-tunnel-health-dashboard/) for more information.
-
-### Make Cloudflare health checks work
-
-1. The ICMP probe packet from Cloudflare must be the type ICMP request, with anycast source IP. In the following example, we have used `172.64.240.252` as a target example:
-
-```bash
-curl --request PUT \
-https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels/{tunnel_id} \
---header "X-Auth-Email: " \
---header "X-Auth-Key: " \
---header "Content-Type: application/json" \
---data '{
- "health_check": {
- "enabled": true,
- "target": "172.64.240.252",
- "type": "request",
- "rate": "mid"
- }
-}'
-```
-
-2. Go to **Configure** > **Network** > **Interfaces** > **Add alias**. Add the IP address provided by Cloudflare for the ICMP probe traffic. This is needed to prevent Sophos firewall from dropping them as spoof packets. This is not the same IP used to create VPN. This is the special IP address for probe traffic only.
-
-
-
-3. ICMP reply from SFOS should go back via the same tunnel on which the probe packets are received. You will need to create an additional SD-WAN policy route.
-
-
-
-Packet flow will look like the following:
-
-```sh
-tcpdump -nn proto 1
-```
-
-```sh output
-tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
-listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
-
-13:09:55.500453 xfrm1, IN: IP 172.70.51.31 > 172.64.240.252: ICMP echo request, id 33504, seq 0, length 64
-13:09:55.500480 xfrm1, OUT: IP 172.64.240.252 > 172.70.51.31: ICMP echo reply, id 33504, seq 0, length 64
-
-13:09:55.504669 xfrm1, IN: IP 172.71.29.66 > 172.64.240.252: ICMP echo request, id 60828, seq 0, length 64
-13:09:55.504695 xfrm1, OUT: IP 172.64.240.252 > 172.71.29.66: ICMP echo reply, id 60828, seq 0, length 64
-```
-
-## Verify tunnel status on Sophos Firewall dashboard
-
-### IPsec
-
-When the tunnel is working, its **Status** will be green.
-
-
-
-The corresponding XFRM interface will also show a **Connected** status.
-
-
-
-### GRE
-
-Access the CLI and type `system gre tunnel show` to check the status of a GRE tunnel. When the tunnel is working, its Status will show up as **Enabled**.
-
-
-
-
-
-## Troubleshooting
-
-If a tunnel shows a connected status at both ends, but is not established:
-
-- Check if the IPsec profile configuration is correct.
-- Make sure the corresponding tunnel interfaces are up.
-- Make sure routing configuration and route precedence are correctly set on SFOS.
-- Make sure a static back route is added on Cloudflare.
-- Firewall rules for specific zones and host or service must be added in SFOS. GRE and IPsec belong to the VPN zone.
-- Perform `tcpdump` to check if packets are going through the VPN or GRE tunnel as expected.
-- Perform a packet capture on Cloudflare to see if traffic is reaching the Cloudflare platform.
+
diff --git a/src/content/docs/magic-wan/configuration/manually/third-party/strongswan.mdx b/src/content/docs/magic-wan/configuration/manually/third-party/strongswan.mdx
index 1b63e7e8c2f74a..f557229b984794 100644
--- a/src/content/docs/magic-wan/configuration/manually/third-party/strongswan.mdx
+++ b/src/content/docs/magic-wan/configuration/manually/third-party/strongswan.mdx
@@ -1,198 +1,14 @@
---
pcx_content_type: integration-guide
title: strongSwan
----
-
-This tutorial explains how to set up strongSwan along with Magic WAN. You will learn how to configure strongSwan, configure an IPsec tunnel and create a Policy Based Routing.
-
-## 1. Health checks configuration
-
-Start by configuring the [bidirectional health checks](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/#add-tunnels) target for Magic WAN. For this particular tutorial, we are using `172.64.240.252` as the target IP address, and `type` as the request.
-
-This can be set up [with the API](/api/resources/magic_transit/subresources/ipsec_tunnels/methods/update/). For example:
-
-```bash
-curl --request PUT \
-https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels/{tunnel_id} \
---header "X-Auth-Email: " \
---header "X-Auth-Key: " \
---header "Content-Type: application/json" \
---data '{
- "health_check": {
- "enabled": true,
- "target": "172.64.240.252",
- "type": "request",
- "rate": "mid"
- }
-}'
-```
-
-## 2. Configure StrongSwan
-
-1. Start by [installing StrongSwan](https://docs.strongswan.org/docs/5.9/install/install.html). For example, open the console and run:
-
-```sh
-sudo apt-get install strongswan -y
-```
-
-2. After StrongSwan finishes installing, go to `/etc/strongswan.conf` to edit the configuration file and add the following settings:
-
-```txt
-charon {
- load_modular = yes
- install_routes = no
- install_virtual_ip = no
-
- plugins {
- include strongswan.d/charon/*.conf
- }
-}
-
-include strongswan.d/*.conf
-```
-
-## 3. Configure IPsec file
-
-1. Go to `/etc/ipsec.conf` and add the following settings:
-
-```txt
-# ipsec.conf - strongSwan IPsec configuration file
-config setup
- charondebug="all"
- uniqueids = yes
-
-conn %default
- ikelifetime=24h
- rekey=yes
- reauth=no
- keyexchange=ikev2
- authby=secret
- dpdaction=restart
- closeaction=restart
-
-# Sample VPN connections
-conn cloudflare-ipsec
- auto=start
- type=tunnel
- fragmentation=no
- leftauth=psk
- # Private IP of the VM
- left=%any
- # Tunnel ID from dashboard, in this example FQDN is used
- leftid=..ipsec.cloudflare.com
- leftsubnet=0.0.0.0/0
- # Cloudflare Anycast IP
- right=
- rightid=
- rightsubnet=0.0.0.0/0
- rightauth=psk
- ike=aes256-sha256-ecp384!
- esp=aes256-sha256-ecp384!
- replay_window=0
- mark_in=42
- mark_out=42
- leftupdown=/etc/strongswan.d/ipsec-vti.sh
-```
-
-2. Now, you need to create a virtual tunnel interface (VTI) with the IP we configured earlier as the target for Cloudflare's health checks (`172.64.240.252`) to route IPsec packets. Go to `/etc/strongswan.d/`.
-
-3. Create a script called `ipsec-vti.sh` and add the following:
-
-```txt
-#!/bin/bash
-
-set -o nounset
-set -o errexit
-VTI_IF="vti0"
-
-case "${PLUTO_VERB}" in
- up-client)
- ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti \
- key "${PLUTO_MARK_OUT%%/*}"
- ip link set "${VTI_IF}" up
- ip addr add 172.64.240.252/32 dev vti0
- sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1"
- sysctl -w "net.ipv4.conf.${VTI_IF}.rp_filter=0"
- sysctl -w "net.ipv4.conf.all.rp_filter=0"
- ip rule add from 172.64.240.252 lookup viatunicmp
- ip route add default dev vti0 table viatunicmp
- ;;
- down-client)
- ip tunnel del "${VTI_IF}"
- ip rule del from 172.64.240.252 lookup viatunicmp
- ip route del default dev vti0 table viatunicmp
- ;;
-esac
-echo "executed"
-```
-
-## 4. Add Policy Based Routing (PBR)
-
-Although the IPsec tunnel is working as is, we need to create Policy Based Routing (PBR) to redirect returning traffic via the IPsec tunnel. Without it, the ICMP replies to the health probes sent by Cloudflare will be returned via the Internet, instead of the same IPsec tunnel. This is required to avoid any potential issues.
-
-To accomplish this, the tutorial uses [iproute2](https://en.wikipedia.org/wiki/Iproute2) to route IP packets from `172.63.240.252` to the tunnel interface.
-
-1. Go to `/etc/iproute2/`.
-
-2. Edit the `rt_tables` file to add a routing table number and name. In this example, we used `viatunicmp` as the name and `200` as the number for the routing table.
-
-```txt
-#
-# reserved values
-#
-255 local
-254 main
-253 default
-0 unspec
-200 viatunicmp
-#
-# local
-#
-#1 inr.ruhep
-```
-
-3. Open the console and add a rule to match the routing table just created. This rule instructs the system to use routing table `viatunicmp` if the packet's source address is `172.64.240.252`:
-
-```sh
-ip rule add from 172.64.240.252 lookup viatunicmp
-```
-
-4. Add a route to the newly created routing table `viatunicmp`. This is the default route via the interface `vti0` in the `viatunicmp` table.
-
-```sh
-ip route add default dev vti0 table viatunicmp
-```
-
-5. Now, you can `start` IPsec. You can also `stop`, `restart` and show the `status` for the IPsec connection:
-
-```bash
-ipsec start
-```
-
-```bash output
-Security Associations (1 up, 0 connecting):
-cloudflare-ipsec[1]: ESTABLISHED 96 minutes ago, .ipsec.cloudflare.com]...162.159.67.88[162.159.67.88]
-cloudflare-ipsec{4}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c4e20a95_i c5373d00_o
-cloudflare-ipsec{4}: 0.0.0.0/0 === 0.0.0.0/0
-```
-
-## 5. Check connection status
-
-After you finish configuring StrongSwan with Magic WAN, you can use tcpdump to investigate the status of health checks originated from Cloudflare.
-
-```sh
-sudo tcpdump -i esp and host
-```
-
-In this example, the outgoing Internet interface shows that the IPsec encrypted packets (ESP) from Cloudflare's health check probes (both the request and response) are going through the IPsec tunnel we configured.
-
-
-
-You can also run tcpdump on `vti0` to check the decrypted packets.
+---
-```sh
-sudo tcpdump -i vti0 host 172.64.240.252
-```
+import { Render } from "~/components";
-
+
diff --git a/src/content/docs/magic-wan/configuration/manually/third-party/viptela.mdx b/src/content/docs/magic-wan/configuration/manually/third-party/viptela.mdx
index 88b4685d086f99..68b7d84cf6b6d1 100644
--- a/src/content/docs/magic-wan/configuration/manually/third-party/viptela.mdx
+++ b/src/content/docs/magic-wan/configuration/manually/third-party/viptela.mdx
@@ -4,97 +4,13 @@ pcx_content_type: integration-guide
---
-Cloudflare partners with Cisco's SD-WAN solution to provide users with an integrated SASE solution. The Cisco SD-WAN appliances (physical and virtual) manage subnets associated with branch offices and cloud instances. Anycast Tunnels are set up between these SD-WAN edge devices and Cloudflare to securely route Internet-bound traffic. This tutorial describes how to configure the Cisco Catalyst 8000 Edge Platforms (physical or virtual) in the SD-WAN mode for north-south (Internet-bound) use cases.
-
-## Prerequisites
-
-Before setting up a connection between Cisco SD-WAN and Cloudflare, you must have:
-
-- Purchased Magic WAN and Secure Web Gateway.
-- Cloudflare provision Magic WAN and Secure Web Gateway.
-- Received two Cloudflare tunnel endpoints (anycast IP address) assigned to Magic WAN.
-- Cisco SD-WAN appliances (physical or virtual). This ensures specific Internet-bound traffic from the sites' private networks is routed over the anycast GRE tunnels to Secure Web Gateway to enforce a user's specific web access policies.
-- A static IP pair to use with the tunnel endpoints. The static IPs should be /31 addresses separate from the IPs used in the subnet deployment.
-- Release 20.6 Controllers and vEdge Device Builds. You should also pair them with devices that are on at least version Cisco IOS XE SD-WAN 17.6. Refer to [Cisco documentation](https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/215676-cisco-tac-and-bu-recommended-sd-wan-soft.html) to learn more Cisco softweare versions.
-
-:::note[Note]
-The SASE integration between Cisco SD-WAN and Cloudflare SSE was validated with Cisco SD-WAN 20.6.2 version with Catalyst 8kv router. For connectivity, we used GRE tunnels.
-:::
-
-## 1. Create a SIG template on Cisco vManage
-
-Cisco vManage is Cisco's SD-WAN management tool that is used to manage all the SD-WAN appliances in branch offices.
-
-For this example scenario, a generic template for `SIG-Branch` was created.
-
-
-
-To create a Secure Internet Gateway (SIG) using vManage:
-
-1. From **Cisco vManage** under **Configuration**, select **Generic** and **Add Tunnel**.
-2. Refer to the table below for the setting fields and their options.
-
-| Setting | Type/Detail |
-| ------------------- | ----------------------------------------- |
-| **Global Template** | Factory_Default_Global_CISCO_Template |
-| **Cisco Banner** | Factory_Default_Retail_Banner |
-| **Policy** | Branch-Local-Policy |
-
-**Transport & Management VPN settings**
-
-| Setting | Type/Detail |
-| --------------------------------- | ----------------------------------- |
-| **Cisco VPN 0** | GCP-Branch-VPN0 |
-| **Cisco Secure Internet Gateway** | Branch-SIG-GRE-Template |
-| **Cisco VPN Interface Ethernet** | GCP-Branch-Public-Internet-TLOC |
-| **Cisco VPN Interface Ethernet** | GCP-VPN0-Interface |
-| **Cisco VPN 512** | Default_AWS_TGW_CSR_VPN512_V01 |
-
-**Basic Information settings**
-
-| Setting | Type/Detail |
-| ------------------ | ------------------------------------------- |
-| **Cisco System** | Default_BootStrap_Cisco_System_Template |
-| **Cisco Logging** | Default_Logging_Cisco_V01 |
-| **Cisco AAA** | AWS-Branch-AAA-Template |
-| **Cisco BFD** | Default_BFD_Cisco-V01 |
-| **Cisco OMP** | Default_AWS_TGW_CSR_OMP_IPv46_... |
-| **Cisco Security** | Default_Security_Cisco_V01 |
-
-When creating the Feature Template, you can choose values that apply globally or that are device specific. For example, the **Tunnel Source IP Address**, **Interface Name** and fields from **Update Tunnel** are device specific and should be chosen accordingly.
-
-## 2. Create tunnels in vManage
-
-From vManage, select **Configuration** > **Templates**. You should see the newly created template where you will update the device values.
-
-Because the template was created to add GRE tunnels, you only need to update the device values. Note that **VPN0** is the default, and the WAN interface used to build the tunnel must be part of **VPN0**.
-
-
-
-## 3. Create tunnels in Cloudflare
-
-Refer to [Configure tunnel endpoints](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/) for more information on creating a GRE tunnel.
-
-
-
-## 4. Define static routes
-
-Refer to [Configure static routes](/magic-wan/configuration/manually/how-to/configure-routes/#create-a-static-route) for more information on configuring your static routes.
-
-
-
-## 5. Validate traffic flow
-
-In the example below, a request for `neverssl.com` was issued, which has a Cloudflare policy blocking traffic to `neverssl`.com.
-
-On the client VM (192.168.30.3), a blocked response is visible.
-
-
-
-A matching blocked log line is visible from the Cloudflare logs.
-
-
-
-## Add new tunnels using IPsec
-
-IPsec tunnels to Cloudflare can only be created on Cisco 8000v in the router mode today. Refer to the [Cisco IOS XE](/magic-wan/configuration/manually/third-party/cisco-ios-xe/) for more information.
+import { Render } from "~/components";
+
+
diff --git a/src/content/docs/magic-wan/configuration/manually/third-party/vyos.mdx b/src/content/docs/magic-wan/configuration/manually/third-party/vyos.mdx
index 9a95c12232af55..75d0c6a9d07019 100644
--- a/src/content/docs/magic-wan/configuration/manually/third-party/vyos.mdx
+++ b/src/content/docs/magic-wan/configuration/manually/third-party/vyos.mdx
@@ -1,74 +1,10 @@
---
pcx_content_type: integration-guide
title: VyOS
-
---
-This tutorial contains configuration information and a sample template for using a VyOS device with an IPsec configuration.
-
-## Notes
-
-- `vti ` - Defines the ESP group for encrypted traffic defined by the tunnel or defines a particular ESP policy or profile.
-- `ike-group ` - Defines IKE group to use for key exchanges or defines a particular IKE policy or profile.
-- The IP addresses of the IPsec tunnel interfaces on both ends of the tunnel should be a pair of private IP addresses (RFC 1918) on the same /31 or /30 subnet, essentially specifying a point-to-point link.
-- The IPsec tunnel endpoint on this VyOS router is the ``.
-- The IP address of the IPsec tunnel endpoint on the Cloudflare side is the anycast IP address provided by Cloudflare.
-- This router is configured to initiate the IPsec tunnel connection.
-
-## Configuration parameters
-
-### Phase 1
-
-- **Encryption**
- - AES-GCM with 128-bit or 256-bit key length
-
-- **Integrity**
- - SHA512
-
-### Phase 2
-
-- **Encryption**
- - AES-GCM with 128-bit or 256-bit key length
-
-- **Integrity**
- - SHA512
-
-- **PFS group**
- - DH group 20 (348-bit random ECP group)
-
-## Configuration template
+import { Render } from "~/components";
-```bash
-set interfaces vti address
-''
-set vpn ipsec esp-group compression 'disable'
-set vpn ipsec esp-group lifetime '86400'
-set vpn ipsec esp-group mode 'tunnel'
-set vpn ipsec esp-group pfs 'enable'
-set vpn ipsec esp-group proposal 1 encryption 'aes256gcm128'
-set vpn ipsec esp-group proposal 1 hash 'sha512'
-set vpn ipsec ike-group close-action 'none'
-set vpn ipsec ike-group dead-peer-detection action 'restart'
-set vpn ipsec ike-group dead-peer-detection interval '30'
-set vpn ipsec ike-group dead-peer-detection timeout '120'
-set vpn ipsec ike-group ikev2-reauth 'no'
-set vpn ipsec ike-group key-exchange 'ikev2'
-set vpn ipsec ike-group lifetime '28800'
-set vpn ipsec ike-group mobike 'disable'
-set vpn ipsec ike-group proposal 1 dh-group '20'
-set vpn ipsec ike-group proposal 1 encryption 'aes256gcm128'
-set vpn ipsec ike-group proposal 1 hash 'sha512'
-set vpn ipsec ipsec-interfaces interface ''
-set vpn ipsec logging log-level '2'
-set vpn ipsec options disable-route-autoinstall
-set vpn ipsec site-to-site peer authentication id ''
-set vpn ipsec site-to-site peer authentication pre-shared-secret ''
-set vpn ipsec site-to-site peer authentication remote-id ''
-set vpn ipsec site-to-site peer connection-type 'initiate'
-set vpn ipsec site-to-site peer ike-group ''
-set vpn ipsec site-to-site peer ikev2-reauth 'no'
-set vpn ipsec site-to-site peer local-address ''
-set vpn ipsec site-to-site peer vti bind ''
-set vpn ipsec site-to-site peer vti esp-group ''
-```
+
diff --git a/src/content/docs/magic-wan/reference/device-compatibility.mdx b/src/content/docs/magic-wan/reference/device-compatibility.mdx
index 7a1cd66c721512..74e36ff9498275 100644
--- a/src/content/docs/magic-wan/reference/device-compatibility.mdx
+++ b/src/content/docs/magic-wan/reference/device-compatibility.mdx
@@ -5,39 +5,28 @@ sidebar:
order: 3
---
-import { GlossaryTooltip } from "~/components"
+import { Render } from "~/components";
-Magic WAN is compatible with any device that supports IPsec with the [supported configuration parameters](/magic-wan/reference/gre-ipsec-tunnels/#supported-configuration-parameters) or supports GRE.
-
-The matrix below includes example devices and links to the integration guides.
-
-| Appliance | GRE tunnel | IPsec tunnel |
-| --- | --- | --- |
-| [Aruba EdgeConnect](/magic-wan/configuration/manually/third-party/aruba-edgeconnect/) |✅ | ✅ |
-| Cisco ASA | Compatibility on roadmap | Specifications compatible[^1] |
-| [Cisco IOS XE](/magic-wan/configuration/manually/third-party/cisco-ios-xe/) | ✅ | ✅ |
-| Cisco Meraki | Compatibility on roadmap | Compatibility on roadmap |
-| [Cisco SD-WAN](/magic-wan/configuration/manually/third-party/viptela/) | ✅ | ✅ |
-| [Fortinet](/magic-wan/configuration/manually/third-party/fortinet/)| Specifications compatible[^1] | ✅ |
-| [Furukawa Electric FITELnet](/magic-wan/configuration/manually/third-party/fitelnet/) | - | ✅ |
-| [Juniper Networks SRX Series Firewalls](/magic-wan/configuration/manually/third-party/juniper/) | - | ✅ |
-| [Palo Alto Networks Next-Generation Firewall](/magic-wan/configuration/manually/third-party/palo-alto/) | ✅ | ✅ |
-| [pfSense](/magic-wan/configuration/manually/third-party/pfsense/)| ✅ | ✅ |
-| Prisma SD-WAN (Palo Alto) | Specifications compatible[^1] | Specifications compatible[^1] |
-| Riverbed | Specifications compatible[^1] | Specifications compatible[^1] |
-| [SonicWall](/magic-wan/configuration/manually/third-party/sonicwall/)| - | ✅ |
-| [Sophos Firewall](/magic-wan/configuration/manually/third-party/sophos-firewall/) | ✅ | ✅ |
-| [strongSwan](/magic-wan/configuration/manually/third-party/strongswan/) | - | ✅ |
-| Velocloud | Compatibility on roadmap | Compatibility on roadmap |
-| Versa | Specifications compatible[^1] | Compatibility on roadmap |
-| [VyOS](/magic-wan/configuration/manually/third-party/vyos/)| ✅ | ✅ |
-
-| VPN | GRE tunnel | IPsec tunnel |
-| --- | --- | --- |
-| [Alibaba Cloud VPN Gateway](/magic-wan/configuration/manually/third-party/alibaba-cloud/) | - | ✅ |
-| [Amazon AWS Transit Gateway](/magic-wan/configuration/manually/third-party/aws/) | - | ✅ |
-| [Azure VPN Gateway](/magic-wan/configuration/manually/third-party/azure/) | - | ✅ |
-| [GCP Cloud VPN](/magic-wan/configuration/manually/third-party/google/) | - | ✅ |
-| [Oracle Cloud](/magic-wan/configuration/manually/third-party/oracle/) | - | ✅ |
-
-[^1]: Specifications compatible per vendor documentation
+
diff --git a/src/content/partials/networking-services/magic-wan/reference/device-compatibility.mdx b/src/content/partials/networking-services/magic-wan/reference/device-compatibility.mdx
new file mode 100644
index 00000000000000..b329ab405a0144
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/reference/device-compatibility.mdx
@@ -0,0 +1,59 @@
+---
+params:
+ - productName
+ - supportedConfigurationParametersUrl
+ - arubaEdgeconnectUrl
+ - ciscoIosXeUrl
+ - ciscoSdWanUrl
+ - fortinetUrl
+ - fitelnetUrl
+ - juniperUrl
+ - paloAltoUrl
+ - pfsenseUrl
+ - sonicwallUrl
+ - sophosFirewallUrl
+ - strongswanUrl
+ - vyosUrl
+ - alibabaCloudUrl
+ - awsUrl
+ - azureUrl
+ - googleUrl
+ - oracleUrl
+---
+
+import { GlossaryTooltip } from "~/components"
+
+{props.productName} is compatible with any device that supports IPsec with the supported configuration parameters or supports GRE.
+
+The matrix below includes example devices and links to the integration guides.
+
+| Appliance | GRE tunnel | IPsec tunnel |
+| --- | --- | --- |
+| Aruba EdgeConnect |✅ | ✅ |
+| Cisco ASA | Compatibility on roadmap | Specifications compatible[^1] |
+| Cisco IOS XE | ✅ | ✅ |
+| Cisco Meraki | Compatibility on roadmap | Compatibility on roadmap |
+| Cisco SD-WAN | ✅ | ✅ |
+| Fortinet| Specifications compatible[^1] | ✅ |
+| Furukawa Electric FITELnet | - | ✅ |
+| Juniper Networks SRX Series Firewalls | - | ✅ |
+| Palo Alto Networks Next-Generation Firewall | ✅ | ✅ |
+| pfSense| ✅ | ✅ |
+| Prisma SD-WAN (Palo Alto) | Specifications compatible[^1] | Specifications compatible[^1] |
+| Riverbed | Specifications compatible[^1] | Specifications compatible[^1] |
+| SonicWall| - | ✅ |
+| Sophos Firewall | ✅ | ✅ |
+| strongSwan | - | ✅ |
+| Velocloud | Compatibility on roadmap | Compatibility on roadmap |
+| Versa | Specifications compatible[^1] | Compatibility on roadmap |
+| VyOS| ✅ | ✅ |
+
+| VPN | GRE tunnel | IPsec tunnel |
+| --- | --- | --- |
+| Alibaba Cloud VPN Gateway | - | ✅ |
+| Amazon AWS Transit Gateway | - | ✅ |
+| Azure VPN Gateway | - | ✅ |
+| GCP Cloud VPN | - | ✅ |
+| Oracle Cloud | - | ✅ |
+
+[^1]: Specifications compatible per vendor documentation
diff --git a/src/content/partials/networking-services/magic-wan/third-party/alibaba-cloud.mdx b/src/content/partials/networking-services/magic-wan/third-party/alibaba-cloud.mdx
new file mode 100644
index 00000000000000..0b925630456b35
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/alibaba-cloud.mdx
@@ -0,0 +1,78 @@
+---
+params:
+ - productName
+ - ipSecTunnelsUrl
+ - addTunnelsUrl
+ - configureStaticRoutesUrl
+---
+
+This tutorial provides information on how to connect Alibaba Cloud infrastructure to {props.productName} through IPsec tunnels. For more information regarding Alibaba Cloud technology, refer to [Alibaba's documentation](https://www.alibabacloud.com/help/en/vpn-gateway).
+
+## Alibaba Cloud
+
+### 1. Create a VPC
+
+1. Log in to your Alibaba Cloud account.
+2. Go to **VPC** > **VPN Gateways**, and select **Create VPC** to create a new virtual private cloud.
+3. Give your VPC a descriptive name. For example, `Cloudflare-Magic-WAN`.
+4. Choose the **Region** that aligns with where your servers are located.
+5. In **IPv4 CIDR block**, choose from one of the recommended IP blocks. For example, `192.168.20.0/24`. Take note of the IP block you choose, as you will need it to create a static route in {props.productName}.
+
+### 2. Create a VPN gateway
+
+1. Still in your Alibaba Cloud account, go to **VPC** > **VPN Gateway**, and select **Create VPN Gateway**.
+2. Give your VPN Gateway a descriptive name. For example, `VPN-Gateway-Magic-WAN`.
+3. In **Region**, choose the server that is best for your geographic region. For example, **US (Silicon Valley)**.
+4. For **Gateway Type**, choose **Standard**.
+5. In **Network Type**, choose **Public**.
+6. For **Tunnels**, select **Single-tunnel**.
+7. In the **VPC** dropdown menu, choose the name of the VPC you created before for {props.productName}. For example, `Cloudflare-Magic-WAN`.
+8. In the **VSwitch** dropdown menu, choose the VSwith you created previously. For example, `VSwitch-CF`.
+9. For options such as **Maximum Bandwidth**, **Traffic**, and **Duration**, select the options that best suit your use case.
+10. In **IPsec-VPN**, select **Enable**.
+11. For **SSL-VPN**, select **Disable**.
+12. When you are finished configuring your VPN gateway, return to the main VPN Gateway window.
+13. Select the VPN gateway you have just created, and then select **Destination-based Routing**.
+14. Select **Add Route Entry**, and enter whatever subnets are needed to reach the required destinations. You can, for example, just add a default route to send all traffic through your {props.productName} tunnel.
+15. When you are finished, return to the main window.
+16. Select **Publish** > **OK** to publish the route.
+
+### 3. Create IPsec connections
+
+1. Go to **VPC** > **Customer Gateways** > **Create Customer Gateway**.
+2. Create a customer gateway with the Cloudflare anycast IP address given to you by your account team. Typically starts with `162.xx.xx.xx`.
+3. Now, go to **VPC** > **IPsec Connections** > **Create IPsec Connection**.
+4. Create an IPsec connection with the following settings:
+ 1. **Name**: give it a descriptive name, like `CF-Magic-WAN-IPsec`.
+ 2. **Associate Resource**: **VPN Gateway**.
+ 3. **VPN Gateway**: From the dropdown menu, choose the VPN gateway you created previously. In our example, `VPN-Gateway-Magic-WAN`.
+ 4. **Customer Gateway**: Select the customer gateway you created above for {props.productName}.
+ 5. **Routing Mode**: **Destination Routing Mode**.
+ 6. **Effective Immediately**: **Yes**.
+ 7. **Pre-Shared Key**: This is the pre-shared key (PSK) you will have to use in the {props.productName} IPsec tunnel. If you do not specify one here, the Alibaba system will generate a random PSK for you.
+5. Go to **Advanced Settings**, and expand the **Encryption Configuration** settings.
+6. In **IKE Configurations**, select the following settings to configure the IPsec connection. These settings have to match the supported configuration parameters for {props.productName} IPsec tunnels:
+ 1. **Version**: _ikev2_
+ 2. **Negotiation Mode**: _main_
+ 3. **Encryption Algorithm**: _aes256_
+ 4. **Authentication Algorithm**: _sha256_
+ 5. **DH Group**: _group20_
+ 6. **Localid**: This is the customer endpoint. These are generally IP addresses provided by your ISP. For example, `47.xxx.xxx.xxx`.
+
+## {props.productName}
+
+### 1. IPsec tunnels
+
+1. Follow the Add tunnels instructions to create the required IPsec tunnels with the following options:
+ 1. **Tunnel name**: Give your tunnel a descriptive name, like `Alibaba`.
+ 2. **Interface address**: Choose from the subnet in your Alibaba Cloud configuration. For example, if your Alibaba default configuration is `169.xx.xx.1/30`, you might want to choose `169.xx.xx.2/30` for your {props.productName} side of the IPsec tunnel.
+ 3. **Customer endpoint**: This is the IP address you entered for **Locali** in Alibaba's IPsec connection. For example, `47.xxx.xxx.xxx`.
+ 4. **Cloudflare endpoint**: Enter the same anycast IP address provided by Cloudflare you have entered for Alibaba's Customer Gateway. Typically starts with `162.xx.xx.xx`.
+ 5. **Pre-shared key**: Select **Use my own pre-shared key**, and enter the PSK key from your Alibaba Cloud IPsec tunnel.
+ 6. **Replay protection**: **Enabled**.
+2. Select **Add tunnels** when you are done.
+
+### 2. Static route
+
+1. Follow the Configure static routes instructions to create a static route.
+2. In **Prefix**, enter the IP CIDR you used to create your virtual private cloud in the Alibaba Cloud interface. In our example we used `192.168.20.0/24`.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/aruba-edgeconnect.mdx b/src/content/partials/networking-services/magic-wan/third-party/aruba-edgeconnect.mdx
new file mode 100644
index 00000000000000..922aeda4936a17
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/aruba-edgeconnect.mdx
@@ -0,0 +1,362 @@
+---
+params:
+ - productName
+ - tunnelHealthCheckUrl
+ - magicFirewallUrl
+ - gatewayUrl
+---
+
+import { Details } from "~/components"
+
+Cloudflare partners with Aruba's EdgeConnect SD-WAN solution to provide users with an integrated solution. The EdgeConnect appliances manage subnets associated with branch offices or retail locations. Anycast tunnels are set up between the EdgeConnect appliances and Cloudflare to securely route traffic.
+
+This tutorial describes how to configure the EdgeConnect device for both east-west (branch to branch) and north-south (Internet-bound) use cases.
+
+:::caution
+Note that north-south traffic routed through Cloudflare's Secure Web Gateway is an optional add-on feature set and requires a Cloudflare Zero Trust account.
+:::
+
+### Prerequisites
+
+Before setting up a connection between EdgeConnect and Cloudflare, you must have:
+
+- A contract that includes {props.productName} and Secure Web Gateway.
+- Received two Cloudflare endpoints (anycast IP address).
+- Determined a private static /31 IP pair to use with each tunnel. The /31 pairs should be from a different private subnet, separate from the private subnets used behind each EdgeConnect appliance.
+- The EdgeConnect devices used in this tutorial and on v9.0.
+
+## Example scenario
+
+
+
+For the purpose of this tutorial, the integration will refer to a scenario with two branch offices, each with distinct subnets.
+
+There are 2 branch offices each with distinct subnets.
+
+- The east branch office has a `10.3.0.0/16` network with an EdgeConnect terminating the anycast GRE tunnel.
+- The west branch office has a `10.30.0.0/16` network with an EdgeConnect terminating the anycast GRE tunnel.
+
+
+
+Below is an example of the **east_branch** deployment on the Orchestrator.
+
+
+
+The Deployment screenshot displays several different IP addresses and interfaces. From left to right:
+
+- **Next Hop 10.3.0.1** - This example uses Google Cloud. This IP defines the default gateway IP for the subnet and is built into GCP.
+- **IP/Mask (LAN) 10.3.0.2/24** - This defines the LAN0 interface IP of the EdgeConnect appliance.
+- **IP/Mask (WAN) 10.2.0.2/24** - This defines the WAN0 interface IP of the EdgeConnect appliance.
+- **Next Hop 10.2.0.1** - This example uses Google Cloud. This IP defines the default gateway IP for the subnet and is built into GCP.
+
+
+
+
+
+For the purpose of this tutorial, the integration will refer to a scenario with two branch offices, each with distinct subnets.
+
+The central branch office has a `10.22.0.0/24` network with an EdgeConnect terminating the anycast IPsec tunnel.
+
+The west branch office has a `10.77.0.0/24` network with an EdgeConnect terminating the anycast IPsec tunnel.
+
+
+
+Below is an example of the **central_branch** deployment on the Orchestrator.
+
+
+
+The Deployment screenshot displays several different IP addresses and interfaces. From left to right:
+
+- **Next Hop 10.22.0.1** - This example uses Google Cloud. This IP defines the default gateway IP for the subnet and is built into GCP.
+- **IP/Mask (LAN) 10.22.0.2/24** - This defines the LAN0 interface IP of the EdgeConnect appliance.
+- **IP/Mask (WAN) 10.32.0.2/24** - This defines the WAN0 interface IP of the EdgeConnect appliance.
+- **Next Hop 10.32.0.1** - This example uses Google Cloud. This IP defines the default gateway IP for the subnet and is built into GCP.
+
+
+
+## 1. Define a common site on the Orchestrator
+
+For all EdgeConnect devices using Cloudflare, modify the devices to put them on the same site. This disables automatic IPsec tunnel creation between the EdgeConnect devices using the same labels for the WAN interfaces in use.
+
+This step is only required if Cloudflare is used for east-west traffic routing.
+
+## 2. Configure overlay policies
+
+We use Aruba Orchestrator's Business Intent Overlays to create intuitive policies which automatically identify and steer application traffic to Cloudflare. Two Business Intent Overlay (BIO) policies are created in this example.
+
+
+
+Cloudflare's tunnel health checks] are ping reply packets encapsulated in GRE packets. The source IP is the Edgeconnect WAN interface used to establish a tunnel, and the destination IP is Cloudflare servers. These packets need to be sent directly from the WAN interface and not through the established tunnels.
+
+To create the overlay policy:
+
+1. Create a compound application, which is a combination of all [Cloudflare public IPs](https://www.cloudflare.com/ips/) and ICMP packets.
+
+
+
+2. Create a breakout Business Intent Overlay (BIO) to bypass the GRE tunnel as the first policy and use this newly created application as the match criteria.
+
+3. Define at least one additional overlay policy and the traffic you want to send to Cloudflare over the GRE tunnels.
+
+The service name used to send traffic through the tunnel created in the next step is **Cloudflare_GRE**. The example uses **Match Everything** to send all other traffic through the established tunnel (both private east-west traffic & Internet bound north-south traffic through Cloudflare's Secure Web Gateway).
+
+
+
+
+
+
+Cloudflare's tunnel health checks] are ping reply packets encapsulated in IPsec packets. The source IP is the Edgeconnect WAN interface used to establish a tunnel, and the destination IP is Cloudflare servers. These packets need to be sent directly from the WAN interface and not through the established tunnels.
+
+To create the overlay policy:
+
+1. Create a compound application, which is a combination of all [Cloudflare public IPs](https://www.cloudflare.com/ips/) and ICMP packets.
+
+
+
+2. Create a breakout Business Intent Overlay (BIO) to bypass the IPsec tunnel as the first policy and use this newly created application as the match criteria.
+
+3. Define at least one additional overlay policy and the traffic you want to send to Cloudflare over the IPsec tunnels.
+
+The service name used to send traffic through the tunnel created in the next step is **Cloudflare_IPsec**. The example uses **Match Everything** to send all other traffic through the established tunnel (both private east-west traffic and Internet bound north-south traffic through Cloudflare's Secure Web Gateway).
+
+
+
+
+## 3. Create tunnels on Cloudflare and EdgeConnect
+
+
+
+
+
+1. Create a tunnel on the EdgeConnect using Cloudflare's assigned public anycast IP and the service used in the overlay policy in the [previous step](#2-configure-overlay-policies).
+2. Create a Virtual Tunnel Interface (VTI) using the private IP pair shared with CF GRE tunnel endpoint and the passthrough tunnel to match the newly created tunnel alias (**CF_GRE_east** in our example).
+
+
+
+
+
+3. Define a GRE tunnel on the Cloudflare dashboard using the EdgeConnect appliance's public IP and the private IP pair /31 shared with the appliance.
+
+
+
+
+
+
+
+
+
+For additional information on creating IPsec tunnels, refer to [API documentation for IPsec tunnels](/api/resources/magic_transit/subresources/ipsec_tunnels/methods/create/).
+
+- `X-Auth-Email`: Your Cloudflare email ID
+- `X-Auth-Key`: Seen in the URL (`dash.cloudflare.com//....`)
+- `Account key`: Global API token in Cloudflare dashboard
+
+1. Test new IPsec tunnel creation
+
+```bash
+curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels?validate_only=true" \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "ipsec_tunnels": [
+ {
+ "name": "EdgeConnect_IPSEC_1",
+ "customer_endpoint": "35.188.72.56",
+ "cloudflare_endpoint": "172.64.241.205",
+ "interface_address": "192.168.10.11/31",
+ "description": "Tunnel for EdgeConnect - GCP Central"
+ }
+ ]
+}'
+```
+
+2. Create a new IPsec tunnel
+
+```bash
+curl https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "ipsec_tunnels": [
+ {
+ "name": "EdgeConnect_IPSEC_1",
+ "customer_endpoint": "35.188.72.56",
+ "cloudflare_endpoint": "172.64.241.205",
+ "interface_address": "192.168.10.11/31",
+ "description": "Tunnel for EdgeConnect - GCP Central"
+ }
+ ]
+}'
+```
+
+```json output
+{
+ "result": {
+ "ipsec_tunnels": [
+ {
+ "id": "tunnel_id",
+ "interface_address": "192.168.10.11/31",
+ "created_on": "2022-04-14T19:57:43.938376Z",
+ "modified_on": "2022-04-14T19:57:43.938376Z",
+ "name": "EdgeConnect_IPSEC_1",
+ "cloudflare_endpoint": "172.64.241.205",
+ "customer_endpoint": "35.188.72.56",
+ "description": "Tunnel for EdgeConnect - GCP Central",
+ "health_check": {
+ "enabled": true,
+ "target": "35.188.72.56",
+ "type": "reply"
+ }
+ }
+ ]
+ },
+ "success": true,
+ "errors": [],
+ "messages": []
+}
+```
+
+3. Generate Pre Shared Key (PSK) for tunnel
+
+Use the tunnel ID from the response in Step 2. Save the pre-shared key generated in this step as you will need it to set up tunnels on the Orchestrator.
+
+```bash
+curl --request POST \
+"https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels/{tunnel_id}/psk_generate?validate_only=true" \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: "
+```
+
+```json output
+{
+ "result": {
+ "ipsec_id": "",
+ "ipsec_tunnel_id": "",
+ "psk": "XXXXXXXXXXXXXXXXX",
+ "psk_metadata": {
+ "last_generated_on": "2022-04-14T20:05:29.756514071Z"
+ }
+ },
+ "success": true,
+ "errors": [],
+ "messages": []
+}
+```
+
+**Create an IPsec tunnel on EdgeConnect**
+
+You can create a tunnel after the Business Intent Overlay policies have been defined. Use the correct policy or service created in [configure overlay policy](#2-configure-overlay-policies). The local IP is the local WAN interface of the EdgeConnect device, and the remote IP is the Cloudflare public IP assigned as the tunnel endpoint.
+
+
+
+
+
+
+
+**Create a Virtual Tunnel Interface (VTI) on the EdgeConnect appliance**
+
+
+
+
+
+## 4. Create static routes on Cloudflare and EdgeConnect
+
+
+
+1. Define static routes on the Cloudflare dashboard for the LAN subnet(s) attached to the EdgeConnect appliance. Use the private IP pair for the EdgeConnect tunnel endpoint.
+
+ In the example below, the traffic to subnet `10.3.0.0/16` attached to the **east_branch** EdgeConnect appliance has a next hop of `10.40.8.10`.
+
+
+
+2. Define static routes on the Orchestrator so Cloudflare can route traffic between sites.
+
+ In the example below, we create a route for the subnet `10.30.0.0/24` on the **west_branch** to be routed via the established GRE tunnel between the EdgeConnect appliance and Cloudflare.
+
+
+
+
+
+
+
+
+
+**Static routes for central branch on EdgeConnect**
+
+
+
+**Static routes for west branch on EdgeConnect**
+
+
+
+
+
+## 5. Validate traffic flow
+
+
+
+**Validate Secure Web Gateway**
+
+To validate traffic flow from the local subnet through Cloudflare's Secure Web Gateway, perform a curl as show in the example below.
+
+
+
+You can validate the request went through Gateway with the presence of the `Cf-Team` response header, or by looking at the logs in the dashboard under **Logs** > **Gateway** > **HTTP**.
+
+
+
+**Validate east-west traffic**
+
+To validate east-west traffic flow, perform a traceroute as shown in the example.
+
+
+
+The example shows a client in GCP East (`10.3.0.3`), which can ping the private IP of a client in GCP West (`10.30.0.4`).
+
+The traceroute shows the path going from the client (`10.3.0.3`) to:
+- the GCP East lan0 IP on the EdgeConnect (`10.3.0.2`)
+- the Cloudflare private GRE endpoint IP (`10.4.8.11`)
+- the GCP West lan0 IP on the West EdgeConnect (`10.30.0.3`)
+- the GCP West client (`10.30.0.4`)
+
+This validates the east-west traffic flow through Cloudflare {props.productName}.
+
+
+
+
+
+**Validate Secure Web Gateway**
+
+To validate traffic flow from the local subnet through Cloudflare's Secure Web Gateway, perform a cURL as shown in the example below.
+
+
+
+You can validate the request was sent through Secure Web Gateway with the presence of the `Cf-Team` response header or by looking at the logs in the dashboard under **Logs** > **Gateway** > **HTTP**.
+
+
+
+**Validate east-west traffic**
+
+To validate east-west traffic flow, perform a traceroute as shown in the example.
+
+
+
+The example shows a client in GCP Central (`10.22.0.9`), which can ping the private IP of a client in GCP West (`10.77.0.10`).
+
+The traceroute shows the path going from the client (`10.22.0.9`) to:
+- the GCP Central lan0 IP on the EdgeConnect (`10.22.0.2`)
+- the Cloudflare private IPsec endpoint IP (`192.168.10.11`)
+- the GCP West EdgeConnect private IPsec endpoint IP (`192.168.15.10`)
+- the GCP West client (`10.77.0.10`)
+
+This validates the east-west traffic flow through Cloudflare {props.productName}.
+
+
+
+## 6. Cloudflare policies
+
+At this point, the GRE or IPsec tunnels should be connected from the EdgeConnect appliances to Cloudflare's global network, and traffic is scoped to route over the tunnels using the EdgeConnect Business Intent Overlays.
+
+To begin filtering traffic and gathering analytics, refer to the Magic Firewall documentation to learn how to create filters for east-west inter-branch traffic and the Secure Web Gateway documentation to learn how to configure Gateway policies if you decide to send traffic from your local private subnets to the Internet through Cloudflare Gateway.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/aws.mdx b/src/content/partials/networking-services/magic-wan/third-party/aws.mdx
new file mode 100644
index 00000000000000..3f51f26e57511b
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/aws.mdx
@@ -0,0 +1,95 @@
+---
+params:
+ - productName
+ - addTunnelsUrl
+ - createAStaticRouteUrl
+---
+
+This tutorial provides information and examples of how to configure IPsec VPN between Cloudflare {props.productName} with an AWS Transit Gateway.
+
+## Prerequisites
+
+You need to have an AWS transit gateway created in your AWS account. This is needed to route traffic between your AWS virtual private cloud (VPC) and Cloudflare {props.productName}. Refer to the [AWS documentation](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html) to learn more about creating a transit gateway.
+
+Additionally, you also need to configure the necessary route table entries for the virtual machine (VM) in your AWS virtual private cloud, as well the route table entries for the transit gateway. Otherwise, connectivity between your VM and another VM routed via {props.productName} will not work. Refer to the [AWS documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) to learn more about routing tables.
+
+## AWS
+
+### Create AWS transit gateway VPN attachment
+
+1. Go to **Transit gateways** > **Transit gateway attachments**, and select **Create transit gateway attachment**.
+2. Select the **Transit gateway ID** that you created previously from the dropdown.
+3. For **Attachment type**, select _VPN_.
+4. Under VPN attachment, select the following settings (you can leave settings not mentioned here with their default values):
+ 1. **Customer Gateway**: Select **New**.
+ 2. **IP Address**: Enter your Cloudflare anycast IP address.
+ 3. **Routing options**: Select **Static**.
+5. Select **Create transit gateway attachment**.
+
+### Configure the VPN connection
+
+1. Select the VPN connection you created > **Download configuration**.
+
+2. This action downloads a text file. Search for the IP range that the AWS Transit Gateway assigned your tunnel. The first IP range should be the one used by the AWS Transit Gateway. Use the second IP range to configure your [Interface address](#ipsec-tunnels) in {props.productName}.
+
+3. Select the VPN connection you created > **Actions** > **Modify VPN tunnel options**.
+
+4. From the **VPN tunnel outside IP address** drop-down menu, choose one of tunnels.
+
+5. Take note of the **IP address** you chose, as this corresponds to the customer endpoint IP that you will need to configure on the Cloudflare side of the IPsec tunnel.
+
+6. The number of options for the VPN connection will expand. Take note of the **Pre-shared key**. You will need it to create the IPsec tunnel on Cloudflare's side.
+
+7. In **Inside IPv4 CIDR**, AWS enforces that only a `/30` block within the `169.254.0.0/16` range can be used. To accommodate this, Cloudflare supports a subset of this IP block. Namely, Cloudflare supports `169.254.240.0/20` to be assigned as the IPsec tunnel's (internal) interface IPs. This example will use `169.254.244.0/30` as the CIDR block for the IPsec tunnel: `169.254.244.1` for the AWS side of the tunnel, and `169.254.244.2` for the Cloudflare side of the tunnel.
+
+ :::caution
+ Make sure you input an IP address supported by Cloudflare. If you do not input a value here, AWS will randomly generate an IP address that might not be supported by Cloudflare.
+ :::
+
+8. Configure the following settings for the IPsec tunnel. Note that the **Startup action** needs to be set to **Start**, which means the AWS side will initiate IPsec negotiation. Settings not mentioned here can be left at their default settings:
+ - **Phase 1 encryption algorithms**: `AES256-GCM-16`
+ - **Phase 2 encryption algorithms**: `AES256-GCM-16`
+ - **Phase 1 integrity algorithms**: `SHA2-256`
+ - **Phase 2 integrity algorithms**: `SHA2-256`
+ - **Phase 1 DH group numbers**: `20`
+ - **Phase 2 DH group numbers**: `20`
+ - **IKE Version**: `ikev2`
+ - **Startup action**: **Start**
+ - **DPD timeout action**: `Restart`
+
+9. Select **Save changes**.
+
+10. Repeat the steps above to configure the second VPN connection. Use the second outside IP address, and make the appropriate changes to IP addresses as well when configuring Cloudflare's side of the tunnel.
+
+:::note
+ECMP over two VPN tunnels is not supported with a static routing configuration. You will need to configure dynamic routing for the VPN between the transit gateway and the customer gateway device. Refer to [AWS documentation](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html) for more information.
+:::
+
+## {props.productName}
+
+After configuring the AWS transit gateway VPN connection and the tunnel as mentioned above, go to the Cloudflare dashboard and create the corresponding IPsec tunnel and static routes on the {props.productName} side.
+
+### IPsec tunnels
+
+1. Refer to Add tunnels to learn how to add an IPsec tunnel. When creating your IPsec tunnel, make sure you define the following settings:
+ - **Tunnel name**: `tunnel01`
+ - **Interface address**: The `/30`CIDR block enforced by AWS (first usable IP is for the AWS side). For example, `169.254.244.2`.
+ - **Customer endpoint**: The IP address from AWS's VPN tunnel outside IP address. For example, `35.xx.xx.xx`.
+ - **Cloudflare endpoint**: Enter the first of your two anycast IPs.
+ - **Pre-shared key**: Choose **Use my own pre-shared key**, and enter the PSK you created for the AWS VPN tunnel.
+ - **Health check type**: Choose **Request**
+ - **Health check direction**: Choose **Bidirectional**
+ - **Replay protection**: Select **Enabled**.
+2. Select **Save**.
+3. Repeat the above steps for `tunnel02`. Chose the same prefix, but select the second IPsec tunnel for **Tunnel/Next hop**.
+
+### Static routes
+
+The static route in {props.productName} should point to the appropriate virtual machine (VM) subnet you created inside your AWS virtual private cloud. For example, if your VM has a subnet of `192.168.192.0/26`, you should use it as the prefix for your static route.
+
+To create a static route:
+
+1. Refer to Create a static route to learn how to create one.
+2. In **Prefix**, enter the subnet for your VM. For example, `192.xx.xx.xx/24`.
+3. For the **Tunnel/Next hop**, choose the IPsec tunnel you created in the previous step.
+4. Repeat the steps above for the second IPsec tunnel you created.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/azure-virtual-wan.mdx b/src/content/partials/networking-services/magic-wan/third-party/azure-virtual-wan.mdx
new file mode 100644
index 00000000000000..d98646babc7ed2
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/azure-virtual-wan.mdx
@@ -0,0 +1,148 @@
+---
+params:
+ - productName
+ - tunnelHealthChecksUrl
+ - ipsecTunnelUrl
+ - tunnelEndpointsUrl
+ - cloudflareDocumentationUrl
+---
+
+This tutorial provides information on how to connect {props.productName} to a Microsoft Azure Virtual WAN hub.
+
+## Prerequisites
+
+You will need to have an existing Resource group, Virtual Network, and Virtual Machine created in your Azure account. Refer to [Microsoft's documentation](https://learn.microsoft.com/en-us/azure/virtual-network/) to learn more on how to create these.
+
+## Start Azure configuration
+
+### 1. Create a Virtual WAN
+
+To connect one or more VNets to {props.productName} via a Virtual WAN hub, you first need to create a Virtual WAN (vWAN) resource representing your Azure network. If you already have a vWAN that you wish to connect to {props.productName}, continue to the next step. Refer to [Microsoft's documentation](https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-site-to-site-portal#openvwan) to learn more.
+
+1. In the Azure portal, go to your **Virtual WANs** page.
+2. Select the option to create a **Virtual WAN**.
+3. Create a Virtual WAN with the **Type** set to **Standard**.
+
+### 2. Create a Virtual WAN Hub
+
+Using traditional hub and spoke terminology, a Virtual WAN Hub deployed within a vWAN is the hub to which your VNet(s) and {props.productName} attach as spokes. The vWAN hub deployed in this step will contain a VPN Gateway for connecting to {props.productName}.
+
+1. Create a **Virtual WAN Hub**.
+2. In **Basics**:
+ 1. Select your resource group as well as your desired region, capacity, and hub routing preference. Microsoft recommends using the default hub routing preference of **ExpressRoute** unless you have a specific need to change this setting. Refer to [Microsoft's documentation](https://learn.microsoft.com/en-us/azure/virtual-wan/about-virtual-hub-routing-preference) to learn more about Azure hub routing preferences.
+ 2. Configure the **Hub Private Address Space**. Choose an [address space with a subnet mask of `/24` or greater](https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-site-to-site-portal#hub) that does not overlap with the address spaces of any VNets you wish to attach to the vWAN Hub, nor with any of your {props.productName} sites.
+3. In **Site to Site**:
+ 1. In **Do you want to create a Site to site (VPN gateway)?** select **Yes**.
+ 2. Select your desired **Gateway scale units** and **Routing Preference**. Refer to [Microsoft's documentation](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/routing-preference-overview#routing-via-microsoft-global-network) to learn more about Azure routing preferences.
+4. Select **Create**. Note that the deployment time for the vWAN Hub and VPN Gateway may take 30 minutes or more.
+5. After the VPN Gateway has finished provisioning, go to **Virtual WAN** > **Hubs** > **Your vHub** > **Connectivity** > **VPN (Site to site)**.
+6. In the **Essentials** dropdown select the VPN Gateway listed.
+7. Select the JSON View for the VPN Gateway and take note of the JSON attributes at the paths `properties.ipConfigurations[0].publicIpAddress` and `properties.ipConfigurations[1].publicIpAddress`. These will be the customer endpoints needed when configuring IPsec tunnels for {props.productName}.
+
+### 3. Create a VPN site
+
+A VPN site represents the remote site your Azure vWAN can reach through a VPN connection. This is typically an on-premises location. In this case, the VPN site represents {props.productName}.
+
+1. Go to **Virtual WAN** > **VPN sites** > **Create site**.
+2. In **Basics**:
+ 1. Configure your desired region and name.
+ 2. Configure the **Device vendor** as Cloudflare.
+ 3. In **Private address space**, specify the address range(s) you wish to access from your vWAN through {props.productName}. This could include other private networks connected to your {props.productName}, or a default route (`0.0.0.0/0`) if you want Internet egress traffic to traverse {props.productName} (that is, to be scanned by Cloudflare Gateway). The address space can be modified after VPN site creation.
+3. In **Links**:
+ 1. Configure a single link. Provide a name, speed (in Mbps), and provider name (here, enter `Cloudflare`) for your link. For the **Link IP address**, enter your Cloudflare anycast address. The **BGP address** and **ASN** fields should be left empty. BGP is not supported at the time of writing this tutorial.
+4. Select **Create**.
+
+### 4. Configure VPN site for Magic IPsec tunnel health checks
+
+{props.productName} uses Tunnel Health Checks to monitor whether a tunnel is available.
+
+Tunnel health checks make use of ICMP probes sent from the Cloudflare side of the Magic IPsec tunnel to the remote endpoint (Azure). Probes are sent from the tunnel's interface address, which you specify in two places:
+
+- **Cloudflare Dashboard:** In your Magic IPsec tunnel configuration as the address of the virtual tunnel interface (VTI) (so that Cloudflare knows what address to send probes from). Cloudflare requires this address in CIDR notation with a `/31` netmask.
+- **Azure Portal:** In your VPN site's address space (so that Azure routes probe responses back over the tunnel). Azure requires this address in CIDR notation with a `/32` netmask.
+
+Cloudflare recommends that you select a unique `/31` subnet ([RFC 1918 — Address Allocation for Private Internets](https://datatracker.ietf.org/doc/html/rfc1918)) for each IPsec tunnel which is treated as a Point-to-Point Link and provides the ideal addressing scheme to satisfy both requirements.
+
+Example:
+
+- Select `169.254.251.137/31` as your unique Point-to-Point Link subnet.
+- In the Cloudflare dashboard, set `169.254.251.137/31` as your tunnel's **IPv4 Interface address**. (Refer to [Configure {props.productName}](#configure-magic-wan) below.)
+- In the Azure portal, add `169.254.251.137/32` to your VPN site's **Private address space**.
+
+:::note
+It is important to ensure the subnet selected for the Interface Address does not overlap with any other subnet.
+
+You should also refer to RFC 3021 for more information on using 31-bit prefixes on [IPv4 Point-to-Point Links](https://datatracker.ietf.org/doc/html/rfc3021).
+:::
+
+To configure the Address Space for the Local Network Gateway to support Tunnel Health Checks:
+
+1. Go to **Virtual WAN** > **VPN sites** > **Your VPN Site** > **Edit site** to edit the VPN site configured in the previous section.
+2. Update the **Private address space** to include two `/32` subnets in CIDR notation as described above. When using Azure VPN Gateways with vWAN Hubs, a single VPN Gateway Connection maps to two {props.productName} IPsec Tunnels. For this reason, we need to select two unique `/31` subnets, one for each Cloudflare IPsec Tunnel. The upper address of each `/31` is then added to the VPN Site's Private address space as a `/32`subnet.
+3. Select **Confirm**.
+
+### 5. Create a Virtual Network Connection
+
+To connect your existing VNet to your newly created vHub:
+
+1. Go to **Virtual WAN** > **Virtual network connections** and select **Add connection**.
+2. Configure the connection to connect the desired VNet to the vHub created above.
+3. Ensure that within the connection's **Routing configuration**:
+ 1. **Propagate to none** is set to **No.**
+ 2. **Bypass Next Hop IP for workloads within this VNet** is set to **No**
+ 3. And **Propagate static route** is set to **Yes**.
+4. Select **Create**.
+
+## Configure {props.productName}
+
+When connecting your Azure vHub VPN Gateway to {props.productName}, you need to create two {props.productName} IPsec tunnels to map to the single Azure VPN Gateway Connection created above. This is because Azure VPN Gateways are deployed with two public IP addresses.
+
+1. Create an IPsec tunnel in the Cloudflare dashboard.
+2. Make sure you have the following settings:
+ 1. **Interface address**: Add the upper IP address within the first `/31` subnet selected in step 4 of the Start Azure Configuration section. Refer to Tunnel endpoints for more details.
+ 2. **Customer endpoint**: The first public IP associated with your Azure VPN Gateway. For example, `40.xxx.xxx.xxx`.
+ 3. **Cloudflare endpoint**: Use the Cloudflare anycast address you have received from your account team. This will also be the IP address corresponding to the VPN Site in Azure. For example, `162.xxx.xxx.xxx`.
+ 4. **Health check rate**: Medium (default).
+ 5. **Health check type**: Reply (default).
+ 6. **Health check direction**: Bidirectional (default).
+ 7. **Health check target**: Custom; enter the customer endpoint.
+ 8. **Add pre-shared key later**: Select this option to create a PSK that will be used later in Azure.
+ 9. **Replay protection**: **Enable**.
+3. Edit the tunnel. Generate a new pre-shared key and copy the key to a safe location.
+4. Create static routes for your Azure Virtual Network subnets, specifying the newly created tunnel as the next hop.
+5. Create the second IPsec tunnel in the Cloudflare dashboard. Copy the configuration of the first tunnel with the following exceptions:
+ 1. **Interface address**: Add the upper IP address within the **second** `/31` subnet selected in step 4 of the Start Azure Configuration section.
+ 2. **Customer endpoint**: The **second** Public IP associated with your Azure VPN Gateway.
+ 3. **Health check target**: Enter the new customer endpoint as a custom target.
+ 4. **Use my own pre-shared key**: Select this option and enter the key generated for the first tunnel.
+6. Create static routes for your Azure Virtual Network subnets, specifying the newly created tunnel as the next hop. To use one tunnel as primary and the other as backup, give the primary tunnel's route a lower priority. To ECMP load balance across both tunnels, assign both routes the same priority.
+
+## Finish Azure Configuration
+
+### 1. Create an IPsec VPN Gateway Connection
+
+To create a **VPN Gateway Connection**:
+
+1. Go to **Virtual WAN** > **Hubs** > **Your vHub** > **Connectivity** > **VPN (Site to site)** and remove the default filter **Hub association: Connected** to display the **VPN Site** created above.
+2. Check the box next to your VPN Site and select **Connect VPN sites**.
+
+Choose the following settings. These settings have been tested by Cloudflare. However, when setting up your VPN connection note that there are other configuration parameters are also technically feasible, as documented in the [Azure documentation](https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-ipsec) and in the Cloudflare documentation.
+
+1. **PSK**: Provide the PSK generated by Cloudflare for your {props.productName} Tunnels.
+2. **Protocol**: *IKEv2*
+3. **IPsec**: *Custom*
+ 1. **IPsec SA lifetime in seconds**: 28800
+ 2. **IKE Phase 1**
+ 1. **Encryption**: *AES256*
+ 2. **Integrity/PRF**: *SHA256*
+ 3. **DH Group**: *ECP384*
+ 3. **IKE Phase 2(IPsec)**
+ 1. **IPsec Encryption**: *AES256*
+ 2. **IPsec Integrity**: *SHA256*
+ 3. **PFS Group**: *ECP384*
+ 4. **Propagate Default Route:** **Disable**
+ 5. **Use policy based traffic selector**: **Disable**
+ 6. **Connection mode**: **Initiator Only**
+ 7. **Configure traffic selector?**: **Disabled**
+
+4. Select **Connect**.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/azure-vpn-gateway.mdx b/src/content/partials/networking-services/magic-wan/third-party/azure-vpn-gateway.mdx
new file mode 100644
index 00000000000000..d9449d8c303ec7
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/azure-vpn-gateway.mdx
@@ -0,0 +1,385 @@
+---
+params:
+ - productName
+ - ipsecTunnelUrl
+ - tunnelEndpointsUrl
+ - staticRoutesUrl
+ - tunnelHealthChecksUrl
+---
+
+This tutorial provides information on how to connect Cloudflare {props.productName} to your Azure Virtual Network, using the Azure Virtual Network Gateway.
+
+## Prerequisites
+
+You will need to have an existing Resource group, Virtual Network, and Virtual Machine created in your Azure account. Refer to [Microsoft's documentation](https://learn.microsoft.com/en-us/azure/virtual-network/) to learn more on how to create these.
+
+## Configure Azure Virtual Network Gateway
+
+### 1. Create a Gateway subnet
+
+You should already have a Virtual Network (VNET) created with a subnet assigned to it. The next step is to create a gateway subnet that Azure will use for addressing services related to Azure's Virtual Network Gateway. If you already have a gateway subnet, Azure will prevent you from creating a second one. If that is your case, update your gateway subnet settings.
+
+1. Go to your **Virtual Network** > **Subnets**.
+2. Select the option to add a **Gateway subnet**.
+3. Configure the subnet address range. The gateway subnet must be contained by the address space of the virtual network, and have a subnet mask of `/27` or greater.
+4. Make sure all other settings are set to **None**.
+
+### 2. Create a Virtual Network Gateway
+
+The Virtual Network Gateway is used to form the tunnel to the devices on your premises.
+
+:::note
+This configuration guide applies to Azure Virtual Network Gateway which includes the functionality found in the Azure VPN Gateway.
+
+
+Active/Active and Active/Standby configurations are both supported. Two Azure public IP addresses and two {props.productName} IPsec tunnels are required for the Active/Active configuration.
+:::
+
+#### Active/Active configuration
+
+1. Create a Virtual Network Gateway.
+2. Create two new public IP addresses or use existing IPs. Take note of the public IP addresses assigned to the Virtual Network Gateway as these will be the **Customer endpoint** for {props.productName}'s IPsec tunnels configuration.
+3. Navigate to the Virtual Network Gateway created earlier.
+4. In **Configuration**, enable **Active-active mode** and disable **Gateway Private IPs**.
+5. Select **Create**.
+
+#### Active/Standby configuration
+
+1. Create a Virtual Network Gateway.
+2. Create a new public IP address or use an existing IP. Take note of the public IP address assigned to the Virtual Network Gateway as this will be the **Customer endpoint** for {props.productName}'s IPsec tunnels configuration.
+3. Select the resource group and VNET you have already created.
+4. In **Configuration**, disable **Active-active mode** and **Gateway Private IPs**.
+5. Select **Create**.
+
+:::note
+The time it takes for Azure to fully provision the Virtual Network Gateway depends on the deployment region.
+:::
+
+## Configure {props.productName}
+
+1. Create an IPsec tunnel in the Cloudflare dashboard.
+2. Make sure you have the following settings:
+ 1. **Interface address**: As the Azure Local Network Gateway will only permit specifying the lower IP address in a `/31` subnet, add the upper IP address within the `/31` subnet selected in [step 2 of the Configure Azure section](#2-configure-local-network-gateway-for-magic-ipsec-tunnel-health-checks). Refer to Tunnel endpoints for more details.
+ 2. **Customer endpoint**: The Public IP associated with your Azure Virtual Network Gateway. For example, `40.xxx.xxx.xxx`.
+ 3. **Cloudflare endpoint**: Use the Cloudflare anycast address you have received from your account team. This will also be the IP address corresponding to the Local Network Gateway in Azure. For example, `162.xxx.xxx.xxx`.
+ 4. **Health check rate**: Leave the default option (Medium) selected.
+ 5. **Health check type**: Leave the default option (Reply) selected.
+ 6. **Health check direction**: Leave default option (Bidirectional) selected.
+ 7. **Health check target**: Select **Custom**.
+ 8. **Target address**: Enter the same address that is used in the **Customer endpoint** field.
+ 9. **Add pre-shared key later**: Select this option to create a PSK that will be used later in Azure.
+ 10. **Replay protection**: **Enable**.
+3. If you are using the Active/Active configuration, select **Add IPsec tunnel** and repeat step 2 to create the second {props.productName} IPsec tunnel. Use the same **Cloudflare endpoint** as for the first tunnel.
+4. Select **Add Tunnels** when you are finished.
+5.The Cloudflare dashboard will show you a list of your tunnels. Edit the tunnel(s) you have created > select **Generate a new pre-shared key** > copy the generated key. If using the Active/Active configuration, select **Change to a new custom pre-shared key** on the second tunnel and use the PSK generated for the first tunnel.
+6. Create static routes for your Azure Virtual Network subnets, specifying the newly created tunnel as the next hop.
+
+:::note
+Both tunnels in an Active/Active configuration must use the same **Cloudflare endpoint**, because an Active/Active Azure VPN connection creates two tunnels to the same remote address.
+:::
+
+## Complete the Azure Configuration
+
+### 1. Create a Local Network Gateway
+
+The Local Network Gateway typically refers to your on-premises location. In this case, the Local Network Gateway represents the Cloudflare side of the connection.
+
+We recommend creating a Local Network Gateway for your Cloudflare IPsec tunnel.
+
+1. Create a new local network gateway.
+2. In **Instance details** > **Endpoint**, select **IP address** and enter the Cloudflare anycast address in the IP address field.
+3. In **Address space(s)**, specify the address range of any subnets you wish to access remotely through the {props.productName} connection. For example, if you want to reach a network with an IP range of `192.168.1.0/24`, and this network is connected to your {props.productName} tenant, you would add `192.168.1.0/24` to the local network gateway address space.
+4. Go to the **Advanced** tab > **BGP settings**, and make sure you select **No**.
+
+:::note
+A single Cloudflare anycast address must be used in both Active/Active and Active/Standby configurations.
+:::
+
+### 2. Configure Local Network Gateway for Magic IPsec tunnel health checks
+
+{props.productName} uses Tunnel Health Checks to monitor whether a tunnel is available.
+
+Tunnel health checks make use of ICMP probes sent from the Cloudflare side of the Magic IPsec tunnel to the remote endpoint (Azure). Probes are sent from the tunnel's interface address, which you specify in two places:
+
+1. **Cloudflare Dashboard:** In your Magic IPsec tunnel configuration as the address of the virtual tunnel interface (VTI) (so that Cloudflare knows what address to send probes from). Cloudflare requires this address in CIDR notation with a `/31` netmask.
+2. **Azure Portal:** In your VPN site's address space (so that Azure routes probe responses back over the tunnel). Azure requires this address in CIDR notation with a `/32` netmask.
+
+Cloudflare recommends customers select a unique `/31` subnet ([RFC 1918 - Address Allocation for Private Internets](https://datatracker.ietf.org/doc/html/rfc1918)) for each IPsec tunnel which is treated as a Point-to-Point Link and provides the ideal addressing scheme to satisfy both requirements.
+
+Example:
+- Select 10.252.3.55/31 as your unique point-to-point link subnet.
+- In the Cloudflare dashboard, set `10.252.3.55/31` as your tunnel's **IPv4 Interface address** (refer to [Configure {props.productName}](#configure-magic-wan)).
+- In the Azure portal, add `10.252.3.55/32` to your Local Network Gateway's **Address space**.
+
+:::note
+It is important to ensure the subnet selected for the Interface Address does not overlap with any other subnet.
+:::
+
+:::note
+Refer to RFC 3021 for more information on using 31-bit prefixes on [IPv4 Point-to-Point Links](https://datatracker.ietf.org/doc/html/rfc3021).
+:::
+
+To configure the Address Space for the Local Network Gateway to support Tunnel Health Checks:
+
+1. Edit the Local Network Gateway configured in the previous section.
+2. Select **Connections**.
+3. Under **Address Space(s)** add the Interface Address of the Magic IPsec Tunnel from the Cloudflare dashboard in CIDR notation (for example, `10.252.3.55/32`).
+4. If using an Active/Active configuration, add the Interface Address of the second Magic IPsec Tunnel from the Cloudflare Dashboard in CIDR notation (for example, `10.252.3.55/32`) under **Address Space(s)**.
+4. Select **Save**.
+
+:::note
+The Magic IPsec Tunnel Interface Address should be entered as a `/31` in the Cloudflare Dashboard, but as a `/32` when configuring the Local Network Gateway Address Space(s) in the Azure portal.
+:::
+
+### 3. Create an IPsec VPN Connection
+
+Choose the following settings when creating your VPN Connection:
+
+1. **Virtual network gateway**: Select the Virtual Network Gateway you have created in step 2.
+2. **Local network gateway**: Select the Local Network Gateway created in step 3.
+3. **Use Azure Private IP Address**: **Disabled**
+4. **BGP**: **Disabled**
+5. **IPsec / IKE policy**: **Custom**
+ 1. **IKE Phase 1**
+ 1. **Encryption**: _GCMAES256_
+ 2. **Integrity/PRF**: _SHA384_
+ 3. **DH Group**: _ECP384_
+ 2. **IKE Phase 2(IPsec)**
+ 1. **IPsec Encryption**: _GCMAES256_
+ 2. **IPsec Integrity**: _GCMAES256_
+ 3. **PFS Group**: _ECP384_
+ 3. **IPsec SA lifetime in KiloBytes**: `0`
+ 4. **IPsec SA lifetime in seconds**: `28800`
+ 5. **Use policy based traffic selector**: **Disable**
+ 6. **DPD timeout in seconds**: `45`
+ 7. **Connection mode**: **InitiatorOnly**
+ 8. **Use custom traffic selectors**: **Disabled**
+6. After the connection is created, select **Settings** > **Authentication**, and input your PSK (this will need to match the PSK used by the {props.productName} configuration).
+
+Repeat this process to define the settings for the Connection to the Local Network Gateway that corresponds to the redundant Cloudflare anycast IP address.
+
+### 4. Route all Internet traffic through {props.productName} and Cloudflare Gateway
+
+Cloudflare Zero Trust customers can route Internet-bound traffic through {props.productName} to the Internet through Cloudflare Gateway.
+
+Microsoft does not permit specifying a default route (`0.0.0.0/0`) under Address Space in the Local Network Gateway. However, it is possible to work around this limitation through the use of route summarization.
+
+1. Go to **Local network gateways** and select the desired object.
+2. Go to **Configuration** > **Address Space(s)** and specify the following two subnets: `0.0.0.0/1` & `128.0.0.0/1`.
+3. Do not remove the subnet configured to support the Tunnel Health Checks.
+4. Select **Save**.
+
+## Install Cloudflare Zero Trust CA Certificate
+
+If you opt to route all Internet bound traffic through {props.productName} and want to take advantage of [HTTPS TLS decryption](/cloudflare-one/policies/gateway/http-policies/tls-decryption/), it will be necessary to install and trust the Cloudflare Zero Trust root CA certificate on your user's devices. You can either install the certificate provided by Cloudflare (default option), or generate your own custom certificate and upload it to Cloudflare.
+
+More details on how to install the root CA certificate can be found in [User-side certificates](/cloudflare-one/connections/connect-devices/user-side-certificates/) in the Cloudflare Zero Trust documentation.
+
+Once the root CA certificate is installed, open a web browser or use curl to validate Internet connectivity:
+
+```sh
+curl https://ipinfo.io
+```
+
+```json output
+{
+ "ip": "104.xxx.xxx.225",
+ "city": "Reston",
+ "region": "Virginia",
+ "country": "US",
+ "loc": "xx.xxxx,-xx.xxxx",
+ "org": "AS13335 Cloudflare, Inc.",
+ "postal": "20190",
+ "timezone": "America/New_York",
+ "readme": "https://ipinfo.io/missingauth"
+}
+```
+
+:::note
+ICMP (ping/traceroute) will work to remote {props.productName} sites, but is not forwarded to the Internet. Please ensure you validate connectivity via HTTP.
+:::
+
+## Validate connectivity and disable Azure Virtual Network Gateway anti-replay protection
+
+Once you have determined that connectivity has been established, Cloudflare recommends you disable anti-replay protection for the Azure Virtual Network Gateway site-to-site VPN connection. This can be accomplished through Microsoft Azure API.
+
+1. Determine the API token via PowerShell:
+
+```powershell
+Get-AzAccessToken
+```
+
+```txt output
+Token: eyJ0eAH-PdSPg
+ExpiresOn : 04/08/2024 23:32:47 +00:00
+Type : Bearer
+TenantId : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
+UserId : user@domain.com
+```
+
+2. Issue the API call to display the details of the site-to-site VPN Connection associated with the Azure Virtual Network Gateway (`GET` request):
+
+```bash
+curl --location 'https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/virtualNetworkGateways/{{virtualNetworkGatewayName}}?api-version=2022-05-01' \
+--header 'Authorization: Bearer eyJ0eAH-PdSPg'
+```
+
+3. Copy/paste the entire response into a text editor:
+
+```json
+{
+ "name": "{{virtualNetworkGatewayName}}",
+ "id": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/virtualNetworkGateways/{{virtualNetworkGatewayName}}",
+ "etag": "W/\"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\"",
+ "type": "Microsoft.Network/virtualNetworkGateways",
+ "location": "eastus"
+ },
+ "properties": {
+ "provisioningState": "Succeeded",
+ "resourceGuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
+ "packetCaptureDiagnosticState": "None",
+ "enablePrivateIpAddress": false,
+ "isMigrateToCSES": false,
+ "ipConfigurations": [
+ {
+ "name": "default",
+ "id": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/virtualNetworkGateways/{{virtualNetworkGatewayName}}/ipConfigurations/default",
+ "etag": "W/\"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\"",
+ "type": "Microsoft.Network/virtualNetworkGateways/ipConfigurations",
+ "properties": {
+ "provisioningState": "Succeeded",
+ "privateIPAllocationMethod": "Dynamic",
+ "publicIPAddress": {
+ "id": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/publicIPAddresses/{{virtualNetworkGatewayPublicIpAddress}}"
+ },
+ "subnet": {
+ "id": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/virtualNetworks/{{virtualNetworkGatewayName}}/subnets/GatewaySubnet"
+ }
+ }
+ }
+ ],
+ "natRules": [],
+ "virtualNetworkGatewayPolicyGroups": [],
+ "enableBgpRouteTranslationForNat": false,
+ "disableIPSecReplayProtection": false,
+ "sku": {
+ "name": "VpnGw2AZ",
+ "tier": "VpnGw2AZ",
+ "capacity": 2
+ },
+ "gatewayType": "Vpn",
+ "vpnType": "RouteBased",
+ "enableBgp": false,
+ "activeActive": false,
+ "bgpSettings": {
+ "asn": 65515,
+ "bgpPeeringAddress": "172.25.40.30",
+ "peerWeight": 0,
+ "bgpPeeringAddresses": [
+ {
+ "ipconfigurationId": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/virtualNetworkGateways/{{virtualNetworkGatewayName}}/ipConfigurations/default",
+ "defaultBgpIpAddresses": [
+ "172.25.40.30"
+ ],
+ "customBgpIpAddresses": [],
+ "tunnelIpAddresses": [
+ "{{CF ANYCAST IP}}"
+ ]
+ }
+ ]
+ },
+ "gatewayDefaultSite": {
+ "id": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/localNetworkGateways/{{localNetworkGatewayName}}"
+ },
+ "vpnGatewayGeneration": "Generation2",
+ "allowRemoteVnetTraffic": false,
+ "allowVirtualWanTraffic": false
+ }
+}
+```
+
+4. Locate the line that controls disabling IPsec anti-replay protection, and change it from `false` to `true`:
+
+```txt
+"disableIPSecReplayProtection": true
+```
+
+5. Upload the entire response in a subsequent API call (`PUT` request):
+
+```bash
+curl --location --request PUT \
+'https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/virtualNetworkGateways/{{virtualNetworkGatewayName}}?api-version=2022-05-01' \
+--header "Authorization: Bearer eyJ0eAH-PdSPg" \
+--header "Content-Type: application/json" \
+--data '{
+ "name": "{{virtualNetworkGatewayName}}",
+ "id": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/virtualNetworkGateways/{{virtualNetworkGatewayName}}",
+ "etag": "W/\"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\"",
+ "type": "Microsoft.Network/virtualNetworkGateways",
+ "location": "eastus"
+ },
+ "properties": {
+ "provisioningState": "Succeeded",
+ "resourceGuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
+ "packetCaptureDiagnosticState": "None",
+ "enablePrivateIpAddress": false,
+ "isMigrateToCSES": false,
+ "ipConfigurations": [
+ {
+ "name": "default",
+ "id": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/virtualNetworkGateways/{{virtualNetworkGatewayName}}/ipConfigurations/default",
+ "etag": "W/\"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\"",
+ "type": "Microsoft.Network/virtualNetworkGateways/ipConfigurations",
+ "properties": {
+ "provisioningState": "Succeeded",
+ "privateIPAllocationMethod": "Dynamic",
+ "publicIPAddress": {
+ "id": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/publicIPAddresses/{{virtualNetworkGatewayPublicIpAddress}}"
+ },
+ "subnet": {
+ "id": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/virtualNetworks/{{virtualNetworkGatewayName}}/subnets/GatewaySubnet"
+ }
+ }
+ }
+ ],
+ "natRules": [],
+ "virtualNetworkGatewayPolicyGroups": [],
+ "enableBgpRouteTranslationForNat": false,
+ "disableIPSecReplayProtection": true,
+ "sku": {
+ "name": "VpnGw2AZ",
+ "tier": "VpnGw2AZ",
+ "capacity": 2
+ },
+ "gatewayType": "Vpn",
+ "vpnType": "RouteBased",
+ "enableBgp": false,
+ "activeActive": false,
+ "bgpSettings": {
+ "asn": 65515,
+ "bgpPeeringAddress": "172.25.40.30",
+ "peerWeight": 0,
+ "bgpPeeringAddresses": [
+ {
+ "ipconfigurationId": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/virtualNetworkGateways/{{virtualNetworkGatewayName}}/ipConfigurations/default",
+ "defaultBgpIpAddresses": [
+ "172.25.40.30"
+ ],
+ "customBgpIpAddresses": [],
+ "tunnelIpAddresses": [
+ "{{CF ANYCAST IP}}"
+ ]
+ }
+ ]
+ },
+ "gatewayDefaultSite": {
+ "id": "/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/providers/Microsoft.Network/localNetworkGateways/{{localNetworkGatewayName}}"
+ },
+ "vpnGatewayGeneration": "Generation2",
+ "allowRemoteVnetTraffic": false,
+ "allowVirtualWanTraffic": false
+ }
+}'
+```
+
+6. Leave the replay protection setting checked in the Cloudflare dashboard, and wait several minutes before validating connectivity again.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/cisco-ios-xe.mdx b/src/content/partials/networking-services/magic-wan/third-party/cisco-ios-xe.mdx
new file mode 100644
index 00000000000000..dec3e160a4ab71
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/cisco-ios-xe.mdx
@@ -0,0 +1,229 @@
+---
+{}
+---
+
+This tutorial contains a configuration example for setting up an IPsec tunnel between Cisco IOS XE and Cloudflare. For this tutorial, the tested Cisco IOS XE software was version 17.03.07.
+
+You should replace peer addresses with the anycast IP addresses assigned to your account. For example:
+
+- **Anycast 01**: `162.159.###.###`
+- **Anycast 02**: `172.64.###.###`
+
+## Cisco IOS XE configuration example
+
+```txt
+crypto ikev2 proposal CF_MAGIC_WAN_IKEV2_PROPOSAL
+ encryption aes-cbc-256
+ integrity sha512 sha384 sha256
+ group 20
+!
+crypto ikev2 policy CF_MAGIC_WAN_IKEV2_POLICY
+ match fvrf any
+ proposal CF_MAGIC_WAN_IKEV2_PROPOSAL
+!
+crypto ikev2 keyring CF_MAGIC_WAN_KEYRING
+ peer GCP_CSR_IPSEC01
+ address 162.159.###.###
+ pre-shared-key hbGnJzFMqwltb###############BapXCOwsGZz2NMg
+ !
+ peer GCP_CSR_IPSEC02
+ address 172.64.###.###
+ pre-shared-key 1VscPp0LPFAcZ###############HOdN-1cUgKVduL4
+ !
+!
+!
+crypto ikev2 profile CF_MAGIC_WAN_01
+ match identity remote address 162.159.###.### 255.255.255.255
+ identity local fqdn ad329f56###############bbe898c0a0.33145236.ipsec.cloudflare.com
+ authentication remote pre-share
+ authentication local pre-share
+ keyring local CF_MAGIC_WAN_KEYRING
+ no config-exchange request
+!
+crypto ikev2 profile CF_MAGIC_WAN_02
+ match identity remote address 172.64.###.### 255.255.255.255
+ identity local fqdn 83f9c418###############29b3f97049.33145236.ipsec.cloudflare.com
+ authentication remote pre-share
+ authentication local pre-share
+ keyring local CF_MAGIC_WAN_KEYRING
+ no config-exchange request
+!
+!
+!
+!
+crypto ipsec profile CF_MAGIC_WAN_01
+ set security-association lifetime kilobytes disable
+ set security-association replay disable
+ set pfs group20
+ set ikev2-profile CF_MAGIC_WAN_01
+!
+crypto ipsec profile CF_MAGIC_WAN_02
+ set security-association lifetime kilobytes disable
+ set security-association replay disable
+ set pfs group14
+ set ikev2-profile CF_MAGIC_WAN_02
+!
+!
+!
+!
+interface Tunnel101
+ ip address 10.252.2.35 255.255.255.254
+ ip mtu 1450
+ ip tcp adjust-mss 1350
+ tunnel source 10.141.0.9
+ tunnel mode ipsec ipv4
+ tunnel destination 162.159.###.###
+ tunnel path-mtu-discovery
+ tunnel protection ipsec profile CF_MAGIC_WAN_01
+!
+interface Tunnel102
+ ip address 10.252.2.37 255.255.255.254
+ ip mtu 1450
+ ip tcp adjust-mss 1350
+ tunnel source 10.141.0.9
+ tunnel mode ipsec ipv4
+ tunnel destination 172.64.###.###
+ tunnel path-mtu-discovery
+ tunnel protection ipsec profile CF_MAGIC_WAN_02
+!
+interface GigabitEthernet1
+ ip address dhcp
+ ip nat outside
+ negotiation auto
+ no mop enabled
+ no mop sysid
+!
+interface GigabitEthernet2
+ ip address 10.10.0.35 255.255.255.0
+ negotiation auto
+ no mop enabled
+ no mop sysid
+```
+
+### Establish IPsec behind a NAT or CGNAT with port `4500`
+
+If your Cisco router is behind a NAT or CGNAT and you need to establish a connection on port `4500`, you can use the `nat force-encap`command.
+
+Add the `nat force-encap`command when setting up the `crypto ikev2 profile` for your tunnels:
+
+```txt {7}
+crypto ikev2 profile CF_MAGIC_WAN_01
+ match identity remote address 162.159.###.### 255.255.255.255
+ identity local fqdn ad329f56###############bbe898c0a0.33145236.ipsec.cloudflare.com
+ authentication remote pre-share
+ authentication local pre-share
+ keyring local CF_MAGIC_WAN_KEYRING
+ nat force-encap
+ no config-exchange request
+```
+
+## Diagnostic output: show crypto session detail
+
+```txt
+cisco-csr1000v#show crypto session detail
+Crypto session current status
+
+Code: C - IKE Configuration mode, D - Dead Peer Detection
+K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
+X - IKE Extended Authentication, F - IKE Fragmentation
+R - IKE Auto Reconnect, U - IKE Dynamic Route Update
+S - SIP VPN
+
+Interface: Tunnel101
+Profile: CF_MAGIC_WAN_01
+Uptime: 00:15:16
+Session status: UP-ACTIVE
+Peer: 162.159.###.### port 500 fvrf: (none) ivrf: (none)
+ Phase1_id: 162.159.###.###
+ Desc: (none)
+ Session ID: 6
+ IKEv2 SA: local 10.141.0.9/500 remote 162.159.###.###/500 Active
+ Capabilities:(none) connid:1 lifetime:23:44:44
+ IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
+ Active SAs: 2, origin: crypto map
+ Inbound: #pkts dec'ed 28110 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2684
+ Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2684
+
+Interface: Tunnel102
+Profile: CF_MAGIC_WAN_02
+Uptime: 00:14:59
+Session status: UP-ACTIVE
+Peer: 172.64.###.### port 500 fvrf: (none) ivrf: (none)
+ Phase1_id: 172.64.###.###
+ Desc: (none)
+ Session ID: 7
+ IKEv2 SA: local 10.141.0.9/500 remote 172.64.###.###/500 Active
+ Capabilities:(none) connid:2 lifetime:23:45:01
+ IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
+ Active SAs: 2, origin: crypto map
+ Inbound: #pkts dec'ed 27586 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2701
+ Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2701
+```
+
+## Diagnostic output: show crypto session remote `` detail
+
+```txt
+cisco-csr1000v#show crypto session remote 162.159.###.### detail
+Crypto session current status
+
+Code: C - IKE Configuration mode, D - Dead Peer Detection
+K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
+X - IKE Extended Authentication, F - IKE Fragmentation
+R - IKE Auto Reconnect, U - IKE Dynamic Route Update
+S - SIP VPN
+
+Interface: Tunnel101
+Profile: CF_MAGIC_WAN_01
+Uptime: 00:15:45
+Session status: UP-ACTIVE
+Peer: 162.159.###.### port 500 fvrf: (none) ivrf: (none)
+ Phase1_id: 162.159.###.###
+ Desc: (none)
+ Session ID: 6
+ IKEv2 SA: local 10.141.0.9/500 remote 162.159.###.###/500 Active
+ Capabilities:(none) connid:1 lifetime:23:44:15
+ IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
+ Active SAs: 2, origin: crypto map
+ Inbound: #pkts dec'ed 29000 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2655
+ Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2655
+```
+
+## Diagnostic output: show crypto session remote `` detail
+
+```txt
+cisco-csr1000v#show crypto session remote 172.64.###.### detail
+Crypto session current status
+
+Code: C - IKE Configuration mode, D - Dead Peer Detection
+K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
+X - IKE Extended Authentication, F - IKE Fragmentation
+R - IKE Auto Reconnect, U - IKE Dynamic Route Update
+S - SIP VPN
+
+Interface: Tunnel102
+Profile: CF_MAGIC_WAN_02
+Uptime: 00:17:10
+Session status: UP-ACTIVE
+Peer: 172.64.###.### port 500 fvrf: (none) ivrf: (none)
+ Phase1_id: 172.64.###.###
+ Desc: (none)
+ Session ID: 7
+ IKEv2 SA: local 10.141.0.9/500 remote 172.64.###.###/500 Active
+ Capabilities:(none) connid:2 lifetime:23:42:50
+ IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
+ Active SAs: 2, origin: crypto map
+ Inbound: #pkts dec'ed 31639 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2569
+ Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2569
+```
+
+## Troubleshooting
+
+If you notice connectivity issues after rebooting your Cisco router, your IPsec Security Associations (SAs) might be out of sync. Cisco recommends that you enable the Invalid Security Parameter Index (SPI) recovery feature to solve this issue. To do so, add the following lines to your configuration file:
+
+```txt
+conf t
+crypto isakmp invalid-spi-recovery
+exit
+```
+
+Refer to [Cisco's documentation](https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/115801-technote-iosvpn-00.html) for more information.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/fitelnet.mdx b/src/content/partials/networking-services/magic-wan/third-party/fitelnet.mdx
new file mode 100644
index 00000000000000..b239e9289c3f07
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/fitelnet.mdx
@@ -0,0 +1,280 @@
+---
+params:
+ - productName
+ - addTunnelsUrl
+ - typeId_ipv4_addrUrl
+ - configureStaticRoutesUrl
+---
+
+This tutorial describes how to configure the Furukawa Electric's FITELnet F220 and F70 devices to connect to Cloudflare {props.productName} via IPsec tunnels. The use cases described in this tutorial are for both east-west (branch to branch) and north-south (Internet-bound).
+
+## Testing environment
+
+These configurations were tested on FITELnet F220 and F70 series with the following firmware versions:
+
+- **F220 series**: Version 01.11(00)
+- **F70 series**: Version 01.09(00)
+
+## IPsec configuration
+
+### {props.productName} configuration
+
+1. Go to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account.
+2. Go to **{props.productName}** > **Configuration**.
+3. From the **Tunnels** tab, select **Create**.
+4. For the first IPsec tunnel, ensure the following settings are defined (refer to Add tunnels for information on settings not mentioned here):
+ - **Tunnel name**: `FITEL-tunnel-1`
+ - **Interface address**: Enter `10.0.0.1/31` for your first tunnel.
+ - **Customer endpoint**: This setting is not required unless your router is using an IKE ID of type `ID_IPV4_ADDR`.
+ - **Cloudflare endpoint**: The Cloudflare anycast IP assigned to you by your account team.
+ - **Pre-shared key**: Create a pre-shared key for your first tunnel.
+5. For the second IPsec tunnel, make the same changes as you did for the first tunnel, and ensure these additional setting is defined:
+ - **Tunnel name**: `FITEL-tunnel-2`
+ - **Interface address**: Enter `10.0.0.3/31` for your second tunnel.
+ - **Customer endpoint**: This setting is not required unless your router is using an IKE ID of type `ID_IPV4_ADDR`.
+ - **Cloudflare endpoint**: The Cloudflare anycast IP assigned to you by your account team.
+ - **Pre-shared key**: Create a pre-shared key for your second tunnel.
+
+### FITELnet router configuration
+
+#### Router 1 settings
+
+Use the CLI to configure these settings:
+
+```txt
+interface Tunnel 1
+ ip address 10.0.0.0 255.255.255.254
+ tunnel mode ipsec map MAP1
+ link-state sync-sa
+exit
+!
+
+crypto ipsec policy IPsec_POLICY
+ set security-association always-up
+ set security-association lifetime seconds 28800
+ set security-association transform-keysize aes 256 256 256
+ set security-association transform esp-aes esp-sha256-hmac
+ set mtu 1460
+ set mss 1350
+ set ip df-bit 0
+ set ip fragment post
+ ! if there is a NAT router between Cloudflare and FITELnet,
+ ! add the two udp-encapsulation options below
+ set udp-encapsulation nat-t keepalive interval 30 always-send
+ set udp-encapsulation-force
+exit
+!
+crypto ipsec selector SELECTOR
+ src 1 ipv4 any
+ dst 1 ipv4 any
+exit
+!
+crypto isakmp keepalive
+crypto isakmp log sa
+crypto isakmp log session
+crypto isakmp log negotiation-fail
+crypto isakmp negotiation always-up-params interval 100 max-initiate 10 max-pending 10 delay 1
+crypto ipsec replay-check disable
+!
+crypto isakmp policy ISAKMP_POLICY
+ authentication pre-share
+ encryption aes
+ encryption-keysize aes 256 256 256
+ group 20
+ lifetime 86400
+ hash sha sha-256
+ initiate-mode aggressive
+exit
+!
+crypto isakmp profile PROF1
+ ! set the value of FQDN ID for self-identify
+ self-identity fqdn
+ set isakmp-policy ISAKMP_POLICY
+ set ipsec-policy IPsec_POLICY
+ set peer
+ ike-version 2
+ local-key
+exit
+!
+crypto map MAP1 ipsec-isakmp
+ match address SELECTOR
+ set isakmp-profile PROF1
+exit
+!
+```
+
+#### Router 2 settings
+
+Use the CLI to configure these settings:
+
+```txt
+interface Tunnel 2
+ ip address 10.0.0.2 255.255.255.254
+ tunnel mode ipsec map MAP1
+ link-state sync-sa
+exit
+!
+
+crypto ipsec policy IPsec_POLICY
+ set security-association always-up
+ set security-association lifetime seconds 28800
+ set security-association transform-keysize aes 256 256 256
+ set security-association transform esp-aes esp-sha256-hmac
+ set mtu 1460
+ set mss 1350
+ set ip df-bit 0
+ set ip fragment post
+ ! if there is a NAT router between Cloudflare and FITELnet,
+ ! add the two udp-encapsulation options below
+ set udp-encapsulation nat-t keepalive interval 30 always-send
+ set udp-encapsulation-force
+exit
+!
+crypto ipsec selector SELECTOR
+ src 1 ipv4 any
+ dst 1 ipv4 any
+exit
+!
+crypto isakmp keepalive
+crypto isakmp log sa
+crypto isakmp log session
+crypto isakmp log negotiation-fail
+crypto isakmp negotiation always-up-params interval 100 max-initiate 10 max-pending 10 delay 1
+crypto ipsec replay-check disable
+!
+crypto isakmp policy ISAKMP_POLICY
+ authentication pre-share
+ encryption aes
+ encryption-keysize aes 256 256 256
+ group 20
+ lifetime 86400
+ hash sha sha-256
+ initiate-mode aggressive
+exit
+!
+crypto isakmp profile PROF1
+ ! set the value of FQDN ID for self-identify
+ self-identity fqdn
+ set isakmp-policy ISAKMP_POLICY
+ set ipsec-policy IPsec_POLICY
+ set peer
+ ike-version 2
+ local-key
+exit
+!
+crypto map MAP1 ipsec-isakmp
+ match address SELECTOR
+ set isakmp-profile PROF1
+exit
+!
+```
+
+## Static route configuration
+
+To configure routes for east-west (branch to branch) connections, refer to the following settings.
+
+### {props.productName}
+
+1. Go to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account.
+2. Go to **{props.productName}** > **Configuration**.
+3. From the **Static Routes** tab, select **Create**.
+4. For the first route, ensure the following settings are defined (refer to Configure static routes to learn about settings not mentioned here):
+
+- **Prefix**: `192.168.0.0/24`
+- **Tunnel/Next hop**: _FITEL-tunnel-1 / 10.0.0.0_
+
+5. For the second route, ensure the following settings are defined:
+
+- **Prefix**: `192.168.1.0/24`
+- **Tunnel/Next hop**: _FITEL-tunnel-2 / 10.0.0.2_
+
+### FITELnet router configuration
+
+#### Router 1
+
+Use the CLI to configure these settings:
+
+```txt
+ip route 192.168.0.0 255.255.255.0 tunnel 1
+```
+
+#### Router 2
+
+Use the CLI to configure these settings:
+
+```txt
+ip route 192.168.1.0 255.255.255.0 tunnel 2
+```
+
+
+## Connection test
+
+### IPsec status
+
+In the FITELnet router CLI, you can run `show crypto sa` to check the status of the IPsec security associations (SAs). `Total number of ISAKMP/IPSEC SA` shows the number of established SAs.
+
+```txt
+show crypto sa
+
+ IKE_SA
+ Mode:
+ Local IP : /500
+ Local ID : (ipv4)
+ Remote IP : anycast-address/500
+ Remote ID : anycast-address (ipv4)
+ Local Authentication method : Pre-shared key
+ Remote Authentication method : Pre-shared key
+ Encryption algorithm : aes256-cbc
+ Hash algorithm : hmac-sha256-128
+ Diffie-Hellman group : 20
+ Initiator Cookie : aaaaaaaa bbbbbbbb
+ Responder Cookie : cccccccc dddddddd
+ Life time : 6852/14400 sec
+ DPD : on
+
+ CHILD_SA
+ Selector :
+ 0.0.0.0/0 ALL ALL <---> 0.0.0.0/0 ALL ALL
+ Interface : tunnel 1
+ Peer IP : anycast-address/500
+ Local IP : xxx.xxx.xxx.xxx/500
+ Encryption algorithm : AES-CBC/256
+ Authentication algorithm : HMAC-SHA2-256
+ Life time : 22868/28800 sec
+ PFS : off ESN : off
+ IN
+ SPI : eeeeeeee
+ Packets : 0
+ Octets : 0
+ Replay error : 0
+ Auth error : 0
+ Padding error : 0
+ Rule error : 0
+ OUT
+ SPI : ffffffff
+ Packets : 0
+ Octets : 0
+ Seq lapped : 0
+
+ Total number of ISAKMP SA 1
+ Total number of IPSEC SA 1
+```
+
+### Route Status
+
+In the FITELnet router CLI, you can run `show ip route` to check the route information. A `*` in the route information indicates that the route information is valid.
+
+```txt
+show ip route
+
+Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
+ B - BGP, T - Tunnel, i - IS-IS, V - VRRP track,
+ Iu - ISAKMP SA up, It - ISAKMP tunnel route, Ip - ISAKMP l2tpv2-ppp
+ Dc - DHCP-client, L - Local Breakout
+ > - selected route, * - FIB route, p - stale info
+
+
+S > * 192.168.1.0/24 [100/0] is directly connected, Tunnel1
+
+#
+```
diff --git a/src/content/partials/networking-services/magic-wan/third-party/fortinet.mdx b/src/content/partials/networking-services/magic-wan/third-party/fortinet.mdx
new file mode 100644
index 00000000000000..af02b80378c870
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/fortinet.mdx
@@ -0,0 +1,526 @@
+---
+params:
+ - productName
+ - bidirectionalHealthChecksUrl
+ - addTunnelsUrl
+ - equalCostMultipathRoutingEcmpUrl
+ - configureStaticRoutesUrl
+ - checkTunnelHealthInTheDashboardUrl
+---
+
+import { Render } from "~/components";
+
+This tutorial provides information and examples of how to configure Cloudflare {props.productName} with IPsec tunnels in conjunction with Fortinet FortiGate firewalls.
+
+The FortiGate configuration settings presented here support bidirectional health checks as required by Cloudflare {props.productName}. However, they do not factor in any other traffic flows outside of the tunnel health checks. The configuration may need to be adjusted based on your current FortiGate configuration.
+
+## Testing Environment
+
+The FortiGate configuration was tested on two different FortiGate firewalls:
+
+- FortiGate Virtual Appliance version 7.0.8, running on VMware ESXi 6.5
+- FortiGate FG80F, version 7.0.12
+
+## {props.productName} configuration
+
+The first step to setting up {props.productName} is to add {props.productName} IPsec tunnels and Magic static routes to your Cloudflare account via the dashboard or API.
+
+Before proceeding, ensure that you have the anycast IPs associated with your account. Check with your Cloudflare account team if you do not yet have them.
+
+### Magic IPsec Tunnels
+
+Cloudflare recommends customers configure two Magic IPsec tunnels per firewall/router - one to each of the two anycast IP addresses.
+
+1. Go to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account.
+2. Go to **{props.productName}** > **Configuration**.
+3. From the **Tunnels** tab, select **Create**.
+4. Select **IPsec tunnel** > **Next**.
+5. When creating your IPsec tunnels:
+ - **Health check type**: Change to _Request_.
+ - **Replay Protection**: Do not change from the default setting.
+ - Set up fields such as **Name**, **Description**, **Interface Address**, **Customer endpoint**, and **Cloudflare endpoint** with settings that work for you. Refer to Add tunnels to learn more.
+
+### Magic static routes
+
+Add two Magic static routes to define the IP address space that exists behind the Magic IPsec tunnels - one to each of the two Magic IPsec tunnels defined in the previous section.
+
+By default, the Magic static routes are defined with the priority set to `100`. Cloudflare leverages Equal Cost Multipath Routing (ECMP) and will load balance the traffic equally across the two tunnels. If you prefer to use an Active/Passive model, you can leave the default value for the first route set to `100`, and set the value for the second tunnel to `150` (higher value is a lower priority).
+
+1. Go to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account.
+
+2. Go to **{props.productName}** > **Configuration**.
+
+3. From the **Static Routes** tab, select **Create**.
+
+4. For the first route, ensure the following settings are defined (refer to Configure static routes to learn about settings not mentioned here):
+
+ - **Prefix**: Specify the [RFC1918](https://datatracker.ietf.org/doc/html/rfc1918) subnet that exists behind the first Magic IPsec tunnel you have defined in the previous section.
+ - **Tunnel/Next hop**: Select your first tunnel (Tunnel 01 of 02).
+
+ 
+
+5. For the second route, ensure the following settings are defined:
+
+ - **Prefix**: Specify the [RFC1918](https://datatracker.ietf.org/doc/html/rfc1918) subnet that exists behind the second Magic IPsec tunnel defined in the previous section.
+ - **Tunnel/Next hop**: Select your second tunnel (Tunnel 02 of 02).
+
+ 
+
+## Fortinet FortiGate configuration
+
+### Enable asymmetric routing
+
+To ensure health checks work as expected, enable asymmetric routing for ICMP. This option is required. Otherwise, the tunnel health checks which are critical for proper {props.productName} functionality will not work as designed.
+
+Note that enabling asymmetric routing will affect FortiGate behavior. To learn more, refer to [How FortiGate behaves when asymmetric routing is enabled](https://community.fortinet.com/t5/FortiGate/Technical-Note-How-the-FortiGate-behaves-when-asymmetric-routing/ta-p/198575).
+
+```txt
+config system settings
+ set asymroute-icmp enable
+end
+```
+
+### Configure NAT-T (optional)
+
+If you have NAT traversal (NAT-T) on your network, you need to enable this feature and initiate IKE communications on port `4500`.
+
+To set the IKE port, add the following to your system settings:
+
+```txt
+config system settings
+ set ike-port 4500
+end
+```
+
+To enable NAT-T, add `set nattraversal enable` to the IPsec tunnels you are configuring.
+
+```txt
+fortigate # config vpn ipsec phase1-interface
+ edit ""
+ set nattraversal enable
+```
+
+Refer to [Fortinet's documentation](https://community.fortinet.com/t5/FortiGate/Technical-Tip-IPSec-VPN-NAT-traversal/ta-p/197873) for more details.
+
+### Disable anti-replay protection
+
+For route-based IPsec configurations, you will need to disable anti-replay protection. The command below disables anti-replay protection globally, but you can also do this per firewall policy. Refer to Fortinet's documentation on [anti-replay support per policy](https://community.fortinet.com/t5/FortiGate/Technical-Tip-Anti-Replay-option-support-per-policy/ta-p/191435) to learn more.
+
+```txt
+config system global
+ set anti-replay disable
+end
+```
+
+### IPsec tunnels
+
+Magic IPsec tunnels leverage a route-based site-to-site VPN model. This model relies on the use of virtual tunnel interfaces and routing to define the traffic that flows across the IPsec tunnels.
+
+Configure two IPsec tunnels using the `phase1-interface` and `phase2-interface` objects.
+
+:::note
+Refer to the Cloudflare {props.productName} dashboard to obtain the FQDN ID value when specifying the `localid` attribute/value pair in the `phase1-interface` configuration. To find this value, go to the [Cloudflare dashboard](https://dash.cloudflare.com/) > **{props.productName}** > **Manage {props.productName} configuration** > **Tunnels**. Then, find your IPsec tunnel and expand it to reveal all the information associated to it.
+:::
+
+The following examples assume `wan1` is the external/egress interface of the FortiGate firewall.
+
+#### Add Phase 1 interfaces
+
+`MWAN_IPsec_Tun1` corresponds to Tunnel 01 of 02 added earlier in the Cloudflare section of the configuration. `MWAN_IPsec_Tun2` corresponds to Tunnel 02 of 02 added earlier in the Cloudflare section of the configuration.
+
+```txt
+fortigate # config vpn ipsec phase1-interface
+ edit "MWAN_IPsec_Tun1"
+ set interface "wan1"
+ set ike-version 2
+ set keylife 86400
+ set peertype any
+ set net-device enable
+ set proposal aes256gcm-prfsha512 aes256gcm-prfsha384 aes256gcm-prfsha256
+ set localid "f1473dXXXXXXX72e33.49561179.ipsec.cloudflare.com"
+ set dhgrp 20
+ set nattraversal disable
+ set remote-gw 162.159.67.210
+ set add-gw-route enable
+ set psksecret
+ next
+ edit "MWAN_IPsec_Tun2"
+ set interface "wan1"
+ set ike-version 2
+ set keylife 86400
+ set peertype any
+ set net-device enable
+ set proposal aes256gcm-prfsha512 aes256gcm-prfsha384 aes256gcm-prfsha256
+ set localid "de91565XXXXXXXfbbd6632.49561179.ipsec.cloudflare.com"
+ set dhgrp 20
+ set nattraversal disable
+ set remote-gw 172.XX.XX.210
+ set add-gw-route enable
+ set psksecret ENC
+ next
+end
+```
+
+#### Add Phase 2 interfaces
+
+Add two `phase2-interfaces` - one for each of the two `phase1-interfaces` as follows:
+
+```txt
+fortigate # config vpn ipsec phase2-interface
+ edit "MWAN_IPsec_Tun1"
+ set phase1name "MWAN_IPsec_Tun1"
+ set proposal aes256gcm aes128gcm
+ set dhgrp 20
+ set replay disable
+ set keylifeseconds 28800
+ set auto-negotiate enable
+ set keepalive enable
+ next
+ edit "MWAN_IPsec_Tun2"
+ set phase1name "MWAN_IPsec_Tun2"
+ set proposal aes256gcm aes128gcm
+ set dhgrp 20
+ set replay disable
+ set keylifeseconds 28800
+ set auto-negotiate enable
+ set keepalive enable
+ next
+end
+```
+
+### Network interfaces
+
+#### Virtual tunnel interfaces
+
+Configure the virtual tunnel interfaces that were automatically added when specifying the `set net-device enable` within the `phase1-interface` settings.
+
+These are the only settings that should need to be added to the virtual tunnel interfaces:
+
+- `ip`: The local IP address (specify with a `/32` netmask - `255.255.255.255`).
+- `remote-ip`: The value associated with the interface address specified earlier in the Magic IPsec tunnels section (specify with a `/31` netmask - `255.255.255.254`).
+- `alias`: This value is optional.
+
+The following examples assume `wan1` is the external/egress interface of the FortiGate firewall.
+
+```txt
+fortigate # config system interface
+ edit "MWAN_IPsec_Tun1"
+ set vdom "root"
+ set ip 10.252.2.91 255.255.255.255
+ set allowaccess ping
+ set type tunnel
+ set remote-ip 10.252.2.90 255.255.255.254
+ set alias "MWAN_IPsec_Tun1"
+ set snmp-index 17
+ set interface "wan1"
+ next
+ edit "MWAN_IPsec_Tun2"
+ set vdom "root"
+ set ip 10.252.2.93 255.255.255.255
+ set allowaccess ping
+ set type tunnel
+ set remote-ip 10.252.2.92 255.255.255.254
+ set alias "MWAN_IPsec_Tun2"
+ set snmp-index 18
+ set interface "wan1"
+ next
+end
+```
+
+### Validate communication across virtual tunnel interfaces
+
+Once the virtual tunnel interfaces have been configured, you should be able to ping the IP address associated with the `remote-ip` attribute.
+
+Below you have examples of a successful result from pinging across both of the virtual tunnel interfaces configured in the previous section:
+
+#### MWAN_IPsec_Tun1
+
+```txt
+fortigate # execute ping 10.252.2.90
+PING 10.252.2.90 (10.252.2.90): 56 data bytes
+64 bytes from 10.252.2.90: icmp_seq=0 ttl=64 time=5.8 ms
+64 bytes from 10.252.2.90: icmp_seq=1 ttl=64 time=5.8 ms
+64 bytes from 10.252.2.90: icmp_seq=2 ttl=64 time=5.8 ms
+64 bytes from 10.252.2.90: icmp_seq=3 ttl=64 time=5.8 ms
+64 bytes from 10.252.2.90: icmp_seq=4 ttl=64 time=5.7 ms
+
+--- 10.252.2.90 ping statistics ---
+5 packets transmitted, 5 packets received, 0% packet loss
+round-trip min/avg/max = 5.7/5.7/5.8 ms
+```
+
+#### MWAN_IPsec_Tun2
+
+```txt
+fortigate # execute ping 10.252.2.92
+PING 10.252.2.92 (10.252.2.92): 56 data bytes
+64 bytes from 10.252.2.92: icmp_seq=0 ttl=64 time=6.1 ms
+64 bytes from 10.252.2.92: icmp_seq=1 ttl=64 time=6.1 ms
+64 bytes from 10.252.2.92: icmp_seq=2 ttl=64 time=6.1 ms
+64 bytes from 10.252.2.92: icmp_seq=3 ttl=64 time=6.1 ms
+64 bytes from 10.252.2.92: icmp_seq=4 ttl=64 time=6.0 ms
+
+--- 10.252.2.92 ping statistics ---
+5 packets transmitted, 5 packets received, 0% packet loss
+round-trip min/avg/max = 6.0/6.0/6.1 ms
+```
+
+### Zone objects (optional)
+
+This sample configuration assumes there are three zones configured on the FortiGate firewall. These zone objects are used in the policies referenced later in this document:
+
+- `Trust_Zone`: Contains the LAN interface(s).
+- `Untrust_Zone`: Contains the WAN interface.
+- `Cloudflare_Zone`: Contains both IPsec Tunnel interfaces.
+
+```txt
+fortigate # config system zone
+ edit "Cloudflare_Zone"
+ set intrazone allow
+ set interface "MWAN_IPsec_Tun1" "MWAN_IPsec_Tun2"
+ next
+ edit "Trust_Zone"
+ set intrazone allow
+ set interface "internal"
+ next
+ edit "Untrust_Zone"
+ set intrazone allow
+ set interface "wan1"
+ next
+end
+```
+
+### Create Address Objects
+
+Create Address Objects to represent the [Cloudflare IPv4 address space](https://www.cloudflare.com/ips) as well as objects for the bidirectional health check anycast IPs:
+
+```txt
+config firewall address
+ edit "Cloudflare_IPv4_01"
+ set color 9
+ set subnet 173.245.48.0 255.255.240.0
+ next
+ edit "Cloudflare_IPv4_02"
+ set color 9
+ set subnet 103.21.244.0 255.255.252.0
+ next
+ edit "Cloudflare_IPv4_03"
+ set color 9
+ set subnet 103.22.200.0 255.255.252.0
+ next
+ edit "Cloudflare_IPv4_04"
+ set color 9
+ set subnet 103.31.4.0 255.255.252.0
+ next
+ edit "Cloudflare_IPv4_05"
+ set color 9
+ set subnet 141.101.64.0 255.255.192.0
+ next
+ edit "Cloudflare_IPv4_06"
+ set color 9
+ set subnet 108.162.192.0 255.255.192.0
+ next
+ edit "Cloudflare_IPv4_07"
+ set color 9
+ set subnet 190.93.240.0 255.255.240.0
+ next
+ edit "Cloudflare_IPv4_08"
+ set color 9
+ set subnet 188.114.96.0 255.255.240.0
+ next
+ edit "Cloudflare_IPv4_09"
+ set color 9
+ set subnet 197.234.240.0 255.255.252.0
+ next
+ edit "Cloudflare_IPv4_10"
+ set color 9
+ set subnet 198.41.128.0 255.255.128.0
+ next
+ edit "Cloudflare_IPv4_11"
+ set color 9
+ set subnet 162.158.0.0 255.254.0.0
+ next
+ edit "Cloudflare_IPv4_12"
+ set color 9
+ set subnet 104.16.0.0 255.248.0.0
+ next
+ edit "Cloudflare_IPv4_13"
+ set color 9
+ set subnet 104.24.0.0 255.252.0.0
+ next
+ edit "Cloudflare_IPv4_14"
+ set color 9
+ set subnet 172.64.0.0 255.248.0.0
+ next
+ edit "Cloudflare_IPv4_15"
+ set color 9
+ set subnet 131.0.72.0 255.255.252.0
+ next
+ edit "Bidirect_HC_Endpoint_01"
+ set comment "Bidirectional health check endpoint address"
+ set color 9
+ set subnet 172.64.240.253 255.255.255.255
+ next
+ edit "Bidirect_HC_Endpoint_02"
+ set comment "Bidirectional health check endpoint address"
+ set color 9
+ set subnet 172.64.240.254 255.255.255.255
+ next
+end
+```
+
+### Configure Address Group Object
+
+Create an Address Object that contains all of the Cloudflare IPv4 subnets as specified in the previous section. You can copy/paste the CLI commands below into an SSH terminal and the objects will get created automatically:
+
+```txt
+config firewall addrgrp
+ edit "Cloudflare_IPv4_Nets"
+ set member "Cloudflare_IPv4_01" "Cloudflare_IPv4_02" "Cloudflare_IPv4_03" "Cloudflare_IPv4_04" "Cloudflare_IPv4_05" "Cloudflare_IPv4_06" "Cloudflare_IPv4_07" "Cloudflare_IPv4_08" "Cloudflare_IPv4_09" "Cloudflare_IPv4_10" "Cloudflare_IPv4_11" "Cloudflare_IPv4_12" "Cloudflare_IPv4_13" "Cloudflare_IPv4_14" "Cloudflare_IPv4_15"
+ set color 9
+ next
+end
+```
+
+### Add security policy
+
+Add a firewall rule to permit the ICMP traffic associated with the reply style bidirectional health checks.
+
+:::note
+This example assumes this rule is the second rule in the firewall policy (`edit 2`). If you opt to copy/paste the example into an SSH session, edit the numeric value associated with the rule position accordingly.
+:::
+
+```txt
+fortigate (policy) # show
+config firewall policy
+ edit 2
+ set name "CF_Magic_Health_Checks"
+ set uuid 80eb76ce-3033-51ee-c5e5-d5a670dff3b3
+ set srcintf "Cloudflare_Zone"
+ set action accept
+ set srcaddr "Cloudflare_IPv4_Nets"
+ set dstaddr "Bidirect_HC_Endpoint_01" "Bidirect_HC_Endpoint_02"
+ set schedule "always"
+ set service "ALL_ICMP"
+ set logtraffic all
+ next
+end
+```
+
+### Policy-based routing
+
+Policy-based routing rules are required to ensure the traffic associated with the bidirectional health checks received over a Magic IPsec tunnel is sent back across the same Magic IPsec tunnel.
+
+Add two policy-based routing rules, one for each of the two Magic IPsec tunnels.
+
+:::note
+This example assumes the rules below are the first and second rules respectively (`edit 1` and `edit 2`). If you opt to copy/paste the example into an SSH session, edit the numeric value associated with the rule position accordingly.
+:::
+
+```txt
+fortigate # config router policy
+ edit 1
+ set input-device "MWAN_IPsec_Tun1"
+ set srcaddr "all"
+ set dstaddr "all"
+ set gateway 10.252.2.90
+ set output-device "MWAN_IPsec_Tun1"
+ next
+ edit 2
+ set input-device "MWAN_IPsec_Tun2"
+ set srcaddr "all"
+ set dstaddr "all"
+ set gateway 10.252.2.92
+ set output-device "MWAN_IPsec_Tun2"
+ next
+end
+```
+
+## Monitor Cloudflare Magic IPsec tunnel health checks
+
+The Cloudflare dashboard monitors the health of all anycast tunnels on your account that route traffic from Cloudflare to your origin network. Refer to Check tunnel health in the dashboard for more information.
+
+## Troubleshooting
+
+### Packet Capture
+
+Packet captures allow you to determine whether or not the policy-based routing rules are working as expected.
+
+:::note
+Due to the nature of the reply-style tunnel health checks, you will see ICMP Reply packets in both the ingress and egress direction. This is expected behavior.
+:::
+
+The expected behavior should look like the examples below - traffic ingressing Tunnel 01 of 02 should egress the same tunnel.
+
+```txt
+fortigate # diagnose sniffer packet any 'host 172.64.240.253' 4
+interfaces=[any]
+filters=[host 172.64.240.253]
+0.601569 MWAN_IPsec_Tun1 in 172.64.240.253 -> 162.158.176.118: icmp: echo reply
+0.601585 MWAN_IPsec_Tun1 out 172.64.240.253 -> 162.158.176.118: icmp: echo reply
+0.611164 MWAN_IPsec_Tun1 in 172.64.240.253 -> 172.71.87.94: icmp: echo reply
+0.611178 MWAN_IPsec_Tun1 out 172.64.240.253 -> 172.71.87.94: icmp: echo reply
+0.617562 MWAN_IPsec_Tun1 in 172.64.240.253 -> 172.71.129.214: icmp: echo reply
+0.617574 MWAN_IPsec_Tun1 out 172.64.240.253 -> 172.71.129.214: icmp: echo reply
+0.622042 MWAN_IPsec_Tun1 in 172.64.240.253 -> 172.69.61.43: icmp: echo reply
+0.622056 MWAN_IPsec_Tun1 out 172.64.240.253 -> 172.69.61.43: icmp: echo reply
+0.624092 MWAN_IPsec_Tun1 in 172.64.240.253 -> 172.68.9.214: icmp: echo reply
+```
+
+Conversely, traffic ingressing Tunnel 02 of 02 should egress the same tunnel:
+
+```txt
+fortigate # diagnose sniffer packet any 'host 172.64.240.254' 4
+interfaces=[any]
+filters=[host 172.64.240.254]
+0.912041 MWAN_IPsec_Tun2 in 172.64.240.254 -> 172.70.177.56: icmp: echo reply
+0.912057 MWAN_IPsec_Tun2 out 172.64.240.254 -> 172.70.177.56: icmp: echo reply
+0.913579 MWAN_IPsec_Tun2 in 172.64.240.254 -> 172.70.221.154: icmp: echo reply
+0.913592 MWAN_IPsec_Tun2 out 172.64.240.254 -> 172.70.221.154: icmp: echo reply
+0.914247 MWAN_IPsec_Tun2 in 172.64.240.254 -> 162.158.1.85: icmp: echo reply
+0.914260 MWAN_IPsec_Tun2 out 172.64.240.254 -> 162.158.1.85: icmp: echo reply
+0.918533 MWAN_IPsec_Tun2 in 172.64.240.254 -> 172.71.125.75: icmp: echo reply
+0.918550 MWAN_IPsec_Tun2 out 172.64.240.254 -> 172.71.125.75: icmp: echo reply
+0.924465 MWAN_IPsec_Tun2 in 172.64.240.254 -> 172.69.21.134: icmp: echo reply
+```
+
+### Flow Debugging
+
+Flow debugging can be helpful when it comes to determining whether or not traffic is ingressing/egressing the firewall via the expected path. It takes steps much further than the sniffer packet captures in the previous section, but it creates a tremendous amount of logging and should only be enabled when absolutely necessary.
+
+Additionally, customers will likely need to contact Fortinet technical support for assistance with interpreting the flow debug logs, as well as to obtain recommendations in terms of how to configure FortiGate to ensure flows are routed correctly based on the application's requirements.
+
+```txt
+fortigate # diagnose debug disable
+fortigate # diagnose debug flow filter clear
+fortigate # diagnose debug reset
+fortigate # diagnose debug flow filter addr 172.64.240.253
+fortigate # diagnose debug show flow show function-name enable
+fortigate # diagnose debug config-error-log timestamps enable
+fortigate # diagnose debug flow trace start 999
+fortigate # diagnose debug enable
+fortigate # 2023-08-01 09:27:26 id=20085 trace_id=2871 func=print_pkt_detail line=5844 msg="vd-root:0 received a packet(proto=1, 172.64.240.253:56968->172.70.121.28:0) tun_id=162.159.67.210 from MWAN_IPsec_Tun1. type=0, code=0, id=56968, seq=0."
+2023-08-01 09:27:26 id=20085 trace_id=2871 func=rpdb_srv_match_input line=1036 msg="Match policy routing id=1: to 10.252.2.90 via ifindex-34"
+2023-08-01 09:27:26 id=20085 trace_id=2871 func=vf_ip_route_input_common line=2605 msg="find a route: flag=00000000 gw-162.159.67.210 via MWAN_IPsec_Tun1"
+2023-08-01 09:27:26 id=20085 trace_id=2871 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface MWAN_IPsec_Tun1, tun_id=0.0.0.0"
+2023-08-01 09:27:26 id=20085 trace_id=2871 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel MWAN_IPsec_Tun1"
+2023-08-01 09:27:26 id=20085 trace_id=2871 func=esp_output4 line=844 msg="IPsec encrypt/auth"
+2023-08-01 09:27:26 id=20085 trace_id=2871 func=ipsec_output_finish line=544 msg="send to 172.71.91.34 via intf-wan1"
+2023-08-01 09:27:26 id=20085 trace_id=2872 func=print_pkt_detail line=5844 msg="vd-root:0 received a packet(proto=1, 172.64.240.253:18685->162.158.209.64:0) tun_id=162.159.67.210 from MWAN_IPsec_Tun1. type=0, code=0, id=18685, seq=0."
+2023-08-01 09:27:26 id=20085 trace_id=2872 func=rpdb_srv_match_input line=1036 msg="Match policy routing id=1: to 10.252.2.90 via ifindex-34"
+2023-08-01 09:27:26 id=20085 trace_id=2872 func=vf_ip_route_input_common line=2605 msg="find a route: flag=00000000 gw-162.159.67.210 via MWAN_IPsec_Tun1"
+2023-08-01 09:27:26 id=20085 trace_id=2872 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface MWAN_IPsec_Tun1, tun_id=0.0.0.0"
+2023-08-01 09:27:26 id=20085 trace_id=2872 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel MWAN_IPsec_Tun1"
+2023-08-01 09:27:26 id=20085 trace_id=2872 func=esp_output4 line=844 msg="IPsec encrypt/auth"
+2023-08-01 09:27:26 id=20085 trace_id=2872 func=ipsec_output_finish line=544 msg="send to 172.71.91.34 via intf-wan1"
+```
+
+### Disable Flow Debugging
+
+The typical use of `CTR + C` will not stop Flow Debugging.
+
+You can disable Flow Debugging simply by typing the following at any point while the debug logs are scrolling by:
+
+```txt
+fortigate # diagnose debug disable
+```
diff --git a/src/content/partials/networking-services/magic-wan/third-party/google.mdx b/src/content/partials/networking-services/magic-wan/third-party/google.mdx
new file mode 100644
index 00000000000000..d848b6997b0ea0
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/google.mdx
@@ -0,0 +1,99 @@
+---
+params:
+ - productName
+ - addTunnelsUrl
+ - createAStaticRouteUrl
+---
+
+This tutorial provides information and examples of how to configure IPsec VPN between Cloudflare {props.productName} with a GCP Cloud VPN.
+
+## Prerequisites
+
+You need to have a GCP VPN gateway created in your GCP account. This is needed to route traffic between your GCP virtual private cloud (VPC) and Cloudflare {props.productName}. Refer to the [GCP documentation](https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-static-vpns) to learn more about creating a Cloud VPN gateway.
+
+A Classic VPN Gateway is required to support static routing. Route tables will also need to be manually configured to allow the routing between the VPN and Cloudflare {props.productName} to work. Refer to [GCP routing options](https://cloud.google.com/network-connectivity/docs/vpn/concepts/choosing-networks-routing#ts-tun-routing) to learn more about GCP VPC routing.
+
+## Google Cloud Platform
+
+### Create a GCP Cloud VPN Gateway
+
+1. Go to **Network Connectivity** > **VPN**.
+2. Select the **Cloud VPN Gateways** tab > **Create VPN Gateway**.
+3. Give your gateway a descriptive name.
+4. Choose the network you want to connect to with this Cloud VPN Gateway (VPC).
+5. Select a region where this Cloud VPN Gateway should be located.
+6. Choose **IPv4** as the IP traffic type that will flow through this Gateway.
+
+:::note
+Cloudflare {props.productName} does not yet support private routing via IPv6.
+:::
+
+### Configure the VPN connection
+
+1. Go to **Network Connectivity** > **VPN**.
+2. Select the **Cloud VPN Tunnels** tab > **Create VPN Tunnel**.
+3. Select the VPN Gateway you have created > **Continue**.
+4. Give your tunnel a descriptive name.
+5. For **Remote Peer IP Address**, use one of the public anycast {props.productName} IPs given to you by your account team.
+6. In **IKE version**, select **IKEv2**.
+7. You can generate an IKE pre-shared key, or add one you already own. If you generate one during this set up, keep it somewhere safe since you will need it in other steps to finish setting up {props.productName} and GCP.
+8. Choose **Route-based** as routing option.
+9. In **Remote network IP range** define the network you are going to expose to GCP via Cloudflare {props.productName}.
+
+:::note
+You can add new IP ranges once the VPN object is created. They will need to be created as VPC routes using this VPN connection (refer to the **Static Routes** section).
+:::
+
+10. Repeat the same process using your second Cloudflare anycast IP.
+
+### Static Routes
+
+Static routing is necessary to route traffic between your VPN and Cloudflare {props.productName}. Follow these steps to create them for your VPC. Refer to [VPN route documentation](https://cloud.google.com/vpc/docs/routes) to learn more about VPN routing.
+
+1. Go to **VPN Network** > **Routes**.
+2. Select **Route Management**.
+3. Create a route.
+4. Choose the VPC network you want to use for that route.
+5. In **Route type** select **Static Routing**.
+6. In **IP Version** select **IPv4**.
+7. Configure the network you want to expose to your VPN in the **Destination IPv4 Range**.
+8. Choose a priority for your static route.
+9. (Optional) You can link that route to a specific instance tag, so only impacted instances will use that route.
+10. In **Next hop** select the VPN tunnel you created previously.
+11. Select **Create**.
+
+## {props.productName}
+
+After configuring the Cloud VPN gateway VPN and the tunnels as mentioned above, go to the Cloudflare dashboard and create the corresponding IPsec tunnels and static routes on the {props.productName} side.
+
+### IPsec tunnels
+
+1. Refer to Add tunnels to learn how to add an IPsec tunnel. When creating your IPsec tunnel, make sure you define the following settings:
+ - **Tunnel name**: `tunnel01`
+ - **Interface address**: The IPsec tunnel inner `/30`CIDR block. For example, `169.254.244.2`.
+ - **Customer endpoint**: The IP address from GCP VPN tunnel outside IP address. For example, `35.xx.xx.xx`.
+ - **Cloudflare endpoint**: Enter the first of your two anycast IPs.
+ - **Pre-shared key**: Choose **Use my own pre-shared key**, and enter the PSK you created for the GCP VPN tunnel.
+ - **Health check type**: Choose **Reply**
+ - **Health check destination**: Choose **custom** and set the IP corresponding to the interface address for the tunnel
+ - **Health check direction**: Choose **Bidirectional**
+ - **Replay protection**: Select **Enabled**.
+2. Select **Save**.
+3. Repeat the above steps for `tunnel02`. Chose the same prefix, but select the second IPsec tunnel for **Tunnel/Next hop**.
+
+:::note
+Do not forget to create a route in the corresponding GCP VPC covering for the healthcheck configuration of the tunnel. The route subnet should match the interface address CIDR of the {props.productName} tunnel (`169.254.244.2` in the example above).
+
+Refer to the **Static Routes** section for more detail on how to create a VPC route leading to your newly created tunnel.
+:::
+
+### Static routes
+
+The static route in {props.productName} should point to the appropriate virtual machine (VM) subnet you created inside your GCP virtual private cloud. For example, if your VM has a subnet of `192.168.192.0/26`, you should use it as the prefix for your static route.
+
+To create a static route:
+
+1. Refer to Create a static route to learn how to create one.
+2. In **Prefix**, enter the subnet for your VM. For example, `192.xx.xx.xx/24`.
+3. For the **Tunnel/Next hop**, choose the IPsec tunnel you created in the previous step.
+4. Repeat the steps above for the second IPsec tunnel you created.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/index.mdx b/src/content/partials/networking-services/magic-wan/third-party/index.mdx
new file mode 100644
index 00000000000000..d7e1bca412947f
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/index.mdx
@@ -0,0 +1,7 @@
+---
+{}
+---
+
+import { DirectoryListing } from "~/components"
+
+
\ No newline at end of file
diff --git a/src/content/partials/networking-services/magic-wan/third-party/juniper.mdx b/src/content/partials/networking-services/magic-wan/third-party/juniper.mdx
new file mode 100644
index 00000000000000..544f2fecedd59d
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/juniper.mdx
@@ -0,0 +1,807 @@
+---
+params:
+ - productName
+ - creatingTheIpsecTunnelsUrl
+ - magicStaticRoutesUrl
+ - equalcostMultipathUrl
+ - phase1ConfigurationParametersUrl
+ - phase2ConfigurationParametersUrl
+ - antireplayUrl
+---
+
+This tutorial provides information and examples of how to configure Juniper Networks SRX Series Firewalls with {props.productName}.
+
+The configuration settings in this document are based on JUNOS 23.4R2.13.
+
+## Prerequisites
+
+Confirm that you have two Cloudflare anycast IPs allocated to your account. You will establish IPsec tunnels to the two anycast IPs irrespective of the location of your Juniper SRX devices (from now on referred to as endpoint) — traffic will be naturally attracted to the closest Cloudflare colocation facility via BGP anycast.
+
+Cloudflare recommends that customers configure two IPsec tunnels (one to each of the two anycast IPs allocated to you Cloudflare account) per Internet service provider per endpoint. This provides tunnel redundancy.
+
+Equal-cost multi-path routing (ECMP) ensures traffic is load-balanced across the tunnels, and you can control traffic steering across the tunnels through route prioritization.
+
+Cloudflare supports route-based site-to-site IPsec tunnels, which require the creation of virtual tunnel interfaces (VTIs). We recommend you select one subnet per Magic IPsec tunnel with either a `/30` or `/31` netmask.
+
+Using a `/31` netmask is a more efficient use of IP addresses as it doubles the number of available subnets compared to a `/30`netmask. This is possible because with a `/31`netmask there is no need to reserve IP addresses for the subnet and broadcast addresses, as there would be if you opt to use a `/30` netmask. Additional details can be found in [RFC 3021 - Using 31-Bit Prefixes on IPv4 Point-to-Point Links](https://datatracker.ietf.org/doc/html/rfc3021).
+
+## Cloudflare {props.productName} configuration
+
+This section of the document will cover the configuration of:
+
+- Magic IPsec tunnels
+- Magic static routes
+
+### {props.productName} topology
+
+This documentation assumes there are two locations connected via {props.productName}:
+
+| Site | Local/Remote | Security Zone | Subnet |
+| ---- | ------------ | ------------- | ------------- |
+| A | Local | trust | `10.1.20.0/24` |
+| B | Remote | Cloudflare | `10.1.100.0/24` |
+
+### Magic IPsec tunnels
+
+1. Start by creating the IPsec tunnels in the Cloudflare dashboard with the following values:
+ - **Tunnel name**: Up to 15 characters (no spaces).
+ - **Description** (Optional).
+ - **Interface address**: This is the Virtual Tunnel Interface (VTI = `st0.x`) RFC 1918 address — the IP address specified in this dialog box is the address on the Cloudflare side of the tunnel.
+ - **Customer endpoint**: Specify the Internet IP address on the untrust side of the SRX firewall.
+ - **Cloudflare endpoint**: One of the two Cloudflare anycast IP addresses.
+ - **Pre-shared key**: Choose **Add pre-shared key later**.
+2. Select **Add IPsec Tunnel** and fill in the values for the second tunnel to the same Juniper SRX:
+ - Ensure you use a unique RFC 1918 IP address for the Interface Address (`/31` or `/30`).
+ - Once again, specify the Internet IP address on the untrust side of the SRX firewall for the **Customer Endpoint**.
+ - The **Cloudflare Endpoint** for the second tunnel will be the second Cloudflare anycast IP provisioned for your account.
+3. Select **Add Tunnels**. We also recommend selecting **Test Tunnels** to ensure that the settings do not conflict with any other tunnels defined in your account and that you specified the correct anycast IP addresses.
+4. You will see a warning indicator next to the tunnel names after creating them because we chose to add a pre-shared key later. This is expected behavior and indicates that a pre-shared key has not been generated yet for the associated tunnel.
+5. Select **Edit** next to one of the tunnels to generate a pre-shared key.
+6. Select **Generate a new pre-shared key** > **Update and generate a pre-shared key**. Make a note of the pre-shared key and store it somewhere safe.
+ :::note
+ You can update the pre-shared key at any time by repeating this step. Just make sure to add the new value of the new pre-shared key to the corresponding tunnel configuration on the Juniper device.
+ :::
+7. Repeat the previous step for the second tunnel.
+8. Expand the first tunnel's properties and note the **Tunnel ID** and **FQDN ID** values.
+9. Repeat the previous steps for the second tunnel.
+ :::note
+ The **Tunnel ID** and **FQDN ID** values are unique per tunnel and remain unchanged unless you delete and recreate the tunnel. Generating a new Pre-Shared Key will not change the values.
+ :::
+
+### Magic static routes
+
+Refer to the {props.productName} Topology section above for more details on the IP subnet scheme.
+
+Magic static routes effectively tell {props.productName} which tunnels to route traffic destined for a given {props.productName} site.
+
+Since two tunnels are configured to each endpoint, it is necessary to configure two static routes.
+
+Cloudflare leverages equal-cost multi-path routing to control traffic steering across the tunnels. The default priority for each route is 100 — traffic will be load-balanced across the two tunnels equally via ECMP. You can modify the priorities as needed, however best practices dictate leaving the default values in place.
+
+1. Create a static route with the following values. Make sure you select the first tunnel in **Tunnel/Next hop**:
+ - **Description:** The description for the static route assigned to your first tunnel.
+ - **Prefix**: Enter the destination subnet for which this route is intended. For this example, it is `10.1.20.0/24` as stated above.
+ - **Tunnel/Next hop**: Choose your first tunnel from the drop-down menu.
+ - **Priority**: The default value is `100`.
+ - **Region code**: Leave set to **All Regions** unless otherwise specified.
+2. Select **Add Static Route** to add a second route for the same subnet. Make sure the second tunnel is selected in **Tunnel/Next hop**.
+3. Select **Test Routes** to ensure the settings are accepted, then select **Add Routes**.
+4. Confirm the routes were added correctly in **{props.productName}** > **Configuration** > **Static Routes**.
+
+## Juniper SRX configuration
+
+There may be some differences in the syntax of the commands in the version on your SRX devices. However, the principles are the same. Refer to the Juniper product documentation for more information.
+
+The interface naming convention for VTI interfaces (also known as Secure Tunnel Interfaces) in Junos is `st0.x`.
+
+[Secure Tunnel Interface in a Virtual Router - Juniper IPsec VPN User Guide](https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-secure-tunnel-interface-in-a-virtual-router.html)
+
+The following elements will be configured on the Juniper SRX firewall(s):
+
+- Ensure the LAN interface is in the `trust` zone
+- Add virtual tunnel Interfaces (`st0.0` and `st0.1`)
+- Assign tunnel interfaces to the `cloudflare` security zone
+- Allow required protocols to both the tunnel and untrust security zones
+- IKE configuration
+- IPsec configuration
+- Policy-based routing (filter-based forwarding)
+- Security policies
+
+### Tunnel interfaces
+
+1. Add two tunnel interfaces:
+
+```txt
+set interfaces st0 unit 0 family inet address 10.252.2.21/31
+set interfaces st0 unit 1 family inet address 10.252.2.23/31
+```
+
+```txt
+admin@srx300> show configuration interfaces st0
+```
+```txt output
+unit 0 {
+ family inet {
+ address 10.252.2.21/31;
+ }
+}
+unit 1 {
+ family inet {
+ address 10.252.2.23/31;
+ }
+}
+```
+
+### Security Zone (Cloudflare) - tunnel interfaces
+
+Define a security zone and add both tunnel interfaces to it. At a minimum, the interfaces should allow `ping`, but this zone only contains point-to-point connections between the firewall and the customer network namespace. Setting it to `all` for system-services and protocols should be fine.
+
+```txt
+set security zones security-zone cloudflare interfaces st0.0 host-inbound-traffic system-services all
+set security zones security-zone cloudflare interfaces st0.0 host-inbound-traffic
+set security zones security-zone cloudflare interfaces st0.1 host-inbound-traffic system-services all
+set security zones security-zone cloudflare interfaces st0.1 host-inbound-traffic
+```
+
+```txt
+admin@srx220> show configuration security zones security-zone cloudflare
+```
+```txt output
+interfaces {
+ st0.0 {
+ host-inbound-traffic {
+ system-services {
+ all;
+ }
+ protocols {
+ all;
+ }
+ }
+ }
+ st0.1 {
+ host-inbound-traffic {
+ system-services {
+ all;
+ }
+ protocols {
+ all;
+ }
+ }
+ }
+}
+```
+
+### Security zone (untrust) - `host-inbound-traffic`
+
+Add `ping` and `ike` to the security zone containing the external interface used to establish the IPsec tunnels to Cloudflare.
+
+```txt
+set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ike
+```
+
+```txt
+admin@srx300> show configuration security zones security-zone untrust
+```
+```txt output
+screen untrust-screen;
+interfaces {
+ ge-0/0/0.0 {
+ host-inbound-traffic {
+ system-services {
+ ike;
+ }
+ }
+ }
+}
+```
+
+### IKE - Phase 1
+
+#### IKE proposal
+
+Add an IKE proposal that specifies the Phase 1 Configuration Parameters:
+
+```txt
+set security ike proposal cf_magic_wan_ike_prop authentication-method pre-shared-keys
+set security ike proposal cf_magic_wan_ike_prop dh-group group20
+set security ike proposal cf_magic_wan_ike_prop authentication-algorithm sha-256
+set security ike proposal cf_magic_wan_ike_prop encryption-algorithm aes-256-cbc
+set security ike proposal cf_magic_wan_ike_prop lifetime-seconds 86400
+```
+
+```txt
+admin@srx300> show configuration security ike proposal cf_magic_wan_ike_prop
+```
+```txt output
+authentication-method pre-shared-keys;
+dh-group group20;
+authentication-algorithm sha-256;
+encryption-algorithm aes-256-cbc;
+lifetime-seconds 86400;
+```
+
+#### IKE policies
+
+Define two IKE policies - one for each of the two Magic IPsec tunnels:
+
+***Tunnel 1 (SRX300_IPSEC_01)**
+
+```txt
+set security ike policy cf_magic_wan_tun_01_pol mode main
+set security ike policy cf_magic_wan_tun_01_pol proposals cf_magic_wan_ike_prop
+set security ike policy cf_magic_wan_tun_01_pol pre-shared-key ascii-text "$9$GRjPTFWZUjHPT"
+```
+
+```txt
+admin@srx300> show configuration security ike policy cf_magic_wan_tun_01_pol
+```
+```txt output
+mode main;
+proposals cf_magic_wan_ike_prop;
+pre-shared-key ascii-text "$9$GRjPTFWZUjHPT"; ## SECRET-DATA
+```
+
+**Tunnel 2 (SRX300_IPSEC_02)**
+
+```txt
+set security ike policy cf_magic_wan_tun_02_pol mode main
+set security ike policy cf_magic_wan_tun_02_pol proposals cf_magic_wan_ike_prop
+set security ike policy cf_magic_wan_tun_02_pol pre-shared-key ascii-text "$9$f536tpSrH.fT/9Lx7-bY"
+```
+
+```txt
+admin@srx300> show configuration security ike policy cf_magic_wan_tun_02_pol
+```
+```txt output
+mode main;
+proposals cf_magic_wan_ike_prop;
+pre-shared-key ascii-text "$9$f536tpSrH.fT/9Lx7-bY"; ## SECRET-DATA
+```
+
+#### IKE gateways
+
+Define two IKE gateways — one for each of the two Magic IPsec tunnels. In the examples below, note the use of the **FQDN ID** value obtained from the Cloudflare dashboard in the `local-identity` hostname setting.
+
+**Tunnel 1 (SRX300_IPSEC_01)**
+
+```txt
+set security ike gateway cf_magic_wan_gw_tun_01 ike-policy cf_magic_wan_tun_01_pol
+set security ike gateway cf_magic_wan_gw_tun_01 address 162.159.68.68
+set security ike gateway cf_magic_wan_gw_tun_01 local-identity hostname 1663e5e706555.ipsec.cloudflare.com
+set security ike gateway cf_magic_wan_gw_tun_01 external-interface ge-0/0/0.0
+set security ike gateway cf_magic_wan_gw_tun_01 version v2-only
+```
+
+```txt
+admin@srx300> show configuration security ike gateway cf_magic_wan_gw_tun_01
+```
+```txt output
+ike-policy cf_magic_wan_tun_01_pol;
+address 162.159.68.68;
+local-identity hostname 1663e5e706555.ipsec.cloudflare.com;
+external-interface ge-0/0/0.0;
+version v2-only;
+```
+
+**Tunnel 2 (SRX300_IPSEC_02)**
+
+```txt
+set security ike gateway cf_magic_wan_gw_tun_02 ike-policy cf_magic_wan_tun_02_pol
+set security ike gateway cf_magic_wan_gw_tun_02 address 172.64.244.68
+set security ike gateway cf_magic_wan_gw_tun_02 local-identity hostname b5ee53036555.ipsec.cloudflare.com
+set security ike gateway cf_magic_wan_gw_tun_02 external-interface ge-0/0/0.0
+set security ike gateway cf_magic_wan_gw_tun_02 version v2-only
+```
+
+```txt
+admin@srx300> show configuration security ike gateway cf_magic_wan_gw_tun_02
+```
+```txt output
+ike-policy cf_magic_wan_tun_02_pol;
+address 172.64.244.68;
+local-identity hostname b5ee53036555.ipsec.cloudflare.com;
+external-interface ge-0/0/0.0;
+version v2-only;
+```
+
+### Phase 2 - IPsec
+
+#### IPsec proposal
+
+Add an IPsec proposal that specifies the Phase 2 Configuration Parameters:
+
+```txt
+set security ipsec proposal cf_magic_wan_ipsec_prop protocol esp
+set security ipsec proposal cf_magic_wan_ipsec_prop authentication-algorithm hmac-sha-256-128
+set security ipsec proposal cf_magic_wan_ipsec_prop encryption-algorithm aes-256-cbc
+set security ipsec proposal cf_magic_wan_ipsec_prop lifetime-seconds 28800
+```
+
+```txt
+admin@srx300> show configuration security ipsec proposal cf_magic_wan_ipsec_prop
+```
+```txt output
+protocol esp;
+authentication-algorithm hmac-sha-256-128;
+encryption-algorithm aes-256-cbc;
+lifetime-seconds 28800;
+```
+
+#### IPsec Policy
+
+Define one IPsec policy — reference the IPsec proposal created above.
+
+```txt
+set security ipsec policy cf_magic_wan_ipsec_pol proposals cf_magic_wan_ipsec_prop
+```
+
+```txt
+admin@srx300> show configuration security ipsec policy cf_magic_wan_ipsec_pol
+```
+```txt output
+proposals cf_magic_wan_ipsec_prop;
+```
+
+#### IPsec VPN tunnels
+
+Define two IPsec policies - one for each of the two Magic IPsec tunnels. It is crucial to ensure that:
+
+- Anti-replay protection is disabled.
+ - Use the [`no-anti-replay`](https://www.juniper.net/documentation/us/en/software/junos/interfaces-adaptive-services/topics/ref/statement/no-anti-replay-edit-services.html) option.
+- The SRX is the tunnel initiator:
+ - Cloudflare will not instantiate the tunnel
+ - If the SRX does not initiate the tunnel, then the tunnel will not be established until there is an attempt to connect to resources through the tunnel
+ - Use [`establish-tunnels immediately`](https://www.juniper.net/documentation/us/en/software/junos/interfaces-adaptive-services/topics/ref/statement/establish-tunnels-edit-services-ipsec-vpn.html) to ensure the SRX is the tunnel initiator.
+
+**VPN Tunnel 1 (cf_magic_wan_ipsec_tun_01)**
+
+```txt
+set security ipsec vpn cf_magic_wan_ipsec_tun_01 bind-interface st0.0
+set security ipsec vpn cf_magic_wan_ipsec_tun_01 ike gateway cf_magic_wan_gw_tun_01
+set security ipsec vpn cf_magic_wan_ipsec_tun_01 ike no-anti-replay
+set security ipsec vpn cf_magic_wan_ipsec_tun_01 ike ipsec-policy cf_magic_wan_ipsec_pol
+set security ipsec vpn cf_magic_wan_ipsec_tun_01 establish-tunnels immediately
+```
+
+```txt
+admin@srx300> show configuration security ipsec vpn cf_magic_wan_ipsec_tun_01
+```
+```txt output
+bind-interface st0.0;
+ike {
+ gateway cf_magic_wan_gw_tun_01;
+ no-anti-replay;
+ ipsec-policy cf_magic_wan_ipsec_pol;
+}
+establish-tunnels immediately;
+```
+
+**VPN Tunnel 2 (cf_magic_wan_ipsec_tun_02)**
+
+```txt
+set security ipsec vpn cf_magic_wan_ipsec_tun_02 bind-interface st0.1
+set security ipsec vpn cf_magic_wan_ipsec_tun_02 ike gateway cf_magic_wan_gw_tun_02
+set security ipsec vpn cf_magic_wan_ipsec_tun_02 ike no-anti-replay
+set security ipsec vpn cf_magic_wan_ipsec_tun_02 ike ipsec-policy cf_magic_wan_ipsec_pol
+set security ipsec vpn cf_magic_wan_ipsec_tun_02 establish-tunnels immediately
+```
+
+```txt
+admin@srx300> show configuration security ipsec vpn cf_magic_wan_ipsec_tun_02
+```
+```txt output
+bind-interface st0.1;
+ike {
+ gateway cf_magic_wan_gw_tun_02;
+ no-anti-replay;
+ ipsec-policy cf_magic_wan_ipsec_pol;
+}
+establish-tunnels immediately;
+```
+
+### Policy-Based Routing
+
+The SRX platform provides policy-based routing functionality, which Juniper refers to as [filter-based forwarding](https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/concept/firewall-filter-option-filter-based-forwarding-overview.html).
+
+Filter-based forwarding is implemented by configuring the following:
+
+1. **Routing Instance**: Specify the routing table(s) to which a packet is forwarded and the destination to which the packet is forwarded at the [edit routing-instances] hierarchy level.
+2. **Firewall Filter**: Use a stateless firewall filter to specify the source and destination addresses in conjunction with a routing instance that forwards traffic across the Magic IPsec tunnels, then bind the firewall filter to the ingress interface (trust zone).
+3. **RIB Group**: Share interface routes with the forwarding routing instances used in filter-based forwarding (FBF).
+
+:::note
+Firewall filters must incorporate at least two terms:
+
+- **Term 1**: Classify the traffic to forward to {props.productName}
+- **Term 2**: Permit all other traffic — otherwise, the firewall filters will discard any traffic not intended for {props.productName} destinations.
+:::
+
+This configuration only factors in one local site (`10.1.20.0/24`). In this example, we assume devices in the trust zone must route traffic to a remote subnet at another {props.productName}-protected site (`10.1.100.0/24`).
+
+Define a static route on the SRX to route traffic to `10.1.100.0/24` with redundant routes referencing each of the two tunnels.
+
+**Routing Instance:**
+
+[Routing Instances](https://www.juniper.net/documentation/us/en/software/junos/routing-overview/topics/concept/routing-instances-overview.html) effectively add additional routing tables to the SRX platform.
+
+As mentioned earlier, any traffic destined for other {props.productName} protected sites must be routed over the Magic IPsec tunnels.
+
+The example includes two static routes - one to each of the two VTIs on the Cloudflare side of the Magic IPsec Tunnels (`10.252.2.20` and `10.252.2.22`).
+
+While it is possible to be more prescriptive in terms of the destination subnets, we simply use `0.0.0.0/0` as the firewall filter ensures only traffic destined for `10.1.100.0/24` will be forwarded to the routing instance. Any other traffic not destined for `10.1.100.0/24` will continue to the primary routing table (`inet.0`) as it falls outside the scope of the firewall filter configured in the next section below.
+
+Leaving the destination subnet as `0.0.0.0/0` eases some administrative burden as you only need to modify the firewall filter to specify which traffic is destined for {props.productName}.
+
+```txt
+set routing-instances MAGIC_WAN_RI instance-type forwarding
+set routing-instances MAGIC_WAN_RI routing-options static route 0.0.0.0/0 next-hop 10.252.2.20
+set routing-instances MAGIC_WAN_RI routing-options static route 0.0.0.0/0 next-hop 10.252.2.22
+```
+
+```txt
+admin@srx300> show configuration routing-instances
+```
+```txt output
+MAGIC_WAN_RI {
+ instance-type forwarding;
+ routing-options {
+ static {
+ route 0.0.0.0/0 next-hop [ 10.252.2.20 10.252.2.22 ];
+ }
+ }
+}
+```
+
+**Firewall Filter:**
+
+In this step, we create a stateless firewall filter to ensure only packets from `10.1.20.0/24` destined for `10.1.100.0/24` are sent to the `MAGIC_WAN_RI` routing instance.
+
+- **Term 1** - `MAGIC_WAN_NETS` ensures only packets from `10.1.20.0/24` destined for `10.1.100.0/24` are sent to the `MAGIC_WAN_RI` routing instance. Take note of the `count` statement defined in this term. [Count](https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/example/firewall-filter-stateless-example-act-on-sampling.html) allows you to view how many packets are processed by this term in the firewall filter. An example of how to view the Counter is included below.
+- **Term 2** - `ALLOW_EVERYTHING_ELSE` ensures all other traffic continues to the primary routing table (`inet.0`).
+
+```txt
+set firewall family inet filter MAGIC_WAN_FBF term MAGIC_WAN_NETS from source-address 10.1.20.0/24
+set firewall family inet filter MAGIC_WAN_FBF term MAGIC_WAN_NETS from destination-address 10.1.100.0/24
+set firewall family inet filter MAGIC_WAN_FBF term MAGIC_WAN_NETS then count MAGIC_WAN_GATEWAY_FBF_count
+set firewall family inet filter MAGIC_WAN_FBF term MAGIC_WAN_NETS then routing-instance MAGIC_WAN_RI
+set firewall family inet filter MAGIC_WAN_FBF term ALLOW_EVERYTHING_ELSE then accept
+```
+
+```txt
+admin@srx300> show configuration firewall
+```
+```txt output
+family inet {
+ filter MAGIC_WAN_FBF {
+ term MAGIC_WAN_NETS {
+ from {
+ source-address {
+ 10.1.20.0/24;
+ }
+ destination-address {
+ 10.1.100.0/24;
+ }
+ }
+ then {
+ count MAGIC_WAN_FBF_count;
+ routing-instance MAGIC_WAN_RI;
+ }
+ }
+ term ALLOW_EVERYTHING_ELSE {
+ then accept;
+ }
+ }
+}
+```
+
+**View Firewall Filter Counters**
+
+To view the firewall filter counter:
+
+```txt
+admin@srx300> show firewall filter MAGIC_WAN_FBF counter MAGIC_WAN_FBF_count
+```
+```txt output
+Filter: MAGIC_WAN_FBF
+
+Counters:
+
+Name Bytes Packets
+MAGIC_WAN_FBF_count 760174478 1940954
+```
+
+**Bind Firewall Filter to the interface in the** **trust** **zone:**
+
+```txt
+set interfaces ge-0/0/7 unit 0 family inet filter input MAGIC_WAN_FBF
+set interfaces ge-0/0/7 unit 0 family inet address 10.1.20.1/24
+```
+
+```txt
+admin@srx300> show configuration interfaces ge-0/0/7 unit 0
+```
+```txt output
+family inet {
+ filter {
+ input MAGIC_WAN_FBF;
+ }
+ address 10.1.20.1/24;
+}
+```
+
+**RIB Group:**
+
+RIB Groups allow you to concatenate the contents of multiple routing tables into a routing table group.
+
+The primary routing table in the RIB group should be `inet.0` followed by the secondary routing table `MAGIC_WAN_RI.inet.0` which is the `MAGIC_WAN_RI` routing-instance created above.
+
+[Interface Routes](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/interface-routes-edit-routing-options.html) referenced below by the `interface-routes` statement determines which interfaces and Routing Instances are bound to the RIB Group.
+
+```txt
+set routing-options static route 0.0.0.0/0 next-hop
+set routing-options rib-groups MAGIC_WAN_RG import-rib [ inet.0 MAGIC_WAN_RI.inet.0 ]
+set routing-options interface-routes rib-group inet MAGIC_WAN_RG
+set routing-options interface-routes rib-group inet MAGIC_WAN_RG
+```
+
+```txt
+admin@srx300> show configuration routing-options
+```
+```txt output
+interface-routes {
+ rib-group inet MAGIC_WAN_GW_RG;
+}
+static {
+ route 0.0.0.0/0 next-hop ;
+}
+rib-groups {
+ MAGIC_WAN_GW_RG {
+ import-rib [ inet.0 MAGIC_WAN_RI.inet.0 ];
+ }
+}
+```
+
+### Security policies
+
+Define security policies to permit traffic flows destined for {props.productName}-protected resources. The source/destination zones must incorporate the zone containing the tunnel interfaces.
+
+There are two very simple rules to allow traffic bidirectionally — it is generally recommended to start with a similar policy and then add more stringent rules once general connectivity is established successfully.
+
+**From Zone:** *Cloudflare* **To Zone:** *trust*
+
+```txt
+set security policies from-zone cloudflare to-zone trust policy cloudflare_to_trust match source-address any
+set security policies from-zone cloudflare to-zone trust policy cloudflare_to_trust match destination-address any
+set security policies from-zone cloudflare to-zone trust policy cloudflare_to_trust match application any
+set security policies from-zone cloudflare to-zone trust policy cloudflare_to_trust then permit
+set security policies from-zone cloudflare to-zone trust policy cloudflare_to_trust then log session-close
+```
+
+```txt
+admin@srx300> show configuration security policies from-zone cloudflare to-zone trust
+```
+```txt output
+policy cloudflare_to_trust_permit {
+ match {
+ source-address any;
+ destination-address any;
+ application any;
+ }
+ then {
+ permit;
+ log {
+ session-close;
+ }
+ }
+}
+```
+
+**From Zone:** *trust* **To Zone:** *Cloudflare*
+
+```txt
+set security policies from-zone trust to-zone cloudflare policy trust_to_cloudflare_permit match source-address any
+set security policies from-zone trust to-zone cloudflare policy trust_to_cloudflare_permit match destination-address any
+set security policies from-zone trust to-zone cloudflare policy trust_to_cloudflare_permit match application any
+set security policies from-zone trust to-zone cloudflare policy trust_to_cloudflare_permit then permit
+set security policies from-zone trust to-zone cloudflare policy trust_to_cloudflare_permit then log session-close
+```
+
+```txt
+admin@srx300> show configuration security policies from-zone trust to-zone cloudflare
+```
+```txt output
+policy trust_to_cloudflare_permit {
+ match {
+ source-address any;
+ destination-address any;
+ application any;
+ }
+ then {
+ permit;
+ log {
+ session-close;
+ }
+ }
+}
+```
+
+## Troubleshooting
+
+### Validate tunnel connectivity
+
+There are several diagnostic commands available to view the status of IPsec tunnels.
+
+#### Ping across virtual tunnel interfaces
+
+Use ping to test connectivity from the SRX side of the tunnel to the Cloudflare side of the tunnel. Ensure you use the source option to specify the IP address associated with tunnel interfaces `st0.0` and `st0.1`, respectively:
+
+**Tunnel 1** - `st0.0 - 10.252.2.21`
+
+```txt
+admin@srx300> ping source 10.252.2.21 10.252.2.20
+```
+```txt output
+PING 10.252.2.20 (10.252.2.20): 56 data bytes
+64 bytes from 10.252.2.20: icmp_seq=0 ttl=64 time=8.429 ms
+64 bytes from 10.252.2.20: icmp_seq=1 ttl=64 time=4.134 ms
+64 bytes from 10.252.2.20: icmp_seq=2 ttl=64 time=4.028 ms
+64 bytes from 10.252.2.20: icmp_seq=3 ttl=64 time=3.855 ms
+64 bytes from 10.252.2.20: icmp_seq=4 ttl=64 time=3.811 ms
+```
+
+**Tunnel 2** - `st0.1 - 10.252.2.23`
+
+```txt
+admin@srx300> ping source 10.252.2.23 10.252.2.22
+```
+```txt output
+PING 10.252.2.22 (10.252.2.22): 56 data bytes
+
+64 bytes from 10.252.2.22: icmp_seq=0 ttl=64 time=7.405 ms
+64 bytes from 10.252.2.22: icmp_seq=1 ttl=64 time=3.685 ms
+64 bytes from 10.252.2.22: icmp_seq=2 ttl=64 time=3.666 ms
+64 bytes from 10.252.2.22: icmp_seq=3 ttl=64 time=3.888 ms
+64 bytes from 10.252.2.22: icmp_seq=4 ttl=64 time=3.814 ms
+```
+
+#### Phase 1 - View Active Peers
+
+[`show security ike active-peer`](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-security-ike-active-peer.html)
+
+```txt
+admin@srx300> show security ike active-peer
+```
+```txt output
+Remote Address Port Peer IKE-ID XAUTH username Assigned IP
+162.XXX.XX.164 500 162.XX.XXX.164 not available 0.0.0.0
+172.XX.XXX.164 500 172.XX.XXX.164 not available 0.0.0.0
+```
+
+#### Phase 1 - View IKE Security Associations
+
+[`show security ike security-associations`](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-security-ike-security-associations.html)
+
+```txt
+admin@srx300> show security ike security-associations
+```
+```txt output
+Index State Initiator cookie Responder cookie Mode Remote Address
+3628774 UP 51078ae37b319d23 1475e3b48ca89a9a IKEv2 162.XXX.XX.164
+3628775 UP b2d9a698b6224fc9 7fb1a9f81db0611c IKEv2 172.XX.XXX.164
+```
+
+#### Phase 2 - View IPsec Security Associations
+
+[`show security ipsec security-associations`](https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/ref/command/show-security-ipsec-security-associations.html)
+
+```txt
+admin@srx300> show security ipsec security-associations
+```
+```txt output
+Total active tunnels: 2
+ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
+<131073 ESP:aes-cbc-256/sha256 d28e709e 28565/unlim - root 500 162.XXX.66.164
+>131073 ESP:aes-cbc-256/sha256 25aed8ae 28565/unlim - root 500 162.XXX.XX.164
+<131074 ESP:aes-cbc-256/sha256 3f13176d 28566/unlim - root 500 172.XX.XXX.164
+>131074 ESP:aes-cbc-256/sha256 965169e9 28566/unlim - root 500 172.XX.XXX.164
+```
+
+### IKE `traceoptions`
+
+It can be very helpful to enable debug logging via traceoptions while setting up the tunnels. The log data can help determine if there are issues and, if so, where they might be occurring.
+
+Please note that some errors in the log are benign. The types of errors to look for are those related to authentication or encryption/integrity (that is, no proposal chosen).
+
+#### Enable IKE `traceoptions`
+
+[traceoptions (Security IKE)](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-traceoptions-ike.html)
+
+```txt
+set security ike traceoptions file ike-debug.log
+set security ike traceoptions file size 1m
+set security ike traceoptions file files 3
+set security ike traceoptions file world-readable
+set security ike traceoptions flag all
+```
+
+The log file can be viewed by doing the following:
+
+1. From an operational mode, run **start shell**.
+2. Use the `tail` command to view the contents of the log file in real-time:
+
+ ```txt
+ tail -f /var/log/ike-debug.log
+ ```
+
+3. Press `CTRL + C` when finished.
+4. Type `exit` to return to the operational mode prompt.
+
+Either deactivate `traceoptions` or delete `traceoptions` once debugging is complete.
+
+#### Deactivate IKE `traceoptions`
+
+```txt
+deactivate security ike traceoptions
+```
+
+Confirm `traceoptions` is deactivated with:
+
+```txt
+admin@srx300> show configuration security ike traceoptions
+```
+```txt output
+##
+## inactive: security ike traceoptions
+##
+file ike-debug.log size 1m files 3 world-readable;
+flag all;
+```
+
+### IPsec `traceoptions`
+
+Refer to [traceoptions (Security IPsec)](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-traceoptions-ipsec.html) for more information on this topic.
+
+#### Enable IPsec `traceoptions`
+
+```txt
+set security ipsec traceoptions file ipsec-debug.log
+set security ipsec traceoptions file size 1m
+set security ipsec traceoptions file files 3
+set security ipsec traceoptions file world-readable
+set security ipsec traceoptions flag all
+```
+
+To view the log file:
+
+1. From an operational mode, run `start shell`.
+2. Use the tail command to view the contents of the log file in real time:
+ `tail -f /var/log/ipsec-debug.log`
+3. Press `CTRL + C` when finished.
+4. Type `exit` to return to the operational mode prompt.
+
+Either deactivate `traceoptions` or delete `traceoptions` once debugging is complete.
+
+#### Delete IPsec `traceoptions`
+
+```txt
+delete security ipsec traceoptions
+```
+
+#### Deactivate IPsec `traceoptions`
+
+```txt
+deactivate security ipsec traceoptions
+```
+
+Confirm `traceoptions` is deactivated:
+
+```txt
+admin@srx300> show configuration security ipsec traceoptions
+```
+```txt output
+##
+## inactive: security ipsec traceoptions
+##
+file ipsec-debug.log size 1m files 3 world-readable;
+flag all;
+```
diff --git a/src/content/partials/networking-services/magic-wan/third-party/oracle.mdx b/src/content/partials/networking-services/magic-wan/third-party/oracle.mdx
new file mode 100644
index 00000000000000..b126330248fd70
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/oracle.mdx
@@ -0,0 +1,114 @@
+---
+params:
+ - productName
+ - addTunnelsUrl
+ - createAStaticRouteUrl
+---
+
+This tutorial provides information and examples of how to configure IPsec between Cloudflare {props.productName} and an Oracle Cloud Site-to-site VPN.
+
+## Prerequisites
+
+You need a pre-shared key to establish the IPsec tunnel. You can use the following code to create a random key:
+
+```js
+ const a = new Uint8Array(48);
+ crypto.getRandomValues(a);
+ let base64String = btoa(String.fromCharCode.apply(null, a));
+
+ base64String = base64String.replace(/\+/g, '')
+ .replace(/\//g, '')
+ .replace(/=/g, '');
+
+ console.log(base64String.substring(0, 32));
+```
+
+:::caution
+The code above is an example of how you might generate a random key. However, make sure you generate a key that is strong enough to comply with your security needs.
+:::
+
+You can try this code in the [Workers playground](https://workers.cloudflare.com/playground#LYVwNgLglgDghgJwgegGYHsHALQBM4RwDcABAEbogB2+CAngLzbPYDqApmQNJQQBimYACFKNRHSoBzAB4ArAEoBBANYR5AEVYAJAOJCAagA0AXCxYduvAVhHVaEmQpVrNug4YCwAKADC6KhDsAdjqUADOMOhhvFD+xiQYWHgExCRUcMDsDABEUDTs0gB0smHZpKhQYEEZWbn5RSXZ3n4BQRDYACp0MOzxcDAwYFAAxgSxVMiycABucGHDCLAQANTA6Ljg7N7eBZFIJLjsqHDgECQA3l4AkHMSwwnsEMMAFgAUAJQXXtdXw-5hZzgJAYaXYAHcSABVPIQAAcigQCDgdFeABZYe8iD8Ft0IOhCpJHvI4DR0MB9HAwCB2GFXnBMT8qmcyHN2AA2VEAZQgiykwPIeLgr25vMkhVQCDJPmeiD8h0K-UGKKo4DAABoSPSGT8WWF2VyeXlJPzdfqRUbCgh2IM4MN2K9kAAdZbISQagDk7vePyuvr9JADlutYFt9qdyFdHq9Pr9voDJCDNrtDoYkZInu1vr+VABCTylPNfJBpo5hbFYRAZABoteAAYNQBmABMmauVogIAQVFBEPkNMiOftFXSYDLGsufue7DghwQYXiE792WzgWCEG67Gy8WygWkKGeEGAYGyap9AF9T76zwyrhevGesd4zMwLDx+IJbGJ6FI5EpVBptD0Ixmn8Vd2lCCIohiOIEkEZJCFIdJMhyTJCHwQgyjzKokNqMgwHQMgml8UC2k6Dc+gGIZRmgfxJjCfxti8c5lzJeBoDISpeDoAB9dDN2MbIm1rJtUWwWsGzEgB2E8WOANioA4oZ1241AQ0kUpjAAbWyKh1nYEpuL+OSCGyABdNVsmAOA8m4tYNiqLc6kOBpSjPJ9n1fKwP1Eewfycf9XCAwxmG8IA).
+
+## Oracle Cloud
+
+### 1. Create Oracle Cloud customer-premises equipment
+
+1. Go to **Networking** > **Customer connectivity**, and select **Customer-premises equipment**.
+2. Select **Create CPE**.
+3. Select the following settings (you can leave settings not mentioned here with their default values):
+ - **Name**: Enter a name.
+ - **IP Address**: Enter your Cloudflare anycast IP address.
+ - **CPE vendor information**: Select **Other**.
+4. Select **Create CPE**.
+
+### 2. Create Oracle Cloud dynamic routing gateways
+
+1. Go to **Networking** > **Customer connectivity**, and select **Dynamic routing gateways**.
+2. Select **Create Dynamic routing gateways**.
+3. Select the following settings (you can leave settings not mentioned here with their default values):
+ - **Name**: Enter a name.
+4. Select **Create Dynamic routing gateways**.
+
+### 3. Create an IPsec connection
+
+1. Go to **Networking** > **Customer connectivity**, and select **Site-to-Site VPN**.
+2. Select **Create IPsec connection**.
+3. Select the following settings (you can leave settings not mentioned here with their default values):
+ - **Name**: Enter a name.
+ - **Customer-premises equipment**: Select the CPE you have created in step 1.
+ - **Dynamic routing gateways**: Select the DRG you have created in step 2.
+ - **Routes to your on-premises network**: Enter a CIDR range you want to route to {props.productName}.
+ - **Tunnel 1**
+ - **Name**: Enter a name.
+ - Select **Provide custom shared secret**.
+ - Enter the **pre-shared key** you created in the Prerequisites section.
+ - **IKE version**: **IKEv2**
+ - **Routing type**: **Static routing**
+ - **IPv4 inside tunnel interface - CPE**: Enter the internal tunnel IP on the Cloudflare side of the IPsec tunnel. In this example, it is `10.200.1.0/31`.
+ - **IPv4 inside tunnel interface - Oracle**: Enter the internal tunnel IP on the Oracle side of the IPsec tunnel. In this example, it is `10.200.1.1/31`. This matches with the Cloudflare side for this tunnel.
+ 1. Select **Show advanced options**
+ 2. Select **Phase one (ISAKMP) configuration**
+ - Select **Set custom configurations**
+ - **Custom encryption algorithm**: **AES_256_CBC**
+ - **Custom authentication algorithm**: **SHA2_256**
+ - **Custom Diffie-Hellman group**: **GROUP20**
+ - **IKE session key lifetime in seconds**: **86400**
+ 3. Select **Phase two (IPsec) configuration**
+ - Select **Set custom configurations**
+ - **Custom encryption algorithm**: **AES_256_CBC**
+ - **HMAC_SHA2_256_128**: **HMAC_SHA2_256_128**
+ - **IPsec session key lifetime in seconds**: **28800**
+ - **Perfect forward secrecy Diffie-Hellman group**: **GROUP20**
+ - **Tunnel 2**
+ - Repeat the above steps for Tunnel 2. Select the right IP for **IPv4 inside tunnel interface - CPE**: `10.200.2.0/31` and **IPv4 inside tunnel interface - Oracle**: `10.200.2.1/31`
+4. Select **Create IPsec connection**
+
+## {props.productName}
+
+After configuring the Oracle Site-to-site VPN connection and the tunnels as mentioned above, go to the Cloudflare dashboard and create the corresponding IPsec tunnel and static routes on the {props.productName} side.
+
+### IPsec tunnels
+
+1. Refer to Add tunnels to learn how to add an IPsec tunnel. When creating your IPsec tunnel, make sure you define the following settings:
+ - **Tunnel name**: Enter a name.
+ - **Interface address**: Enter the internal tunnel IP on the Cloudflare side of the IPsec tunnel. In this example, it is `10.200.1.0/31`.
+ - **Customer endpoint**: The Oracle VPN public IP address.
+ - **Cloudflare endpoint**: Enter your Cloudflare anycast IP address.
+ - **Health check type**: **Request**
+ - **Health check direction**: **Unidirectional**
+ - **Health check target**: **Default**
+ - **Pre-shared key**: Choose **Use my own pre-shared key**, and enter the pre-shared key you created in the Prerequisites section.
+ - **Replay protection**: **Enabled**.
+2. Select **Add tunnels**.
+3. Repeat the above steps for Tunnel 2. Chose the same Cloudflare anycast IP address and select the right IP for **Interface address**: `10.200.2.0/31`
+
+### Static routes
+
+The static route in {props.productName} should point to the appropriate virtual machine (VM) subnet you created inside your Oracle Virtual Cloud Network (VCN). For example, if your VM has a subnet of `192.168.192.0/26`, you should use it as the prefix for your static route.
+
+To create a static route:
+
+1. Refer to Create a static route to learn how to create one.
+2. In **Prefix**, enter the subnet for your VM. For example, `192.xx.xx.xx/24`.
+3. For the **Tunnel/Next hop**, choose the IPsec tunnel you created in the previous step.
+4. Repeat the steps above for the second IPsec tunnel you created.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/palo-alto.mdx b/src/content/partials/networking-services/magic-wan/third-party/palo-alto.mdx
new file mode 100644
index 00000000000000..b0db0202da67c1
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/palo-alto.mdx
@@ -0,0 +1,1572 @@
+---
+params:
+ - productName
+ - configureTwoIpsecTunnelsUrl
+ - configureBidirectionalHealthChecksUrl
+ - addTunnelsUrl
+ - staticRouteUrl
+ - equalcostMultipathEcmpRoutingUrl
+---
+
+This tutorial includes the steps required to configure IPsec tunnels to connect a Palo Alto Networks Next-Generation Firewall (NGFW) to Cloudflare {props.productName} through a Layer 3 deployment.
+
+## Software version tested
+
+- PAN-OS 9.1.14-h4
+
+## Use Cases
+
+- **{props.productName}**: Connecting two or more locations with [RFC-1918](https://datatracker.ietf.org/doc/html/rfc1918) private non-routable address space.
+- **{props.productName} with Cloudflare Zero Trust (Gateway egress)**: Same as {props.productName}, with the addition of outbound Internet access from {props.productName} 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](https://datatracker.ietf.org/doc/html/rfc1918) 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](https://datatracker.ietf.org/doc/html/rfc5737)) addresses within the `203.0.113.0/24` subnet.
+
+| Description | Address | Address |
+| --------------------------------- | ---------------------------------- | ---------------------------- |
+| NGFW external interface | `203.0.113.254/24` | |
+| NGFW internal interface | `10.1.100.254/24` | |
+| Local trust subnet (LAN) | `10.1.100.0/24` | |
+| NGFW tunnel interface 01 | `10.252.2.26/31` (Cloudflare side) | `10.252.2.27/31` (NGFW side) |
+| NGFW tunnel interface 02 | `10.252.2.28/31` (Cloudflare side) | `10.252.2.29/31` (NGFW side) |
+| {props.productName} anycast IP | `162.159.66.164` | `172.64.242.164` |
+| {props.productName} health check anycast IP | `172.64.240.253` | `172.64.240.254` |
+| VLAN0010 - remote {props.productName} site | `10.1.10.0/24` | |
+| VLAN0020 - remote {props.productName} site | `10.1.20.0/24` | |
+
+
+## Cloudflare {props.productName}
+
+### Magic IPsec Tunnels
+
+Use the Cloudflare dashboard or API to configure two IPsec Tunnels. The settings mentioned in [Add IPsec tunnels](#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.
+
+:::caution
+You need to configure bidirectional health checks with {props.productName}. The settings must include custom target IP addresses for each tunnel. Additionally, Cloudflare recommends that you lower the rate at which health check probes are sent.
+:::
+
+#### 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](#environment), 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](https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/policy/use-tags-to-group-and-visually-distinguish-objects/create-and-apply-tags), they can greatly improve object and policy visibility. The following color scheme was implemented in this configuration:
+
+| Tag | Color |
+| -------------------- | ------ |
+| `Trust_L3_Zone` | Green |
+| `Untrust_L3_Zone` | Red |
+| `Cloudflare_L3_Zone` | Orange |
+
+Use the Palo Alto Networks Next-Generation Firewall command-Line to set the tags:
+
+```bash
+set tag Trust_L3_Zone color color2
+set tag Untrust_L3_Zone color color1
+set tag Cloudflare_L3_Zone color color6
+```
+
+### 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
+
+:::note
+Any objects without a netmask specified are `/32`.
+:::
+
+| Name | Type | Address | Tags |
+| ------------------------------- | ---------- | ------------------ | -------------------- |
+| `CF_Health_Check_Anycast_01` | IP Netmask | `172.64.240.253` | `Cloudflare_L3_Zone` |
+| `CF_Health_Check_Anycast_02` | IP Netmask | `172.64.240.254` | `Cloudflare_L3_Zone` |
+| `CF_Magic_WAN_Anycast_01` | IP Netmask | `162.159.66.164` | `Cloudflare_L3_Zone` |
+| `CF_Magic_WAN_Anycast_02` | IP Netmask | `172.64.242.164` | `Cloudflare_L3_Zone` |
+| `CF_MWAN_IPsec_VTI_01_Local` | IP Netmask | `10.252.2.27/31` | `Cloudflare_L3_Zone` |
+| `CF_MWAN_IPsec_VTI_01_Remote` | IP Netmask | `10.252.2.26` | `Cloudflare_L3_Zone` |
+| `CF_MWAN_IPsec_VTI_02_Local` | IP Netmask | `10.252.2.29/31` | `Cloudflare_L3_Zone` |
+| `CF_MWAN_IPsec_VTI_02_Remote` | IP Netmask | `10.252.2.28` | `Cloudflare_L3_Zone` |
+| `CF_WARP_Client_Prefix` | IP Netmask | `100.96.0.0/12` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_01` | IP Netmask | `173.245.48.0/20` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_02` | IP Netmask | `103.21.244.0/22` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_03` | IP Netmask | `103.22.200.0/22` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_04` | IP Netmask | `103.31.4.0/22` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_05` | IP Netmask | `141.101.64.0/18` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_06` | IP Netmask | `108.162.192.0/18` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_07` | IP Netmask | `190.93.240.0/20` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_08` | IP Netmask | `188.114.96.0/20` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_09` | IP Netmask | `197.234.240.0/22` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_10` | IP Netmask | `198.41.128.0/17` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_11` | IP Netmask | `162.158.0.0/15` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_12` | IP Netmask | `104.16.0.0/13` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_13` | IP Netmask | `104.24.0.0/14` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_14` | IP Netmask | `172.64.0.0/13` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_15` | IP Netmask | `131.0.72.0/22` | `Cloudflare_L3_Zone` |
+| `Internet_L3_203-0-113-254--24` | IP Netmask | `203.0.113.254/24` | `Untrust_L3_Zone` |
+| `VLAN0010_10-1-10-0--24` | IP Netmask | `10.1.10.0/24` | `Cloudflare_L3_Zone` |
+| `VLAN0020_10-1-20-0--24` | IP Netmask | `10.1.20.0/24` | `Cloudflare_L3_Zone` |
+| `VLAN0100_10-1-100-0--24` | IP Netmask | `10.1.100.0/24` | `Trust_L3_Zone` |
+| `VLAN0100_L3_10-1-100-254--24` | IP Netmask | `10.1.10.254/24` | `Trust_L3_Zone` |
+
+Use the Palo Alto Networks Next-Generation Firewall command-Line to set the objects:
+
+```bash
+set address CF_Health_Check_Anycast_01 ip-netmask 172.64.240.253
+set address CF_Health_Check_Anycast_01 tag Cloudflare_L3_Zone
+set address CF_Health_Check_Anycast_02 ip-netmask 172.64.240.254
+set address CF_Health_Check_Anycast_02 tag Cloudflare_L3_Zone
+set address CF_Magic_WAN_Anycast_01 ip-netmask 162.159.66.164
+set address CF_Magic_WAN_Anycast_01 tag Cloudflare_L3_Zone
+set address CF_Magic_WAN_Anycast_02 ip-netmask 172.64.242.164
+set address CF_Magic_WAN_Anycast_02 tag Cloudflare_L3_Zone
+set address CF_MWAN_IPsec_VTI_01_Local ip-netmask 10.252.2.27/31
+set address CF_MWAN_IPsec_VTI_01_Local tag Cloudflare_L3_Zone
+set address CF_MWAN_IPsec_VTI_02_Local ip-netmask 10.252.2.29/31
+set address CF_MWAN_IPsec_VTI_02_Local tag Cloudflare_L3_Zone
+set address CF_MWAN_IPsec_VTI_01_Remote ip-netmask 10.252.2.26
+set address CF_MWAN_IPsec_VTI_01_Remote tag Cloudflare_L3_Zone
+set address CF_MWAN_IPsec_VTI_02_Remote ip-netmask 10.252.2.28
+set address CF_MWAN_IPsec_VTI_02_Remote tag Cloudflare_L3_Zone
+set address CF_WARP_Client_Prefix ip-netmask 100.96.0.0/12
+set address CF_WARP_Client_Prefix tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_01 ip-netmask 173.245.48.0/20
+set address Cloudflare_IPv4_01 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_02 ip-netmask 103.21.244.0/22
+set address Cloudflare_IPv4_02 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_03 ip-netmask 103.22.200.0/22
+set address Cloudflare_IPv4_03 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_04 ip-netmask 103.31.4.0/22
+set address Cloudflare_IPv4_04 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_05 ip-netmask 141.101.64.0/18
+set address Cloudflare_IPv4_05 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_06 ip-netmask 108.162.192.0/18
+set address Cloudflare_IPv4_06 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_07 ip-netmask 190.93.240.0/20
+set address Cloudflare_IPv4_07 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_08 ip-netmask 188.114.96.0/20
+set address Cloudflare_IPv4_08 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_09 ip-netmask 197.234.240.0/22
+set address Cloudflare_IPv4_09 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_10 ip-netmask 198.41.128.0/17
+set address Cloudflare_IPv4_10 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_11 ip-netmask 162.158.0.0/15
+set address Cloudflare_IPv4_11 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_12 ip-netmask 104.16.0.0/13
+set address Cloudflare_IPv4_12 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_13 ip-netmask 104.24.0.0/14
+set address Cloudflare_IPv4_13 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_14 ip-netmask 172.64.0.0/13
+set address Cloudflare_IPv4_14 tag Cloudflare_L3_Zone
+set address Cloudflare_IPv4_15 ip-netmask 131.0.72.0/22
+set address Cloudflare_IPv4_15 tag Cloudflare_L3_Zone
+set address Internet_L3_203-0-113-254--24 ip-netmask 203.0.113.254/24
+set address Internet_L3_203-0-113-254--24 tag Untrust_L3_Zone
+set address VLAN0010_10-1-10-0--24 ip-netmask 10.1.10.0/24
+set address VLAN0010_10-1-10-0--24 tag Trust_L3_Zone
+set address VLAN0020_10-1-20-0--24 ip-netmask 10.1.20.0/24
+set address VLAN0020_10-1-20-0--24 tag Trust_L3_Zone
+set address VLAN0100_10-1-100-0--24 ip-netmask 10.1.100.0/24
+set address VLAN0100_10-1-100-0--24 tag Trust_L3_Zone
+set address VLAN0100_L3_10-1-100-254--24 ip-netmask 10.1.100.254/24
+set address VLAN0100_L3_10-1-100-254--24 tag Trust_L3_Zone
+```
+
+#### Address Group object
+
+The **Address Group** object used in this configuration provides a single object representation of the entire Cloudflare IPv4 public address space.
+
+| Name | Type | Addresses | Tags |
+| ---------------------------- | ------ | -------------------- | -------------------- |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_01` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_02` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_03` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_04` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_05` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_06` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_07` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_08` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_09` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_10` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_11` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_12` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_13` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_14` | `Cloudflare_L3_Zone` |
+| `Cloudflare_IPv4_Static_Grp` | Static | `Cloudflare_IPv4_15` | `Cloudflare_L3_Zone` |
+
+Use the Palo Alto Networks Next-Generation Firewall command-Line to set the address group object:
+
+```bash
+set address-group Cloudflare_IPv4_Static_Grp static [ Cloudflare_IPv4_01 Cloudflare_IPv4_02 Cloudflare_IPv4_03 Cloudflare_IPv4_04 Cloudflare_IPv4_05 Cloudflare_IPv4_06 Cloudflare_IPv4_07 Cloudflare_IPv4_08 Cloudflare_IPv4_09 Cloudflare_IPv4_10 Cloudflare_IPv4_11 Cloudflare_IPv4_12 Cloudflare_IPv4_13 Cloudflare_IPv4_14 Cloudflare_IPv4_15 ]
+set address-group Cloudflare_IPv4_Static_Grp tag Cloudflare_L3_Zone
+```
+
+:::note
+While not covered by this tutorial, it is also possible to use External Dynamic Lists to automatically obtain the most current list of Cloudflare IPv4 addresses by periodically polling [https://www.cloudflare.com/ips-v4](https://www.cloudflare.com/ips-v4).
+:::
+
+### 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:
+
+```bash
+set network profiles interface-management-profile Allow_Ping userid-service no
+set network profiles interface-management-profile Allow_Ping ping yes
+```
+
+### Network Interfaces
+
+Palo Alto Networks Next-Generation Firewall (NGFW) is configured with two Ethernet interfaces:
+
+| Interface | Interface Type | IP Address | Virtual Router |
+| ----------- | -------------- | ------------------ | -------------- |
+| ethernet1/1 | Layer3 | `10.1.100.254/24` | default |
+| ethernet1/2 | Layer3 | `203.0.113.254/24` | default |
+
+#### 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`
+
+| Name | Option | Value |
+| ---------------- | ------------------ | --------------------------------------------------- |
+| **ethernet1/1** | Interface Type | _Layer3_ |
+| | Netflow Profile | _None_ |
+| **Config tab** | Virtual Router | _default_ |
+| | Security Zone | _Trust_L3_Zone_ |
+| **IPv4 tab** | Type | **Static** |
+| | IP | `VLAN0100_L3_10-1-100-254--24`
address object |
+| **Advanced tab** | Management Profile | _Mgmt_Services_ |
+
+
+
+
+
+##### ethernet1/2: `Untrust_L3_Zone`
+
+| Name | Option | Value |
+| ---------------- | ------------------- | ---------------------------------------------------- |
+| **ethernet1/2** | Interface Type | _Layer3_ |
+| | Netflow Profile | _None_ |
+| **Config tab** | Virtual Router | _default_ |
+| | Security Zone | _Untrust_L3_Zone_ |
+| **IPv4 tab** | Type | **Static** |
+| | IP | `Internet_L3_203-0-113-254--24`
address object |
+| **Advanced tab** | Management Profile | _Allow_Ping_ |
+| | MTU | `576 - 1500` |
+| | Adjust TCP MSS | **Enable** |
+| | IPv4 MSS Adjustment | `64` |
+
+
+
+
+
+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.
+
+```bash
+set network interface ethernet ethernet1/1 layer3 ndp-proxy enabled no
+set network interface ethernet ethernet1/1 layer3 lldp enable no
+set network interface ethernet ethernet1/1 layer3 ip VLAN0100_L3_10-1-100-254--24
+set network interface ethernet ethernet1/1 layer3 interface-management-profile Mgmt_Services
+set network interface ethernet ethernet1/2 layer3 ndp-proxy enabled no
+set network interface ethernet ethernet1/2 layer3 lldp enable no
+set network interface ethernet ethernet1/2 layer3 ip Internet_L3_203-0-113-254--24
+set network interface ethernet ethernet1/2 layer3 interface-management-profile Allow_Ping
+set network interface ethernet ethernet1/2 layer3 adjust-tcp-mss enable yes
+set network interface ethernet ethernet1/2 layer3 adjust-tcp-mss ipv4-mss-adjustment 64
+```
+
+### Tunnel interfaces
+
+Establishing IPsec Tunnels to Cloudflare {props.productName} 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.
+
+:::note
+MTU is set to `1450`. This value may need to be adjusted for optimal performance on your network.
+:::
+
+#### Set up via dashboard
+
+##### tunnel.1 - `Cloudflare_L3_Zone`
+
+| Name | Option | Value |
+| ---------------- | ------------------ | ------------------------------------------------- |
+| **tunnel.1** | Netflow Profile | _None_ |
+| **Config tab** | Virtual Router | _default_ |
+| | Security Zone | _Cloudflare_L3_Zone_ |
+| **IPv4 tab** | IP | `CF_MWAN_IPsec_VTI_01_Local`
address object |
+| **Advanced tab** | Management Profile | _Allow_Ping_ |
+| | MTU | `1450` |
+
+
+
+
+
+##### tunnel.2 - `Cloudflare_L3_Zone`
+
+| Name | Option | Value |
+| ---------------- | ------------------ | ------------------------------------------------- |
+| **tunnel.2** | Netflow Profile | _None_ |
+| **Config tab** | Virtual Router | _default_ |
+| | Security Zone | _Cloudflare_L3_Zone_ |
+| **IPv4 tab** | IP | `CF_MWAN_IPsec_VTI_02_Local`
address object |
+| **Advanced tab** | Management Profile | _Allow_Ping_ |
+| | MTU | `1450` |
+
+
+
+
+
+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:
+
+```bash
+set network interface tunnel units tunnel.1 ip CF_MWAN_IPsec_VTI_01_Local
+set network interface tunnel units tunnel.1 mtu 1450
+set network interface tunnel units tunnel.1 interface-management-profile Allow_Ping
+set network interface tunnel units tunnel.2 ip CF_MWAN_IPsec_VTI_02_Local
+set network interface tunnel units tunnel.2 mtu 1450
+set network interface tunnel units tunnel.2 interface-management-profile Allow_Ping
+```
+
+### Zones
+
+The Palo Alto Networks Next-Generation Firewall (NGFW) used to create this tutorial includes the following zones and corresponding network interfaces:
+
+| Zone | Interface | Interface |
+| -------------------- | ----------- | --------- |
+| `Trust_L3_Zone` | ethernet1/1 | |
+| `Untrust_L3_Zone` | ethernet1/2 | |
+| `Cloudflare_L3_Zone` | tunnel.1 | tunnel.2 |
+
+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.
+
+:::note
+Any {props.productName} protected networks that are not local should be considered part of the `Cloudflare_L3_Zone`.
+:::
+
+#### Set up via dashboard
+
+##### `Trust_L3_zone`
+
+| Name | Option | Value |
+| --------------- | ----------------------- | --------------- |
+| `Trust_L3_zone` | Log setting | _None_ |
+| | Type | _Layer3_ |
+| | Interfaces | **ethernet1/1** |
+| | Zone Protection Profile | _None_ |
+
+
+
+##### `Untrust_L3_zone`
+
+| Name | Option | Value |
+| ----------------- | ----------------------- | --------------------- |
+| `Untrust_L3_zone` | Log setting | _None_ |
+| | Type | _Layer3_ |
+| | Interfaces | **ethernet1/2** |
+| | Zone Protection Profile | _Untrust_Zone_Prof_ |
+
+
+
+##### `Cloudflare_L3_zone`
+
+| Name | Option | Value |
+| -------------------- | ----------------------- | ------------------------------- |
+| `Cloudflare_L3_zone` | Log setting | _None_ |
+| | Type | _Layer3_ |
+| | Interfaces | **tunnel.1**
**tunnel.2** |
+| | Zone Protection Profile | _None_ |
+
+
+
+
+#### Set up via command line
+
+You can also use the command line to associate zones and interfaces:
+
+```bash
+set zone Trust_L3_Zone network layer3 ethernet1/1
+set zone Untrust_L3_Zone network layer3 ethernet1/2
+set zone Cloudflare_L3_Zone network layer3 [ tunnel.1 tunnel.2 ]
+```
+
+### 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
+
+| Name | Option | Value |
+| ------------------- | ----------------------------- | -------------------------------------------- |
+| `CF_IKE_Crypto_CBC` | DH Group | **group20** |
+| | Authentication | **sha512**
**sha384**
**sha256** |
+| | Encryption | **aes-256-cbc** |
+| | Key Lifetime | 24 hours |
+| | IKEv2 Authentication Multiple | `0` |
+
+#### Set up via command line
+
+You can also set up the crypto profile for Phase 1 via the command line:
+
+```bash
+set network ike crypto-profiles ike-crypto-profiles CF_IKE_Crypto_CBC hash [ sha512 sha384 sha256 ]
+set network ike crypto-profiles ike-crypto-profiles CF_IKE_Crypto_CBC dh-group [ group20 ]
+set network ike crypto-profiles ike-crypto-profiles CF_IKE_Crypto_CBC encryption aes-256-cbc
+set network ike crypto-profiles ike-crypto-profiles CF_IKE_Crypto_CBC lifetime hours 24
+set network ike crypto-profiles ike-crypto-profiles CF_IKE_Crypto_CBC authentication-multiple 0
+```
+
+### 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
+
+| Name | Option | Value |
+| --------------------- | -------------- | ------------------------- |
+| `CF_IPsec_Crypto_CBC` | Encryption | **aes-256-cbc** |
+| | Authentication | **sha256**
**sha1** |
+| | DH Group | **group20** |
+| | Lifetime | 8 hours |
+
+#### Set up via command line
+
+You can also set up the IPsec crypto profile for Phase 2 via the command line:
+
+```bash
+set network ike crypto-profiles ipsec-crypto-profiles CF_IPsec_Crypto_CBC esp authentication [ sha256 sha1 ]
+set network ike crypto-profiles ipsec-crypto-profiles CF_IPsec_Crypto_CBC esp encryption aes-256-cbc
+set network ike crypto-profiles ipsec-crypto-profiles CF_IPsec_Crypto_CBC lifetime hours 8
+set network ike crypto-profiles ipsec-crypto-profiles CF_IPsec_Crypto_CBC dh-group group20
+```
+
+### IKE Gateways
+
+:::note
+Any other settings not specified should be left at their default values. Any deviation may lead to undesirable behavior and are not supported.
+:::
+
+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`
+
+:::note
+Make sure you select `CF_IKE_Crypto_CBC` as the IKE Crypto profile.
+:::
+
+| Tab | Option | Value |
+| ----------------- | ------- | -------------------- |
+| **General tab** | Name |`CF_Magic_WAN_IKE_01` |
+| | Version | _IKEv2 only mode_.
Make sure both IKE Gateways are based only on this setting. |
+| | Local IP Address | `Internet_L3_203-0-113-254--24` |
+| | Peer address | `CF_Magic_WAN_Anycast_01` |
+| | Pre-Shared Key | This value can be obtained from the Cloudflare dashboard - value is unique per tunnel. |
+| | Local Identification | _FQDN (hostname)_.
You can obtain this value from the Cloudflare Dashboard - value is unique per tunnel. |
+| | Peer Identification | _None_ |
+| **Advanced tab** | IKE Crypto Profile | _CF_IKE_Crypto_CBC_ |
+| | Liveness Check | The default value (five seconds) is sufficient. This setting is used to periodically determine if there are any underlying connectivity issues that may adversely affect the creation of Phase 1 Security Associations. |
+
+
+
+
+##### Tunnel 2 settings: `CF_Magic_WAN_IKE_02`
+
+:::note
+Make sure you select `CF_IKE_Crypto_CBC` as the IKE Crypto profile.
+:::
+
+| Tab | Option | Value |
+| ---------------- | -------------------- |------ |
+| **General tab** | Name | `CF_Magic_WAN_IKE_02` |
+| | Version | _IKEv2 only mode_.
Make sure both IKE Gateways are based only on this setting. |
+| | Local IP Address | `Internet_L3_203-0-113-254--24` |
+| | Peer address | `CF_Magic_WAN_Anycast_02` |
+| | Pre-Shared Key | This value can be obtained from the Cloudflare dashboard - value is unique per tunnel. |
+| | Local Identification | _FQDN (hostname)_.
You can obtain this value from the Cloudflare Dashboard - value is unique per tunnel. |
+| | Peer Identification | _None_ |
+| **Advanced tab** | IKE crypto profile | _CF_IKE_Crypto_CBC_ |
+| | Liveness Check | The default value (five seconds) is sufficient. This setting is used to periodically determine if there are any underlying connectivity issues that may adversely affect the creation of Phase 1 Security Associations. |
+
+
+
+
+#### Set up via command line
+
+##### Tunnel 1 settings: `CF_Magic_WAN_IKE_01`
+
+```bash
+set network ike gateway CF_Magic_WAN_IKE_01 protocol ikev1 dpd enable yes
+set network ike gateway CF_Magic_WAN_IKE_01 protocol ikev2 dpd enable yes
+set network ike gateway CF_Magic_WAN_IKE_01 protocol ikev2 ike-crypto-profile CF_IKE_Crypto_CBC
+set network ike gateway CF_Magic_WAN_IKE_01 protocol version ikev2
+set network ike gateway CF_Magic_WAN_IKE_01 local-address ip Internet_L3_203-0-113-254--24
+set network ike gateway CF_Magic_WAN_IKE_01 local-address interface ethernet1/2
+set network ike gateway CF_Magic_WAN_IKE_01 protocol-common nat-traversal enable no
+set network ike gateway CF_Magic_WAN_IKE_01 protocol-common fragmentation enable no
+set network ike gateway CF_Magic_WAN_IKE_01 peer-address ip CF_Magic_WAN_Anycast_01
+set network ike gateway CF_Magic_WAN_IKE_01 authentication pre-shared-key key -AQ==Xdcd9ir5o5xhjuIH---------------------HsRoVf+M0TTG4ja3EzulN37zMOwGs
+set network ike gateway CF_Magic_WAN_IKE_01 local-id id 28de99ee57424ee0a1591384193982fa.33145236.ipsec.cloudflare.com
+set network ike gateway CF_Magic_WAN_IKE_01 local-id type fqdn
+set network ike gateway CF_Magic_WAN_IKE_01 disabled no
+```
+
+##### Tunnel 2 settings: `CF_Magic_WAN_IKE_02`
+
+```bash
+set network ike gateway CF_Magic_WAN_IKE_02 protocol ikev1 dpd enable yes
+set network ike gateway CF_Magic_WAN_IKE_02 protocol ikev2 dpd enable yes
+set network ike gateway CF_Magic_WAN_IKE_02 protocol ikev2 ike-crypto-profile CF_IKE_Crypto_CBC
+set network ike gateway CF_Magic_WAN_IKE_02 protocol version ikev2
+set network ike gateway CF_Magic_WAN_IKE_02 local-address ip Internet_L3_203-0-113-254--24
+set network ike gateway CF_Magic_WAN_IKE_02 local-address interface ethernet1/2
+set network ike gateway CF_Magic_WAN_IKE_02 protocol-common nat-traversal enable no
+set network ike gateway CF_Magic_WAN_IKE_02 protocol-common fragmentation enable no
+set network ike gateway CF_Magic_WAN_IKE_02 peer-address ip CF_Magic_WAN_Anycast_02
+set network ike gateway CF_Magic_WAN_IKE_02 authentication pre-shared-key key -AQ==rvwEulxx7wLBl---------------------swSeJPXxxM2cfPbt7q4HZZGZZ8
+set network ike gateway CF_Magic_WAN_IKE_02 local-id id b87322b0915b47158667bf1653990e66.33145236.ipsec.cloudflare.com
+set network ike gateway CF_Magic_WAN_IKE_02 local-id type fqdn
+set network ike gateway CF_Magic_WAN_IKE_02 disabled no
+```
+
+### 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. {props.productName} 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 ({props.productName} IPsec tunnels are based on IKEv2).
+
+#### Set up via dashboard
+
+##### Tunnel 1 settings: `CF_Magic_WAN_IPsec_01`
+
+| Name | Option | Value |
+| ----------------------- | ------------------------ | ------------------------- |
+| `CF_Magic_WAN_IPsec_01` | Tunnel interface | tunnel.1 |
+| | IKE Gateway | _CF_Magic_WAN_IKE_01_ |
+| | IPsec crypto profile | _CF_IKE_Crypto_CBC_ |
+| | Enable Replay Protection | **Disable** |
+
+
+
+
+##### Tunnel 2 settings: `CF_Magic_WAN_IPsec_02`
+
+| Name | Option | Value |
+| ----------------------- | ------------------------ | ------------------------- |
+| `CF_Magic_WAN_IPsec_02` | Tunnel interface | tunnel.2 |
+| | IKE Gateway | _CF_Magic_WAN_IKE_02_ |
+| | IPsec crypto profile | _CF_IKE_Crypto_CBC_ |
+| | Enable Replay Protection | **Disable** |
+
+
+
+
+#### Set up via command line
+
+##### Tunnel 1 settings: `CF_Magic_WAN_IPsec_01`
+
+```bash
+set network tunnel ipsec CF_Magic_WAN_IPsec_01 auto-key ike-gateway CF_Magic_WAN_IKE_01
+set network tunnel ipsec CF_Magic_WAN_IPsec_01 auto-key ipsec-crypto-profile CF_IPsec_Crypto_CBC
+set network tunnel ipsec CF_Magic_WAN_IPsec_01 tunnel-monitor destination-ip 10.252.2.26
+set network tunnel ipsec CF_Magic_WAN_IPsec_01 tunnel-monitor tunnel-monitor-profile default
+set network tunnel ipsec CF_Magic_WAN_IPsec_01 tunnel-interface tunnel.1
+set network tunnel ipsec CF_Magic_WAN_IPsec_01 anti-replay no
+set network tunnel ipsec CF_Magic_WAN_IPsec_01 disabled no
+```
+
+##### Tunnel 2 settings: `CF_Magic_WAN_IPsec_02`
+
+```bash
+set network tunnel ipsec CF_Magic_WAN_IPsec_02 auto-key ike-gateway CF_Magic_WAN_IKE_02
+set network tunnel ipsec CF_Magic_WAN_IPsec_02 auto-key ipsec-crypto-profile CF_IPsec_Crypto_CBC
+set network tunnel ipsec CF_Magic_WAN_IPsec_02 tunnel-monitor destination-ip 10.252.2.28
+set network tunnel ipsec CF_Magic_WAN_IPsec_02 tunnel-monitor tunnel-monitor-profile default
+set network tunnel ipsec CF_Magic_WAN_IPsec_02 tunnel-interface tunnel.2
+set network tunnel ipsec CF_Magic_WAN_IPsec_02 anti-replay no
+set network tunnel ipsec CF_Magic_WAN_IPsec_02 disabled no
+```
+
+### 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.
+
+:::note
+Tunnel health checks will not function until security policies and policy-based forwarding are configured. This series of tests is focused on testing IPsec connectivity exclusively.
+:::
+
+#### Verify IKE Phase 1 Communications
+
+The first step is to verify IKE Phase 1 completed successfully:
+
+##### Syntax
+
+```bash
+show vpn ike-sa gateway [value]
+```
+
+##### Example for `CF_Magic_WAN_IKE_01`
+
+```bash
+admin@panvm03> show vpn ike-sa gateway CF_Magic_WAN_IKE_01
+
+There is no IKEv1 phase-1 SA found.
+
+There is no IKEv1 phase-2 SA found.
+
+IKEv2 SAs
+Gateway ID Peer-Address Gateway Name Role SN Algorithm Established Expiration Xt Child ST
+
+---------- ------------ ------------ ---- -- --------- ----------- ---------- -- ----- --
+
+2 162.159.66.164 CF_Magic_WAN_IKE_01 Init 67 PSK/DH20/A256/SHA256 Jun.04 21:09:13 Jun.05 05:09:13 0 1 Established
+
+IKEv2 IPsec Child SAs
+Gateway Name TnID Tunnel ID Parent Role SPI(in) SPI(out) MsgID ST
+
+------------ ---- ------ -- ------ ---- ------- -------- ----- --
+
+CF_Magic_WAN_IKE_01 2 CF_Magic_WAN_IPsec_01 322550 67 Init FCAEE176 1EF41BA9 000007B4 Mature
+
+Show IKEv2 SA: Total 2 gateways found. 1 ike sa found.
+```
+
+##### Example for `CF_Magic_WAN_IKE_02`
+
+```bash
+admin@panvm03> show vpn ike-sa gateway CF_Magic_WAN_IKE_02
+
+There is no IKEv1 phase-1 SA found.
+
+There is no IKEv1 phase-2 SA found.
+
+IKEv2 SAs
+Gateway ID Peer-Address Gateway Name Role SN Algorithm Established Expiration Xt Child ST
+
+---------- ------------ ------------ ---- -- --------- ----------- ---------- -- ----- --
+
+3 172.64.242.164 CF_Magic_WAN_IKE_02 Init 66 PSK/DH20/A256/SHA256 Jun.04 20:37:42 Jun.05 04:37:42 0 2 Established
+
+IKEv2 IPsec Child SAs
+Gateway Name TnID Tunnel ID Parent Role SPI(in) SPI(out) MsgID ST
+
+------------ ---- ------ -- ------ ---- ------- -------- ----- --
+
+CF_Magic_WAN_IKE_02 3 CF_Magic_WAN_IPsec_02 323145 66 Init B6EDA356 43F71BC5 00000A52 Mature
+
+Show IKEv2 SA: Total 2 gateways found. 1 ike sa found.
+```
+
+#### Troubleshooting IKE Phase 1 Communications
+
+{props.productName} 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
+
+```bash
+test vpn ike-sa gateway [value]
+```
+
+##### Example for `CF_Magic_WAN_IKE_01`
+
+```bash
+admin@panvm03> test vpn ike-sa gateway CF_Magic_WAN_IKE_01
+
+Start time: Jun.05 00:30:29
+Initiate 1 IKE SA.
+```
+
+##### Example for `CF_Magic_WAN_IKE_02`
+
+```bash
+admin@panvm03> test vpn ike-sa gateway CF_Magic_WAN_IKE_02
+
+Start time: Jun.05 00:30:33
+Initiate 1 IKE SA.
+```
+
+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
+
+```bash
+show vpn ipsec-sa tunnel [value]
+```
+
+##### Example for `CF_Magic_WAN_IPsec_01`
+
+```bash
+admin@panvm03> show vpn ipsec-sa tunnel CF_Magic_WAN_IPsec_01
+
+GwID/client IP TnID Peer-Address Tunnel(Gateway) Algorithm SPI(in) SPI(out) life(Sec/KB) remain-time(Sec)
+
+-------------- ---- ------------ --------------- --------- ------- -------- ------------ ----------------
+
+2 2 162.159.66.164 CF_Magic_WAN_IPsec_01(CF_Magic_WAN_IKE_01) ESP/A256/SHA256 B5D09AB8 9FA69407 3600/Unlimited 3445
+
+Show IPsec SA: Total 1 tunnels found. 1 ipsec sa found.
+```
+
+##### Example for `CF_Magic_WAN_IPsec_02`
+
+```bash
+admin@panvm03> show vpn ipsec-sa tunnel CF_Magic_WAN_IPsec_02
+
+GwID/client IP TnID Peer-Address Tunnel(Gateway) Algorithm SPI(in) SPI(out) life(Sec/KB) remain-time(Sec)
+
+-------------- ---- ------------ --------------- --------- ------- -------- ------------ ----------------
+
+3 3 172.64.242.164 CF_Magic_WAN_IPsec_02(CF_Magic_WAN_IKE_02) ESP/A256/SHA256 CAEA6F09 EC6ACC7A 3600/Unlimited 3361
+
+Show IPsec SA: Total 1 tunnels found. 1 ipsec sa found.
+```
+
+#### Troubleshooting IPsec Phase 2 Communications
+
+{props.productName} 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
+
+```bash
+test vpn ipsec-sa tunnel [value]
+```
+
+##### Example for `CF_Magic_WAN_IPsec_01`
+
+```bash
+admin@panvm03> test vpn ipsec-sa tunnel CF_Magic_WAN_IPsec_01
+
+Start time: Jun.05 00:37:50
+Initiate 1 IPsec SA for tunnel CF_Magic_WAN_IPsec_01.
+```
+
+##### Example for `CF_Magic_WAN_IPsec_02`
+
+```bash
+admin@panvm03> test vpn ipsec-sa tunnel CF_Magic_WAN_IPsec_02
+
+Start time: Jun.05 00:38:52
+Initiate 1 IPsec SA for tunnel 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.
+
+:::note
+The interface address is defined with a `/31` netmask. There have been isolated cases where NGFW exhibited issues when using ping to verify connectivity between the local and remote Virtual Tunnel interfaces. This behavior can vary depending on the version of PAN-OS installed on the firewall. If you encounter this issue, either switch to a `/30` netmask, or contact Palo Alto Networks support for assistance.
+:::
+
+##### Syntax
+
+```bash
+ping source [value src IP] host [value dst IP]
+```
+
+##### Example for Tunnel 1
+
+```bash
+admin@panvm03> ping source 10.252.2.27 host 10.252.2.26
+PING 10.252.2.26 (10.252.2.26) from 10.252.2.27 : 56(84) bytes of data.
+64 bytes from 10.252.2.26: icmp_seq=1 ttl=64 time=2.71 ms
+64 bytes from 10.252.2.26: icmp_seq=2 ttl=64 time=2.03 ms
+64 bytes from 10.252.2.26: icmp_seq=3 ttl=64 time=1.98 ms
+64 bytes from 10.252.2.26: icmp_seq=4 ttl=64 time=1.98 ms
+^C
+--- 10.252.2.26 ping statistics ---
+4 packets transmitted, 4 received, 0% packet loss, time 3002ms
+rtt min/avg/max/mdev = 1.980/2.180/2.719/0.312 ms
+```
+
+##### Example for Tunnel 2
+
+```bash
+admin@panvm03> ping source 10.252.2.29 host 10.252.2.28
+PING 10.252.2.28 (10.252.2.28) from 10.252.2.29 : 56(84) bytes of data.
+64 bytes from 10.252.2.28: icmp_seq=1 ttl=64 time=2.90 ms
+64 bytes from 10.252.2.28: icmp_seq=2 ttl=64 time=1.92 ms
+64 bytes from 10.252.2.28: icmp_seq=3 ttl=64 time=1.76 ms
+64 bytes from 10.252.2.28: icmp_seq=4 ttl=64 time=1.97 ms
+^C
+--- 10.252.2.28 ping statistics ---
+4 packets transmitted, 4 received, 0% packet loss, time 3003ms
+rtt min/avg/max/mdev = 1.765/2.141/2.900/0.446 ms
+```
+
+### 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 {props.productName} 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.
+
+:::note
+ECMP is disabled on the Palo Alto Networks Next-Generation Firewall by default. Enabling ECMP will force the Virtual Router to restart. While a restart of the Virtual Router is much faster than restarting the entire firewall, it is still recommended that you make this change during a scheduled maintenance window.
+:::
+
+#### 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 {props.productName} Static Routes (reference the Cloudflare Dashboard).
+
+
+
+You can also use the command line to make these changes:
+
+```bash
+set network virtual-router default ecmp algorithm weighted-round-robin interface tunnel.1 weight 100
+set network virtual-router default ecmp algorithm weighted-round-robin interface tunnel.2 weight 100
+set network virtual-router default ecmp enable yes
+set network virtual-router default ecmp symmetric-return yes
+set network virtual-router default ecmp strict-source-path yes
+```
+
+#### Add static routes
+
+Add two static routes for each {props.productName} Protected Network - one for each of the two tunnel interfaces.
+
+:::note
+Palo Alto Networks Next-Generation Firewall will not allow for configuring two routes to the same destination with equal metrics - even if they reference different interfaces and ECMP is enabled. The examples provided here use Metric 10 for the route via interface tunnel.1 and Metric 11 for the route via interface tunnel.2.
+:::
+
+The environment used for this tutorial assumes two {props.productName} Protected Networks:
+
+- **VLAN0010**: `10.1.10.0/24`
+- **VLAN0020**: `10.1.20.0/24`
+
+##### VLAN0010 (`10.1.10.0/24`) via tunnel.1
+
+| Name | Option | Value |
+| -------------------------- | ----------- | ---------------------------------- |
+| `Magic_WAN_VLAN0010_Tun01` | Destination | _VLAN0010_10-1-10-0--24_ |
+| | Interface | _tunnel.1_ |
+| | Next hop | _IP Address_ |
+| | | _CF_MWAN_IPsec_VTI_01_Remote_ |
+| | Metric | `10` |
+| | Route Table | _Unicast_ |
+| | BFD Profile | _Disable BFD_ |
+
+
+
+##### VLAN0010 (`10.1.10.0/24`) via tunnel.2
+
+| Name | Option | Value |
+| -------------------------- | ----------- | ---------------------------------- |
+| `Magic_WAN_VLAN0010_Tun02` | Destination | _VLAN0010_10-1-10-0--24_ |
+| | Interface | _tunnel.2_ |
+| | Next hop | _IP Address_ |
+| | | _CF_MWAN_IPsec_VTI_02_Remote_ |
+| | Metric | `11` |
+| | Route Table | _Unicast_ |
+| | BFD Profile | _Disable BFD_ |
+
+
+
+##### VLAN0020 (`10.1.20.0/24`) via tunnel.1
+
+| Name | Option | Value |
+| -------------------------- | ----------- | ---------------------------------- |
+| `Magic_WAN_VLAN0020_Tun01` | Destination | _VLAN0020_10-1-20-0--24_ |
+| | Interface | _tunnel.1_ |
+| | Next hop | _IP Address_ |
+| | | _CF_MWAN_IPsec_VTI_01_Remote_ |
+| | Metric | `10` |
+| | Route Table | _Unicast_ |
+| | BFD Profile | _Disable BFD_ |
+
+
+
+##### VLAN0020 (`10.1.20.0/24`) via tunnel.2
+
+| Name | Option | Value |
+| -------------------------- | ----------- | ---------------------------------- |
+| `Magic_WAN_VLAN0020_Tun02` | Destination | _VLAN0020_10-1-20-0--24_ |
+| | Interface | _tunnel.2_ |
+| | Next hop | _IP Address_ |
+| | | _CF_MWAN_IPsec_VTI_02_Remote_ |
+| | Metric | `11` |
+| | Route Table | _Unicast_ |
+| | BFD Profile | _Disable BFD_ |
+
+
+
+You can also configure these settings via command line:
+
+##### VLAN0010 - `10.1.10.0/24`
+
+```bash
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun01 nexthop ip-address CF_MWAN_IPsec_VTI_01_Remote
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun01 bfd profile None
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun01 interface tunnel.1
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun01 metric 10
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun01 destination VLAN0010_10-1-10-0--24
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun01 route-table unicast
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun02 nexthop ip-address CF_MWAN_IPsec_VTI_02_Remote
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun02 bfd profile None
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun02 interface tunnel.2
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun02 metric 11
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun02 destination VLAN0010_10-1-10-0--24
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0010_Tun02 route-table unicast
+```
+
+##### VLAN0020 - `10.1.20.0/24`
+
+```bash
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun01 nexthop ip-address CF_MWAN_IPsec_VTI_01_Remote
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun01 bfd profile None
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun01 interface tunnel.1
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun01 metric 10
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun01 destination VLAN0020_10-1-20-0--24
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun01 route-table unicast
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun02 nexthop ip-address CF_MWAN_IPsec_VTI_02_Remote
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun02 bfd profile None
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun02 interface tunnel.2
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun02 metric 11
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun02 destination VLAN0020_10-1-20-0--24
+set network virtual-router default routing-table ip static-route Magic_WAN_VLAN0020_Tun02 route-table unicast
+```
+
+### 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).
+
+:::note
+The construct of the security policies may seem counter-intuitive - this is due to the use of ICMP reply probes. As long as you adhere to the recommended policies in this documentation, the bi-directional health checks will work as expected.
+:::
+
+Cloudflare {props.productName} 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.
+
+:::note
+Cloudflare health checks are sent from random servers across Cloudflare's global network and can originate from any addresses within the Cloudflare IPv4 address space represented by the `Cloudflare_IPv4_Static_Grp`.
+:::
+
+##### Setup via dashboard
+
+| Name | Option | Value |
+| ------------------------------- | ------------------- | --------------------------------------------------------------------------- |
+| `Cloudflare_Tunnel_Bidirect_HC` | Rule Type | _universal (default)_ |
+| | Description | `Permit bidirectional HCs` |
+| | Group Rules By Tag | _None_ |
+| **Source tab** | Source Zone | **Cloudflare_L3_Zone** |
+| | Source Address | **CF_Health_Check_Anycast_01**
**CF_Health_Check_Anycast_02** |
+| **Destination tab** | Destination Zone | **Cloudflare_L3_Zone** |
+| | Destination Address | **Cloudflare_IPv4_Static_Grp** |
+| **Application tab** | Applications | **icmp**
**ping** |
+| **Actions tab** | Action | _Allow_ |
+| | Log Setting | **Log at Session End** |
+| | Profile type | _None_ |
+| | Schedule | _None_ |
+| | QoS Marking | _None_ |
+
+
+
+
+
+
+
+
+##### Setup via command line
+
+```bash
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC to Cloudflare_L3_Zone
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC from Cloudflare_L3_Zone
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC source [ CF_Health_Check_Anycast_01 CF_Health_Check_Anycast_02 ]
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC destination Cloudflare_IPv4_Static_Grp
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC source-user any
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC category any
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC application [ icmp ping ]
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC service application-default
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC hip-profiles any
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC action allow
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC rule-type universal
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC description "Permit bidirectional HCs"
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC disabled no
+set rulebase security rules Cloudflare_Tunnel_Bidirect_HC log-end yes
+```
+
+:::note
+Logging is enabled on the rule to permit heath checks. While the amount of bandwidth consumed by health checks is negligible, the flows generate a significant number of log entries. You may want to disable logging on this rule once in production, and only enable it if any troubleshooting becomes necessary.
+:::
+
+#### 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
+
+| Name | Option | Value |
+| --------------------------------------- | ------------------- | ---------------------------------- |
+| `PBF_Cloudflare_Health_Check_01` | Tags | _Cloudflare_L3_Zone_ |
+| | Group Rules By Tag | _None_ |
+| **Source tab** | Type | _Zone_ |
+| | Zone | **Cloudflare_L3_Zone** |
+| | Source Address | **CF_Health_Check_Anycast_01** |
+| **Destination/Application/Service tab** | Destination Address | **Cloudflare_IPv4_Static_Grp** |
+| **Forwarding tab** | Action | _Forward_ |
+| | Egress interface | _tunnel.1_ |
+| | Next Hop | _IP Address_ |
+| | | _CF_MWAN_IPsec_VTI_01_Remote_ |
+
+
+
+
+
+
+##### Set up via dashboard tunnel.2
+
+| Name | Option | Value |
+| --------------------------------------- | ------------------- | ---------------------------------- |
+| `PBF_Cloudflare_Health_Check_02` | Tags | _Cloudflare_L3_Zone_ |
+| | Group Rules By Tag | _None_ |
+| **Source tab** | Type | _Zone_ |
+| | Zone | **Cloudflare_L3_Zone** |
+| | Source Address | **CF_Health_Check_Anycast_02** |
+| **Destination/Application/service tab** | Destination Address | **Cloudflare_IPv4_Static_Grp** |
+| **Forwarding tab** | Action | _Forward_ |
+| | Egress interface | _tunnel.2_ |
+| | Next Hop | _IP Address_ |
+| | | _CF_MWAN_IPsec_VTI_02_Remote_ |
+
+
+
+
+
+
+##### Set up via command line tunnel.1
+
+```bash
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_01 action forward nexthop ip-address CF_MWAN_IPsec_VTI_01_Remote
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_01 action forward egress-interface tunnel.1
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_01 from zone Cloudflare_L3_Zone
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_01 enforce-symmetric-return enabled no
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_01 source CF_Health_Check_Anycast_01
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_01 destination Cloudflare_IPv4_Static_Grp
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_01 source-user any
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_01 application any
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_01 service any
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_01 tag Cloudflare_L3_Zone
+```
+
+##### Set up via command line tunnel.2
+
+```bash
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_02 action forward nexthop ip-address CF_MWAN_IPsec_VTI_02_Remote
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_02 action forward egress-interface tunnel.2
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_02 from zone Cloudflare_L3_Zone
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_02 enforce-symmetric-return enabled no
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_02 source CF_Health_Check_Anycast_02
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_02 destination Cloudflare_IPv4_Static_Grp
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_02 source-user any
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_02 application any
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_02 service any
+set rulebase pbf rules PBF_Cloudflare_Healthcheck_02 tag Cloudflare_L3_Zone
+```
+
+### 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
+
+```bash
+rule eq Cloudflare_Tunnel_Bidirect_HC
+```
+
+
+
+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
+
+```bash
+( addr.src in 172.64.240.253 ) or ( addr.src in 172.64.240.254 )
+```
+
+
+
+#### 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:
+
+- **{props.productName}**: permit traffic between two or more locations with [RFC-1918](https://datatracker.ietf.org/doc/html/rfc1918) private non-routable address space.
+- **{props.productName} with Cloudflare Zero Trust (Gateway egress)**: same as {props.productName} with the addition of outbound Internet access from {props.productName} protected sites egressing the Cloudflare edge network.
+
+#### {props.productName} only
+
+Rules must be defined to facilitate traffic from the trust network to the {props.productName} protected sites. While it may be possible to define one rule for traffic in both directions, this example includes two rules:
+
+- From Trust to {props.productName} protected sites.
+
+- From {props.productName} protected sites to Trust.
+
+##### Trust to {props.productName} dashboard
+
+| Name | Option | Value |
+| ------------------------------------- | ------------------- | ------------------------------------------------------------- |
+| `Trust_to_Cloudflare_Magic_WAN_Allow` | Rule Type | _universal (default)_ |
+| | Group Rules by Tag | _None_ |
+| **Source tab** | Source Zone | **Trust_L3_Zone** |
+| | Source Address | **VLAN0100_10-1-100-0--24** |
+| **Destination tab** | Destination Zone | **Cloudflare_L3_Zone** |
+| | Destination Address | **VLAN0010_10-1-10-0--24**
**VLAN0020_10-1-20-0--24** |
+| **Actions tab** | Action | _Allow_ |
+| | Log Setting | **Log at Session End** |
+| | Profile type | _None_ |
+| | Schedule | _None_ |
+| | QoS Marking | _None_ |
+
+
+
+
+
+
+
+
+##### Trust to {props.productName} command line
+
+```bash
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow to Cloudflare_L3_Zone
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow from Trust_L3_Zone
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow source VLAN0100_10-1-100-0--24
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow destination [ VLAN0010_10-1-10-0--24 VLAN0020_10-1-20-0--24 ]
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow source-user any
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow category any
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow application any
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow service application-default
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow hip-profiles any
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow action allow
+set rulebase security rules Trust_to_Cloudflare_Magic_WAN_Allow rule-type universal
+```
+
+##### {props.productName} to Trust dashboard
+
+| Name | Option | Value |
+| ------------------------------------- | ------------------- | ------------------------------------------------------------- |
+| `Cloudflare_Magic_WAN_to_Trust_Allow` | Rule Type | _universal (default)_ |
+| | Group Rules by Tag | _None_ |
+| Source tab | Source Zone | **Cloudflare_L3_Zone** |
+| | Source Address | **VLAN0010_10-1-10-0--24**
**VLAN0020_10-1-20-0--24** |
+| Destination tab | Destination Zone | **Trust_L3_Zone** |
+| | Destination Address | **VLAN0100_10-1-100-0--24** |
+| Actions tab | Action | _Allow_ |
+| | Log Setting | **Log at Session End** |
+| | Profile type | _None_ |
+| | Schedule | _None_ |
+| | QoS Marking | _None_ |
+
+
+
+
+
+
+
+
+##### {props.productName} to Trust command line
+
+```bash
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow to Trust_L3_Zone
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow from Cloudflare_L3_Zone
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow source [ VLAN0010_10-1-10-0--24 VLAN0020_10-1-20-0--24 ]
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow destination VLAN0100_10-1-100-0--24
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow source-user any
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow category any
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow application any
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow service application-default
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow hip-profiles any
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow action allow
+set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow rule-type universal
+```
+
+### 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 {props.productName} protected sites or {props.productName} protected sites with Gateway egress must be routed across the IPsec tunnels.
+
+:::note
+Security rules match traffic flows based on source and destination zone. Policy-based forwarding rules are applied per interface. Therefore, two policy-based forwarding rules are required for every one security rule - one for tunnel.1 and one for tunnel.2.
+:::
+
+#### Dashboard policy-based forwarding - {props.productName} production traffic via tunnel.1
+
+| Name | Option | Value |
+| --------------------------------------- | ------------------- | ------------------------------------------------------------- |
+| `PBF_Magic_WAN_Sites_01` | Group Rules by Tag | _None_ |
+| **Source tab** | Type | _Zone_ |
+| | Zone | **Trust_L3_Zone** |
+| | Source Address | **VLAN0100_10-1-100-0--24** |
+| **Destination/Application/Service tab** | Destination Address | **VLAN0010_10-1-10-0--24**
**VLAN0020_10-1-20-0--24** |
+| **Forwarding tab** | Action | _Forward_ |
+| | Egress Interface | _tunnel.1_ |
+| | Next hop | _IP Address_ |
+| | | _CF_MWAN_IPsec_VTI_01_Remote_ |
+
+
+
+
+
+
+#### Command line policy-based forwarding - {props.productName} production traffic via tunnel.1
+
+```bash
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 action forward nexthop ip-address CF_MWAN_IPsec_VTI_01_Remote
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 action forward egress-interface tunnel.1
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 from zone Trust_L3_Zone
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 enforce-symmetric-return enabled no
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 source VLAN0100_10-1-100-0--24
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 destination [ VLAN0010_10-1-10-0--24 VLAN0020_10-1-20-0--24 ]
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 source-user any
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 application any
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 service any
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 disabled no
+set rulebase pbf rules PBF_Magic_WAN_Sites_01 negate-destination no
+```
+
+#### Dashboard policy-based forwarding - {props.productName} production traffic via tunnel.2
+
+| Name | Option | Value |
+| --------------------------------------- | ------------------- | ------------------------------------------------------------- |
+| `PBF_Magic_WAN_sites_02` | Group Rules by Tag | _None_ |
+| **Source tab** | Type | _Zone_ |
+| | Zone | **Trust_L3_Zone** |
+| | Source Address | **VLAN0100_10-1-100-0--24** |
+| **Destination/Application/Service tab** | Destination Address | **VLAN0010_10-1-10-0--24**
**VLAN0020_10-1-20-0--24** |
+| **Forwarding tab** | Action | _Forward_ |
+| | Egress Interface | _tunnel.2_ |
+| | Next hop | _IP Address_ |
+| | | _CF_MWAN_IPsec_VTI_02_Remote_ |
+
+
+
+
+
+
+#### Command line policy-based forwarding - tunnel.2
+
+```bash
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 action forward nexthop ip-address CF_MWAN_IPsec_VTI_02_Remote
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 action forward egress-interface tunnel.2
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 from zone Trust_L3_Zone
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 enforce-symmetric-return enabled no
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 source VLAN0100_10-1-100-0--24
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 destination [ VLAN0010_10-1-10-0--24 VLAN0020_10-1-20-0--24 ]
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 source-user any
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 application any
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 service any
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 disabled no
+set rulebase pbf rules PBF_Magic_WAN_Sites_02 negate-destination no
+```
+
+## {props.productName} 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 {props.productName} 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 {props.productName} Protected Sites (using the Negate option).
+
+The following examples are based on Option 2.
+
+:::note
+
+This example assumes the security rules and policy-based forwarding rules from the previous sections have been configured and are directly above the rules configured in this section.
+
+Also, traffic from Trust to the Internet would typically be defined as `Trust_L3_Zone` to `Untrust_L3_Zone`. However, since egress Internet traffic will be routed through the Magic IPsec tunnels, the rule must reference `Trust_L3_Zone` to `Cloudflare_L3_Zone`.
+:::
+
+### Security Rule: Trust to Gateway Egress
+
+#### Dashboard
+
+| Name | Option | Value |
+| ------------------------------------ | ------------------- | ------------------------------------------------------------------------------ |
+| `Trust_to_MWAN_Gateway_Egress_Allow` | Rule Type | _universal (default)_ |
+| | Group Rules By Tag | _None_ |
+| **Source tab** | Source Zone | **Trust_L3_Zone** |
+| **Destination tab** | Destination Zone | **Cloudflare_L3_Zone** |
+| | Destination Address | **VLAN0010_10-1-10-0--24**
**VLAN0020_10-1-20-0--24**
**Negate** |
+| **Actions tab** | Action | _Allow_ |
+| | Log Setting | **Log at Session End** |
+| | Profile Type | _None_ |
+| | Schedule | _None_ |
+| | QoS Marking | _None_ |
+
+
+
+
+
+
+
+
+#### Command line
+
+```bash
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow to Cloudflare_L3_Zone
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow from Trust_L3_Zone
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow source any
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow destination [ VLAN0010_10-1-10-0--24 VLAN0020_10-1-20-0--24 ]
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow source-user any
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow category any
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow application any
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow service application-default
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow hip-profiles any
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow action allow
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow rule-type universal
+set rulebase security rules Trust_to_MWAN_Gateway_Egress_Allow negate-destination yes
+```
+
+### Policy-based forwarding: Trust to Gateway egress via tunnel.1
+
+#### Dashboard
+
+| Name | Option | Value |
+| --------------------------------------- | ------------------- | ------------------------------------------------------------------------------ |
+| `PBF_MWAN_Egress01` | Group Rules By Tag | _None_ |
+| **Source tab** | Source Zone | **Trust_L3_Zone** |
+| **Destination/Application/Service tab** | Destination Address | **VLAN0010_10-1-10-0--24**
**VLAN0020_10-1-20-0--24**
**Negate** |
+| **Forwarding tab** | Action | _Forward_ |
+| | Egress Interface | _tunnel.1_ |
+| | Next Hop | _IP Address_ |
+| | | _CF_MWAN_IPsec_VTI_01_Remote_ |
+
+
+
+
+
+
+#### Command line
+
+```bash
+set rulebase pbf rules PBF_MWAN_Egress_01 action forward nexthop ip-address CF_MWAN_IPsec_VTI_01_Remote
+set rulebase pbf rules PBF_MWAN_Egress_01 action forward egress-interface tunnel.1
+set rulebase pbf rules PBF_MWAN_Egress_01 from zone Trust_L3_Zone
+set rulebase pbf rules PBF_MWAN_Egress_01 enforce-symmetric-return enabled no
+set rulebase pbf rules PBF_MWAN_Egress_01 source VLAN0100_10-1-100-0--24
+set rulebase pbf rules PBF_MWAN_Egress_01 destination [ VLAN0010_10-1-10-0--24 VLAN0020_10-1-20-0--24 ]
+set rulebase pbf rules PBF_MWAN_Egress_01 source-user any
+set rulebase pbf rules PBF_MWAN_Egress_01 application any
+set rulebase pbf rules PBF_MWAN_Egress_01 service any
+set rulebase pbf rules PBF_MWAN_Egress_01 disabled no
+set rulebase pbf rules PBF_MWAN_Egress_01 negate-destination yes
+```
+
+### Policy-based forwarding: Trust to Gateway egress via tunnel.2
+
+#### Dashboard
+
+| Name | Option | Value |
+| --------------------------------------- | ------------------- | ------------------------------------------------------------------------------ |
+| `PBF_MWAN_Egress02` | Group Rules By Tag | _None_ |
+| **Source tab** | Source Zone | **Trust_L3_Zone** |
+| | Source Address | **VLAN0100_10-1-100-0--24** |
+| **Destination/Application/Service tab** | Destination Address | **VLAN0010_10-1-10-0--24**
**VLAN0020_10-1-20-0--24**
**Negate** |
+| **Forwarding tab** | Action | _Forward_ |
+| | Egress Interface | _tunnel.2_ |
+| | Next Hop | _IP Address_ |
+| | | _CF_MWAN_IPsec_VTI_02_Remote_ |
+
+
+
+
+
+
+#### Command line
+
+```bash
+set rulebase pbf rules PBF_MWAN_Egress_02 action forward nexthop ip-address CF_MWAN_IPsec_VTI_02_Remote
+set rulebase pbf rules PBF_MWAN_Egress_02 action forward egress-interface tunnel.2
+set rulebase pbf rules PBF_MWAN_Egress_02 from zone Trust_L3_Zone
+set rulebase pbf rules PBF_MWAN_Egress_02 enforce-symmetric-return enabled no
+set rulebase pbf rules PBF_MWAN_Egress_02 source VLAN0100_10-1-100-0--24
+set rulebase pbf rules PBF_MWAN_Egress_02 destination [ VLAN0010_10-1-10-0--24 VLAN0020_10-1-20-0--24 ]
+set rulebase pbf rules PBF_MWAN_Egress_02 source-user any
+set rulebase pbf rules PBF_MWAN_Egress_02 application any
+set rulebase pbf rules PBF_MWAN_Egress_02 service any
+set rulebase pbf rules PBF_MWAN_Egress_02 disabled no
+set rulebase pbf rules PBF_MWAN_Egress_02 negate-destination yes
+```
+
+## Troubleshooting
+
+Cloudflare recommends you consult [PAN-OS 9.1 Administrators Guide - Interpret VPN Error Messages](https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/vpns/set-up-site-to-site-vpn/interpret-vpn-error-messages) and [PAN-OS 10.2 Administrators Guide - Interpret VPN Error Messages](https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-admin/vpns/set-up-site-to-site-vpn/interpret-vpn-error-messages) for general troubleshooting.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/pfsense.mdx b/src/content/partials/networking-services/magic-wan/third-party/pfsense.mdx
new file mode 100644
index 00000000000000..653ac1028f2fe0
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/pfsense.mdx
@@ -0,0 +1,230 @@
+---
+params:
+ - productName
+ - configureTwoIpsecTunnelsUrl
+ - addTunnelsUrl
+ - staticRouteUrl
+---
+
+This tutorial includes the steps required to configure IPsec tunnels to connect a pfSense firewall to Cloudflare {props.productName}.
+
+## Software tested
+
+| Manufacturer | Firmware revision |
+| ------------ | ----------------- |
+| pfSense | 24.03 |
+
+## Prerequisites
+
+For this tutorial, you will need to know the following information:
+
+- Your Anycast IP addresses (given to you by Cloudflare)
+- External IP addresses
+- Internal IP address ranges
+- Inside tunnel `/31` ranges
+
+## Example scenario
+
+The following IP addresses are used throughout this tutorial. Any legally routable IP addresses have been replaced with IPv4 Address Blocks Reserved for Documentation ([RFC 5737](https://datatracker.ietf.org/doc/html/rfc5737)) addresses within the `203.0.113.0/24` subnet.
+
+| Tunnel name | `PF_TUNNEL_01` | `PF_TUNNEL_02` |
+| ---------------------------------- | ----------------------------- | ----------------------------- |
+| Interface address | `10.252.2.26/31` | `10.252.2.28/31` |
+| Customer endpoint | `203.0.113.254` | `203.0.113.254` |
+| Cloudflare endpoint | `` | `` |
+| Pfsense IPsec Phase 2 Local IP | `10.252.2.27` | `10.252.2.29` |
+| Pfsense IPsec Phase 2 Remote IP | `10.252.2.26` | `10.252.2.28` |
+| {props.productName} static routes - Prefix | `10.1.100.0/24` | `10.1.100.0/24` |
+| {props.productName} static routes - Next hop | `PF_TUNNEL_01` | `PF_TUNNEL_02` |
+
+## 1. Configure {props.productName} IPsec tunnels
+
+Use the Cloudflare dashboard or API to configure two IPsec tunnels. The settings mentioned below are used for the IPsec tunnels referenced throughout the remainder of this guide.
+
+### Add IPsec tunnels
+
+1. Follow the Add tunnels instructions to create the required IPsec tunnels with the following options:
+ - **Tunnel name**: `PF_TUNNEL_01`
+ - **Interface address**: `10.252.2.26/31`
+ - **Customer endpoint**: `203.0.113.254`
+ - **Cloudflare endpoint**: Enter the Anycast IP address provided by Cloudflare.
+ - **Health check rate**: _Medium_
+ - **Health check type**: _Request_
+ - **Health check direction**: _Bidirectional_
+ - **Turn on replay protection**: Enable
+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**: `PF_TUNNEL_02`
+ - **Interface address**: `10.252.2.28/31`
+ - **Customer endpoint**: `203.0.113.254`
+ - **Cloudflare endpoint**: Enter the Anycast IP address provided by Cloudflare.
+ - **Health check rate**: _Medium_
+ - **Health check type**: _Request_
+ - **Health check direction**: _Bidirectional_
+ - **Turn on replay protection**: Enable
+4. Select **Add pre-shared key later** > **Add tunnels**.
+
+:::note
+If site-to-site traffic is a requirement for your use case, you need to enable replay protection. Refer to Add tunnels > IPsec tunnel to learn how to enable this feature.
+:::
+
+### 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 IPsec tunnel you have created.
+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**.
+
+:::note
+Take note of your pre-shared keys, and keep them in a safe place to use later in pfSense.
+:::
+
+### IPsec identifier - User ID
+
+After creating your IPsec tunnels, the Cloudflare dashboard will list them under **Tunnels**. To retrieve your IPsec tunnel's user ID:
+
+1. Go to **{props.productName}** > **Configuration**.
+2. Select **Tunnels**.
+3. Select the IPsec tunnel.
+4. Scroll to **User ID** and copy the string. For example, `ipsec@long_string_of_letters_and_numbers`.
+
+The User ID will be required when configuring IKE Phase 1 on the pfSense firewall.
+
+## 2. Create {props.productName} static routes
+
+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 values):
+
+### Tunnel 01
+
+- **Description**: `PF_TUNNEL_01`
+- **Prefix**: `10.1.100.0/24`
+- **Tunnel/Next hop**: `PF_TUNNEL_01`
+
+### Tunnel 02
+
+- **Description**: `PF_TUNNEL_02`
+- **Prefix**: `10.1.100.0/24`
+- **Tunnel/Next hop**: `PF_TUNNEL_02`
+
+## 3. Configure the pfSense firewall
+
+Install pfSense and boot up. Then, assign and set LAN and WAN interfaces, as well as IP addresses. For example:
+
+- **LAN**: `203.0.113.254`
+- **WAN**: ``
+
+### Configure IPsec Phase 1
+
+Add a new IPsec tunnel [Phase 1 entry](https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure-p1.html), with the following settings:
+
+- **General Information**
+ - **Description**: `CF1_IPsec_P1`
+- **IKE Endpoint Configuration**
+ - **Key exchange version**: _IKE_v2_
+ - **Internet Protocol**: _IPv4_
+ - **Interface**: _WAN_
+ - **Remote gateway**: Enter your Cloudflare Anycast IP address.
+- **Phase 1 Proposal (Authentication)**
+ - **Authentication method**: _Mutual PSK_
+ - **My identifier**: _User Fully qualified domain name_ > `ipsec@long_string_of_letters_and_numbers`
(You can get this identifier from your Cloudflare IPsec tunnel configuration > **User ID**)
+ - **Peer identifier**: _Peer IP Address_ (your Cloudflare Anycast IP)
+ - **Pre-Shared Key**: Enter the PSK you have on your Cloudflare IPsec tunnel.
+- **Phase 1 proposal (Encryption algorithm)**
+ - **Encryption algorithm**: _AES 256 bits_
+ - **Key length**: _256 bits_
+ - **Hash algorithm**: _SHA256_
+ - **DH key group**: _20_
+ - **Lifetime**: `86400`
+
+
+### Configure IPsec Phase 2
+
+Add a new IPsec tunnel [Phase 2 entry](https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure-p2.html), with the following settings. You need to create an entry for tunnel 1 and 2, making the appropriate changes for the IP addresses for local and remote network:
+
+- **General Information**
+ - **Description**: `CF1_IPsec_P2`
+ - **Mode**: _Routed (VTI)_
+- **Networks**
+ - **Local Network**: _Address_ > Upper IP address in the `/31` assigned in Cloudflare tunnel. For example, `10.252.2.27` for tunnel 1 and `10.252.2.29` for tunnel 2.
+ - **Remote Network**: _Address_ > Lower IP address in the `/31` for Cloudflare side. For example, `10.252.2.26` for tunnel 1, and `10.252.2.28` for tunnel 2.
+- **Phase 2 Proposal (SA/Key Exchange)**
+ - **Protocol**: _ESP_
+ - **Encryption algorithm**: _AES 256 bits_
+ - **Hash algorithm**: _SHA256_
+ - **DH key group**: _20_
+ - **Lifetime**: `28800`
+
+When you are finished, apply your changes. If you go to **Status** > **IPsec**, you should be able to check that both Phase 1 and Phase 2 are connected.
+
+
+
+
+
+
+
+### Interface assignments
+
+In **Interfaces** > **Assignments** > **Add**, create a new interface to assign to the first IPsec tunnel, with the following settings:
+
+- **General configuration**
+ - **Description**: `CF1_IPsec_1`
+ - **MSS**: `1446`
+- **Interface Assignments**
+ - **WAN**: Add your WAN interface. For example, `vnet1`.
+ - **LAN**: Add your LAN interface. For example, `vnet0`.
+ - Add your **CF_IPsec_1** that you have created above for Phase 1.
+
+Select **Save** when you are finished.
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Gateway
+
+In **System** > **Routing** > **Gateways** there should already be a gateway. For this example, it is named `CF1_IPSEC_1_VTIV4`.
+
+
+
+
+
+
+
+### Firewall Rules IPsec
+
+1. In **Firewall Rules** > **IPsec interface**, allow any type of traffic.
+
+
+
+
+
+
+
+2. Navigate to **Status** > **Gateways**. `CF1_IPSEC_1_VTIV4` should now be online.
+
+
+
+
+
+
+
+### Firewall Rules LAN
+
+1. In **Firewall** > **Rules** > **LAN**, allow any type of traffic.
+2. Expand the **Advanced** section.
+3. Change the Gateway to `CF1_IPSEC_1_VTIV4`.
+
+
+
+
+
+
diff --git a/src/content/partials/networking-services/magic-wan/third-party/sonicwall.mdx b/src/content/partials/networking-services/magic-wan/third-party/sonicwall.mdx
new file mode 100644
index 00000000000000..19e82c09b354d7
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/sonicwall.mdx
@@ -0,0 +1,207 @@
+---
+params:
+ - productName
+ - ipsecTunnelsUrl
+ - creatingYourIpsecTunnelsUrl
+ - createYourStaticRoutesUrl
+ - configureMagicWanHealthChecksUrl
+ - checkTunnelHealthInTheDashboardUrl
+---
+
+import { Render } from "~/components";
+
+This tutorial shows you how to use {props.productName} with the following versions of the SonicWall appliances:
+
+- **Hardware tested**:
+ - SonicWall NSv 470
+ - SonicWal 3700
+- **Software versions tested**:
+ - SonicOS 7.0.1
+
+You can connect your SonicWall appliance through IPsec tunnels to {props.productName}. Generic Routing Encapsulation (GRE) is not supported on SonicWall.
+
+## Topology
+
+
+
+The following instructions show how to setup an IPsec connection on your SonicWall device. We will use the IP ranges from the above topology example to create the connections needed. Settings not explicitly mentioned can be left with their default values.
+
+## 1. Create an IPsec tunnel on your Cloudflare account
+
+1. Start by creating your IPsec tunnels on Cloudflare. Name and describe the tunnels as needed, and add the following settings:
+
+ - **Interface address**: Enter the internal tunnel IP on the Cloudflare side of the IPsec tunnel. In this example, it is `10.200.1.0/31`.
+ - **Customer endpoint**: Enter the WAN IP address of your SonicWall device. In our example, this is `198.51.100.2`.
+ - **Cloudflare endpoint**: Enter the IP address provided by Cloudflare. In our example, this is `1.2.3.4`.
+ - **Pre-shared key**: Select **Use my own pre-shared key** and paste a secure key of your own.
+
+2. Select **Add tunnels** when you are finished.
+
+3. After you create your tunnel, Cloudflare dashboard will load a list of tunnels set up for your account. Select the arrow to expand the tunnels you have just created, and check the following settings:
+
+ - **Customer endpoint**: Refers to the SonicWall WAN IP that the VPN policy is bound to (in red).
+ - **Cloudflare endpoint**: Refers to the anycast IP provided by Cloudflare (in blue).
+ - **FQDN ID**: The ID used in the VPN policy for the SonicWall's Local IKE ID. Copy this ID and save it. You will need it when configuring the tunnel on your SonicWall (in green).
+
+ 
+
+:::note
+The interface address on the Cloudflare side of the tunnel is `10.200.1.0/31`. You will need to use `10.200.1.1/31` on the SonicWall side of the tunnel.
+:::
+
+## 2. Create static routes on Cloudflare dashboard
+
+Static routes are required for any networks that will be reached via the IPsec tunnel. In our example, there are two networks: `172.31.3.0/24` and the tunnel network `10.200.1.0/31`.
+
+1. Create your static routes. Name and describe them as needed, and add the following settings:
+
+ - **First tunnel**: Following our example, add `10.200.1.0/31` as the **Prefix** and `10.200.1.1` for the **Tunnel/Next hop**.
+ - **Second tunnel**: Following our example, add `172.31.3.0/24` as the **Prefix** and `10.200.1.1` for the **Tunnel/Next hop**.
+
+2. Select **Add routes** when you are finished.
+
+## 3. Add a VPN configuration in SonicWall
+
+1. Go to **Network** > **IPsec VPN** > **Rules and Settings**.
+2. Select **Add**.
+3. In **General** > **Security Policy** group, add the following settings:
+ - **Authentication Method**: _IKE Using Preshared Secret_.
+ - **IPsec Primary Gateway Name or Address**: Enter Cloudflare's anycast IP address for the primary gateway (in blue).
+4. In the **IKE Authentication** group, add the following settings:
+ - **Shared secret**: Paste the pre-shared key you use to create the IPsec tunnel in step 1 (in purple).
+ - **Local IKE ID**: Select _Domain name_ from the dropdown menu, and paste here the **FQDN ID** you saved from step 1, after creating the IPsec tunnel (in green).
+ - **Peer IKE IDE**: Select _IPv4_ Address from the dropdown menu, and enter the Cloudflare anycast IP address (in blue).
+
+
+
+
+
+
+
+5. Select **Proposals**. VPN Policy is somewhat flexible. Adjust these settings to match your organization's preferred security policy. As an example, you can use the settings in the examples below.
+6. In the **IKE (Phase 1) Proposal** group, select the following settings:
+ - **Exchange**: _IKEv2 Mode_
+ - **DH Group**: _Group 20_
+ - **Encryption**: _AES-256_
+ - **Authentication**: _SHA256_
+ - **Life Time (seconds)**: `86400`
+7. In the **IPsec (Phase 2) Proposal** group, add the following settings:
+ - **Protocol**: _ESP_
+ - **Encryption**: _AESGCM16-256_
+ - **Authentication**: _None_
+ - **Enable Perfect Forward Secrecy**: Enabled
+ - **DH Group**: _Group 20_
+ - **Life Time (seconds)**: `28800`
+8. Select **Advanced**.
+9. Enable **Disable IPsec Anti-Replay**.
+10. In **VPN Policy bound to** select your WAN interface from the dropdown menu, to bind it to your VPN.
+11. Select **Save**.
+
+
+
+
+
+
+
+## 4. Add a VPN tunnel interface
+
+SonicOS requires a VPN tunnel interface to route traffic via {props.productName}. When creating the interface, use the prefix `10.200.1.1/31`. This matches with the Cloudflare side for this tunnel, which is `10.200.1.0`.
+
+:::note
+You will need to use a different IP pair for each tunnel/site.
+:::
+
+1. Go to **Network** > **System** > **Interfaces**.
+2. Select **Add interface** > **VPN Tunnel Interface**.
+3. For IP Address, use `10.200.1.1`.
+4. Enable **Ping**. This is required so the interface can be pinged for debugging and {props.productName} health checks.
+
+
+
+
+
+
+
+5. Select **Advanced**.
+6. Enable the **Enable Asymmetric Route Support** option. This is required for the {props.productName} tunnel health check.
+
+
+
+
+
+
+
+7. Select **OK**.
+
+## 5. Add address object(s)
+
+Address objects are necessary for route policies. In our example, we have one other site that will be reached via {props.productName}. First, you need to create address objects for each network. Then, you need to create an address group that contains all the remote networks. This address group will be used in the next step to create the correct route policies.
+
+To add an address object:
+
+1. Select **Object** > **Match Objects** > **Addresses**.
+2. Select **Address Objects** > **Add**.
+3. Enter the information for your address object - refer to the topology image for the examples this tutorial is using. Since the addresses are in the VPN zone, set the **Zone Assignment** for the object to _VPN_.
+4. Select **Save**. The window will stay on to facilitate multiple entries. Select **X** to close it.
+
+
+
+
+
+
+
+5. Select **Address Groups** > **Add** to add a new address group.
+6. Enter a **Name** for your address group.
+7. Select the individual network objects you have created on the left menu, and add them to the group by selecting the right-facing arrow in the middle column.
+8. Select **Save**.
+
+
+
+
+
+
+
+## 6. Set up routing
+
+Add a route using the address object or group just created as the destination.
+
+1. Select **Policy** > **Rules and Policies** > **Routing Rules**.
+2. Select **Add** to add your route policy.
+3. The **Next Hop** should be the VPN tunnel interface that was previously created in the interface panel.
+
+## 7. Add access rule for health checks
+
+An additional access rule is required for {props.productName} health checks to work properly. This will enable the WAN IP to receive ICMP pings via the tunnel, and return them over the WAN.
+
+1. Select **Policy** > **Rules and Policies**.
+2. Select **Access Rules** > **Add**.
+3. Enter a descriptive name for your policy.
+4. In **Source / Destination** > **Destination > Port/Services**, select _ICMP_ from the dropdown.
+5. Select **Optional Settings**.
+6. In **Others**, enable **Allow Management traffic**.
+
+## 8. Setup health checks
+
+You have to [configure {props.productName} health checks](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/#add-tunnels) correctly. Here is an example of how to set up health checks:
+
+```bash
+curl --request PUT \
+https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels/{tunnel_id} \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "health_check": {
+ "direction": "bidirectional",
+ "enabled": true,
+ "type": "request",
+ "rate": "low"
+ }
+}'
+```
+
+Health checks might take some time to stabilize after the configuration is changed.
+
+## 9. Verify tunnel status on Cloudflare dashboard
+
+The Cloudflare dashboard monitors the health of all anycast tunnels on your account that route traffic from Cloudflare to your origin network. Refer to Check tunnel health in the dashboard for more information.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/sophos-firewall.mdx b/src/content/partials/networking-services/magic-wan/third-party/sophos-firewall.mdx
new file mode 100644
index 00000000000000..d060797bee9936
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/sophos-firewall.mdx
@@ -0,0 +1,268 @@
+---
+params:
+ - productName
+ - genericRoutingEncapsulationGreOrIpsecTunnelsUrl
+ - ikeIdUrl
+ - configureTunnelEndpointsUrl
+ - checkTunnelHealthInTheDashboardUrl
+---
+
+import { Render } from "~/components";
+
+This tutorial shows you how to use {props.productName} with the following versions of the Sophos Firewall:
+
+- **Sophos form factor tested:**
+
+ - Sophos Firewall XGS and XG series hardware
+ - Sophos Firewall virtual appliance on VMware
+
+- **Sophos software versions tested:**
+ - SFOS Version 19.0 MR2-Build 472
+ - SFOS Version 19.5.1 MR1-Build 278
+
+You can connect through Generic Routing Encapsulation (GRE) or IPsec tunnels to {props.productName}.
+
+## IPsec connection
+
+The following instructions show how to setup an IPsec connection on your Sophos Firewall device. Settings not explicitly mentioned can be left with their default values.
+
+### 1. Add an IPsec profile
+
+1. Go to **System** > **Profiles**.
+2. In **IPsec profiles**, select **Add**.
+3. In the **General settings** group, make sure you have the following settings:
+ - **Name**: Give your profile a descriptive name.
+ - **Key exchange**: **IKEv2**
+ - **Authentication mode**: **Main mode**
+4. In the **Phase 1** group, make sure you have the following settings:
+ - **DH group (key group)**: _20_
+ - **Encryption**: _AES256_
+ - **Authentication**: _SHA2 256_
+5. In the **Phase 2** group, select the following:
+ - **PFS group (DH group)**: _Same as phase-1_
+ - **Key life**: _28800_
+ - **Encryption**: _AES256_
+ - **Authentication**: _SHA2 256_
+6. Enable **Dead Peer Detection**.
+7. In **When peer unreachable**, select _Re-initiate_.
+8. Select **Save**.
+
+### 2. Create IPsec connection tunnel
+
+The next step involves configuring a site-to-site IPsec VPN connection on your Sophos Firewall device.
+
+1. Go to **Configure** > **Site-to-site VPN**.
+2. In **IPsec**, select **Add**.
+3. In the **General settings** group, make sure you have the following settings:
+ - **Name**: Give your site-to-site VPN a descriptive name.
+ - **Connection type**: _Tunnel interface_
+ - **Gateway type**: _Initiate the connection_
+4. In the **Encryption** group, make sure you have the following settings:
+ - **Authentication type**: **Preshared key**
+5. In **Gateway settings**, make sure you have the following settings:
+ - **Gateway address**: Enter your Cloudflare anycast IP address provided by Cloudflare.
+ - **Local ID type**: Add the IKE ID provided by Cloudflare.
+
+
+
+After setting up your IPsec tunnel, it will show up on the IPsec connections list with an **Active** status.
+
+
+
+### 3. Assign the XFRM interface address
+
+You must use an interface address from the `/31` subnet required to configure tunnel endpoints on {props.productName}.
+
+1. Go to **Configure** > **Network**.
+2. In **Interfaces**, select the corresponding interface to the IPsec tunnel you created in [step 2](#2-create-ipsec-connection-tunnel).
+3. Edit the interface to assign an address from the `/31` subnet required to configure tunnel endpoints. When you are finished, it should look similar to the following:
+
+
+
+### 4. Add a firewall rule
+
+1. Go to **Protect** > **Rules and policies**.
+2. In **Firewall rules**, create a firewall rule with the criteria and security policies from your company that allows traffic to flow between Sophos and {props.productName}.
+
+
+
+### 5. Disable IPsec anti-replay
+
+You will have to disable IPsec Anti-Replay on your Sophos Firewall. Changing the anti-replay settings restarts the IPsec service, which causes tunnel-flap for all IPsec tunnels. This will also disable IPsec anti-replay protection for all VPN connections globally. Plan these changes accordingly.
+
+Below are instruction on how to achieve this on SFOS version 19 and SFOS version 19.5:
+
+#### SFOS 19.0 MR2-Build 472 or 19.5 MR1-Build278 or later versions:
+
+1. Sign in to the CLI.
+2. Enter **4** to choose **Device console**, and enter the following command:
+
+ ```bash
+ set vpn ipsec-performance anti-replay window-size 0
+ ```
+
+ 
+
+#### Older SFOS versions
+
+Contact Sophos support.
+
+## GRE connection
+
+### 1. Configure a GRE tunnel between SFOS and Cloudflare
+
+Start by configuring a GRE tunnel between SFOS and the Cloudflare anycast IP address.
+
+1. Sign in to the CLI.
+2. Enter **4** to choose **Device console**, and enter the following command:
+
+ ```bash
+ system gre tunnel add name local-gw remote-gw local-ip remote-ip
+ ```
+
+ 
+
+ For more details, refer to the [Sophos Firewall knowledge base](https://support.sophos.com/support/s/article/KB-000035813?language=en_US).
+
+### 2. Add a GRE or SD-WAN route to redirect traffic through the GRE tunnel
+
+The detailed information on how to add a GRE or SD-WAN route to redirect traffic through the GRE tunnel, is in the next section ([Traffic redirection mechanism on Sophos Firewall](#traffic-redirection-mechanism-on-sophos-firewall)).
+
+### 3. Add a firewall rule for LAN/DMZ to VPN
+
+Create a firewall rule with the criteria and security policies from your company that allows traffic to flow between Sophos and {props.productName}. This firewall rule should include the required networks and services.
+
+1. Go to **Protect** > **Rules and policies**.
+2. In **Firewall rules**, select **IPv4** > **Add firewall rule**.
+
+
+
+## Traffic redirection mechanism on Sophos Firewall
+
+To redirect traffic, you can add a static or an SD-WAN route.
+
+### IPsec
+
+#### Static route
+
+Go to **Configure** > **Routing** > **Static routes** to add an XFRM interface-based route. The interface will be automatically created when you set up a tunnel interface based on IPsec (such as the Cloudflare_MWAN example from above).
+
+
+
+#### SD-WAN route
+
+1. Go to **Configure** > **Routing** > **Gateways** to create a custom gateway on the XFRM interface. The interface will be automatically created when you set up a tunnel interface based on IPsec (such as the Cloudflare_MWAN example from above).
+
+
+
+2. In **Configure** > **Routing** > **SD-WAN routes**, select **Add** to add the desired networks and services in the route to redirect traffic to Cloudflare. Enter a descriptive name for your connection, and the IP addresses you set up for your IPsec tunnels in **Incoming interface** and **Source networks**. Do not forget to choose the correct **Primary gateway** option.
+
+
+
+### GRE
+
+Add a GRE or SD-WAN route or both.
+
+#### GRE route
+
+Add the route on the CLI.
+
+1. Sign in to the CLI.
+2. Enter **4** to choose **Device console**, and enter the following command to create the tunnel:
+
+```bash
+system gre route add net tunnelname
+```
+
+
+
+#### SD-WAN route
+
+1. Add a custom gateway on GRE with the peer IP address (from the `/31` subnet you chose earlier) as the Gateway IP address, and disable **Health check**.
+
+
+
+2. Add an SD-WAN route with the desired networks and services in the route to redirect traffic to Cloudflare.
+
+
+
+## Verify tunnel status on Cloudflare dashboard
+
+The Cloudflare dashboard monitors the health of all anycast tunnels on your account that route traffic from Cloudflare to your origin network. Refer to Check tunnel health in the dashboard for more information.
+
+### Make Cloudflare health checks work
+
+1. The ICMP probe packet from Cloudflare must be the type ICMP request, with anycast source IP. In the following example, we have used `172.64.240.252` as a target example:
+
+```bash
+curl --request PUT \
+https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels/{tunnel_id} \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "health_check": {
+ "enabled": true,
+ "target": "172.64.240.252",
+ "type": "request",
+ "rate": "mid"
+ }
+}'
+```
+
+2. Go to **Configure** > **Network** > **Interfaces** > **Add alias**. Add the IP address provided by Cloudflare for the ICMP probe traffic. This is needed to prevent Sophos firewall from dropping them as spoof packets. This is not the same IP used to create VPN. This is the special IP address for probe traffic only.
+
+
+
+3. ICMP reply from SFOS should go back via the same tunnel on which the probe packets are received. You will need to create an additional SD-WAN policy route.
+
+
+
+Packet flow will look like the following:
+
+```sh
+tcpdump -nn proto 1
+```
+
+```sh output
+tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
+listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
+
+13:09:55.500453 xfrm1, IN: IP 172.70.51.31 > 172.64.240.252: ICMP echo request, id 33504, seq 0, length 64
+13:09:55.500480 xfrm1, OUT: IP 172.64.240.252 > 172.70.51.31: ICMP echo reply, id 33504, seq 0, length 64
+
+13:09:55.504669 xfrm1, IN: IP 172.71.29.66 > 172.64.240.252: ICMP echo request, id 60828, seq 0, length 64
+13:09:55.504695 xfrm1, OUT: IP 172.64.240.252 > 172.71.29.66: ICMP echo reply, id 60828, seq 0, length 64
+```
+
+## Verify tunnel status on Sophos Firewall dashboard
+
+### IPsec
+
+When the tunnel is working, its **Status** will be green.
+
+
+
+The corresponding XFRM interface will also show a **Connected** status.
+
+
+
+### GRE
+
+Access the CLI and type `system gre tunnel show` to check the status of a GRE tunnel. When the tunnel is working, its Status will show up as **Enabled**.
+
+
+
+
+
+## Troubleshooting
+
+If a tunnel shows a connected status at both ends, but is not established:
+
+- Check if the IPsec profile configuration is correct.
+- Make sure the corresponding tunnel interfaces are up.
+- Make sure routing configuration and route precedence are correctly set on SFOS.
+- Make sure a static back route is added on Cloudflare.
+- Firewall rules for specific zones and host or service must be added in SFOS. GRE and IPsec belong to the VPN zone.
+- Perform `tcpdump` to check if packets are going through the VPN or GRE tunnel as expected.
+- Perform a packet capture on Cloudflare to see if traffic is reaching the Cloudflare platform.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/strongswan.mdx b/src/content/partials/networking-services/magic-wan/third-party/strongswan.mdx
new file mode 100644
index 00000000000000..70b73cdb92a30b
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/strongswan.mdx
@@ -0,0 +1,199 @@
+---
+params:
+ - productName
+ - bidirectionalHealthChecksUrl
+---
+
+This tutorial explains how to set up strongSwan along with {props.productName}. You will learn how to configure strongSwan, configure an IPsec tunnel and create a Policy Based Routing.
+
+## 1. Health checks configuration
+
+Start by configuring the bidirectional health checks target for {props.productName}. For this particular tutorial, we are using `172.64.240.252` as the target IP address, and `type` as the request.
+
+This can be set up [with the API](/api/resources/magic_transit/subresources/ipsec_tunnels/methods/update/). For example:
+
+```bash
+curl --request PUT \
+https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/ipsec_tunnels/{tunnel_id} \
+--header "X-Auth-Email: " \
+--header "X-Auth-Key: " \
+--header "Content-Type: application/json" \
+--data '{
+ "health_check": {
+ "enabled": true,
+ "target": "172.64.240.252",
+ "type": "request",
+ "rate": "mid"
+ }
+}'
+```
+
+## 2. Configure StrongSwan
+
+1. Start by [installing StrongSwan](https://docs.strongswan.org/docs/5.9/install/install.html). For example, open the console and run:
+
+```sh
+sudo apt-get install strongswan -y
+```
+
+2. After StrongSwan finishes installing, go to `/etc/strongswan.conf` to edit the configuration file and add the following settings:
+
+```txt
+charon {
+ load_modular = yes
+ install_routes = no
+ install_virtual_ip = no
+
+ plugins {
+ include strongswan.d/charon/*.conf
+ }
+}
+
+include strongswan.d/*.conf
+```
+
+## 3. Configure IPsec file
+
+1. Go to `/etc/ipsec.conf` and add the following settings:
+
+```txt
+# ipsec.conf - strongSwan IPsec configuration file
+config setup
+ charondebug="all"
+ uniqueids = yes
+
+conn %default
+ ikelifetime=24h
+ rekey=yes
+ reauth=no
+ keyexchange=ikev2
+ authby=secret
+ dpdaction=restart
+ closeaction=restart
+
+# Sample VPN connections
+conn cloudflare-ipsec
+ auto=start
+ type=tunnel
+ fragmentation=no
+ leftauth=psk
+ # Private IP of the VM
+ left=%any
+ # Tunnel ID from dashboard, in this example FQDN is used
+ leftid=..ipsec.cloudflare.com
+ leftsubnet=0.0.0.0/0
+ # Cloudflare Anycast IP
+ right=
+ rightid=
+ rightsubnet=0.0.0.0/0
+ rightauth=psk
+ ike=aes256-sha256-ecp384!
+ esp=aes256-sha256-ecp384!
+ replay_window=0
+ mark_in=42
+ mark_out=42
+ leftupdown=/etc/strongswan.d/ipsec-vti.sh
+```
+
+2. Now, you need to create a virtual tunnel interface (VTI) with the IP we configured earlier as the target for Cloudflare's health checks (`172.64.240.252`) to route IPsec packets. Go to `/etc/strongswan.d/`.
+
+3. Create a script called `ipsec-vti.sh` and add the following:
+
+```txt
+#!/bin/bash
+
+set -o nounset
+set -o errexit
+
+VTI_IF="vti0"
+
+case "${PLUTO_VERB}" in
+ up-client)
+ ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti \
+ key "${PLUTO_MARK_OUT%%/*}"
+ ip link set "${VTI_IF}" up
+ ip addr add 172.64.240.252/32 dev vti0
+ sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1"
+ sysctl -w "net.ipv4.conf.${VTI_IF}.rp_filter=0"
+ sysctl -w "net.ipv4.conf.all.rp_filter=0"
+ ip rule add from 172.64.240.252 lookup viatunicmp
+ ip route add default dev vti0 table viatunicmp
+ ;;
+ down-client)
+ ip tunnel del "${VTI_IF}"
+ ip rule del from 172.64.240.252 lookup viatunicmp
+ ip route del default dev vti0 table viatunicmp
+ ;;
+esac
+echo "executed"
+```
+
+## 4. Add Policy Based Routing (PBR)
+
+Although the IPsec tunnel is working as is, we need to create Policy Based Routing (PBR) to redirect returning traffic via the IPsec tunnel. Without it, the ICMP replies to the health probes sent by Cloudflare will be returned via the Internet, instead of the same IPsec tunnel. This is required to avoid any potential issues.
+
+To accomplish this, the tutorial uses [iproute2](https://en.wikipedia.org/wiki/Iproute2) to route IP packets from `172.63.240.252` to the tunnel interface.
+
+1. Go to `/etc/iproute2/`.
+
+2. Edit the `rt_tables` file to add a routing table number and name. In this example, we used `viatunicmp` as the name and `200` as the number for the routing table.
+
+```txt
+#
+# reserved values
+#
+255 local
+254 main
+253 default
+0 unspec
+200 viatunicmp
+#
+# local
+#
+#1 inr.ruhep
+```
+
+3. Open the console and add a rule to match the routing table just created. This rule instructs the system to use routing table `viatunicmp` if the packet's source address is `172.64.240.252`:
+
+```sh
+ip rule add from 172.64.240.252 lookup viatunicmp
+```
+
+4. Add a route to the newly created routing table `viatunicmp`. This is the default route via the interface `vti0` in the `viatunicmp` table.
+
+```sh
+ip route add default dev vti0 table viatunicmp
+```
+
+5. Now, you can `start` IPsec. You can also `stop`, `restart` and show the `status` for the IPsec connection:
+
+```bash
+ipsec start
+```
+
+```bash output
+Security Associations (1 up, 0 connecting):
+cloudflare-ipsec[1]: ESTABLISHED 96 minutes ago, .ipsec.cloudflare.com]...162.159.67.88[162.159.67.88]
+cloudflare-ipsec{4}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c4e20a95_i c5373d00_o
+cloudflare-ipsec{4}: 0.0.0.0/0 === 0.0.0.0/0
+```
+
+## 5. Check connection status
+
+After you finish configuring StrongSwan with {props.productName}, you can use tcpdump to investigate the status of health checks originated from Cloudflare.
+
+```sh
+sudo tcpdump -i esp and host
+```
+
+In this example, the outgoing Internet interface shows that the IPsec encrypted packets (ESP) from Cloudflare's health check probes (both the request and response) are going through the IPsec tunnel we configured.
+
+
+
+You can also run tcpdump on `vti0` to check the decrypted packets.
+
+```sh
+sudo tcpdump -i vti0 host 172.64.240.252
+```
+
+
diff --git a/src/content/partials/networking-services/magic-wan/third-party/viptela.mdx b/src/content/partials/networking-services/magic-wan/third-party/viptela.mdx
new file mode 100644
index 00000000000000..404d0c6dfb4903
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/viptela.mdx
@@ -0,0 +1,102 @@
+---
+params:
+ - productName
+ - configureTunnelEndpointsUrl
+ - configureStaticRoutesUrl
+ - ciscoIosXeUrl
+---
+
+Cloudflare partners with Cisco's SD-WAN solution to provide users with an integrated SASE solution. The Cisco SD-WAN appliances (physical and virtual) manage subnets associated with branch offices and cloud instances. Anycast Tunnels are set up between these SD-WAN edge devices and Cloudflare to securely route Internet-bound traffic. This tutorial describes how to configure the Cisco Catalyst 8000 Edge Platforms (physical or virtual) in the SD-WAN mode for north-south (Internet-bound) use cases.
+
+## Prerequisites
+
+Before setting up a connection between Cisco SD-WAN and Cloudflare, you must have:
+
+- Purchased {props.productName} and Secure Web Gateway.
+- Cloudflare provision {props.productName} and Secure Web Gateway.
+- Received two Cloudflare tunnel endpoints (anycast IP address) assigned to {props.productName}.
+- Cisco SD-WAN appliances (physical or virtual). This ensures specific Internet-bound traffic from the sites' private networks is routed over the anycast GRE tunnels to Secure Web Gateway to enforce a user's specific web access policies.
+- A static IP pair to use with the tunnel endpoints. The static IPs should be /31 addresses separate from the IPs used in the subnet deployment.
+- Release 20.6 Controllers and vEdge Device Builds. You should also pair them with devices that are on at least version Cisco IOS XE SD-WAN 17.6. Refer to [Cisco documentation](https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/215676-cisco-tac-and-bu-recommended-sd-wan-soft.html) to learn more Cisco softweare versions.
+
+:::note[Note]
+The SASE integration between Cisco SD-WAN and Cloudflare SSE was validated with Cisco SD-WAN 20.6.2 version with Catalyst 8kv router. For connectivity, we used GRE tunnels.
+:::
+
+## 1. Create a SIG template on Cisco vManage
+
+Cisco vManage is Cisco's SD-WAN management tool that is used to manage all the SD-WAN appliances in branch offices.
+
+For this example scenario, a generic template for `SIG-Branch` was created.
+
+
+
+To create a Secure Internet Gateway (SIG) using vManage:
+
+1. From **Cisco vManage** under **Configuration**, select **Generic** and **Add Tunnel**.
+2. Refer to the table below for the setting fields and their options.
+
+| Setting | Type/Detail |
+| ------------------- | ----------------------------------------- |
+| **Global Template** | Factory_Default_Global_CISCO_Template |
+| **Cisco Banner** | Factory_Default_Retail_Banner |
+| **Policy** | Branch-Local-Policy |
+
+**Transport & Management VPN settings**
+
+| Setting | Type/Detail |
+| --------------------------------- | ----------------------------------- |
+| **Cisco VPN 0** | GCP-Branch-VPN0 |
+| **Cisco Secure Internet Gateway** | Branch-SIG-GRE-Template |
+| **Cisco VPN Interface Ethernet** | GCP-Branch-Public-Internet-TLOC |
+| **Cisco VPN Interface Ethernet** | GCP-VPN0-Interface |
+| **Cisco VPN 512** | Default_AWS_TGW_CSR_VPN512_V01 |
+
+**Basic Information settings**
+
+| Setting | Type/Detail |
+| ------------------ | ------------------------------------------- |
+| **Cisco System** | Default_BootStrap_Cisco_System_Template |
+| **Cisco Logging** | Default_Logging_Cisco_V01 |
+| **Cisco AAA** | AWS-Branch-AAA-Template |
+| **Cisco BFD** | Default_BFD_Cisco-V01 |
+| **Cisco OMP** | Default_AWS_TGW_CSR_OMP_IPv46_... |
+| **Cisco Security** | Default_Security_Cisco_V01 |
+
+When creating the Feature Template, you can choose values that apply globally or that are device specific. For example, the **Tunnel Source IP Address**, **Interface Name** and fields from **Update Tunnel** are device specific and should be chosen accordingly.
+
+## 2. Create tunnels in vManage
+
+From vManage, select **Configuration** > **Templates**. You should see the newly created template where you will update the device values.
+
+Because the template was created to add GRE tunnels, you only need to update the device values. Note that **VPN0** is the default, and the WAN interface used to build the tunnel must be part of **VPN0**.
+
+
+
+## 3. Create tunnels in Cloudflare
+
+Refer to Configure tunnel endpoints for more information on creating a GRE tunnel.
+
+
+
+## 4. Define static routes
+
+Refer to Configure static routes for more information on configuring your static routes.
+
+
+
+## 5. Validate traffic flow
+
+In the example below, a request for `neverssl.com` was issued, which has a Cloudflare policy blocking traffic to `neverssl`.com.
+
+On the client VM (192.168.30.3), a blocked response is visible.
+
+
+
+A matching blocked log line is visible from the Cloudflare logs.
+
+
+
+## Add new tunnels using IPsec
+
+IPsec tunnels to Cloudflare can only be created on Cisco 8000v in the router mode today. Refer to the Cisco IOS XE for more information.
diff --git a/src/content/partials/networking-services/magic-wan/third-party/vyos.mdx b/src/content/partials/networking-services/magic-wan/third-party/vyos.mdx
new file mode 100644
index 00000000000000..8005745148379f
--- /dev/null
+++ b/src/content/partials/networking-services/magic-wan/third-party/vyos.mdx
@@ -0,0 +1,72 @@
+---
+{}
+---
+
+This tutorial contains configuration information and a sample template for using a VyOS device with an IPsec configuration.
+
+## Notes
+
+- `vti ` - Defines the ESP group for encrypted traffic defined by the tunnel or defines a particular ESP policy or profile.
+- `ike-group ` - Defines IKE group to use for key exchanges or defines a particular IKE policy or profile.
+- The IP addresses of the IPsec tunnel interfaces on both ends of the tunnel should be a pair of private IP addresses (RFC 1918) on the same `/31` or `/30` subnet, essentially specifying a point-to-point link.
+- The IPsec tunnel endpoint on this VyOS router is the ``.
+- The IP address of the IPsec tunnel endpoint on the Cloudflare side is the anycast IP address provided by Cloudflare.
+- This router is configured to initiate the IPsec tunnel connection.
+
+## Configuration parameters
+
+### Phase 1
+
+- **Encryption**
+ - AES-GCM with 128-bit or 256-bit key length
+
+- **Integrity**
+ - SHA512
+
+### Phase 2
+
+- **Encryption**
+ - AES-GCM with 128-bit or 256-bit key length
+
+- **Integrity**
+ - SHA512
+
+- **PFS group**
+ - DH group 20 (348-bit random ECP group)
+
+## Configuration template
+
+```bash
+set interfaces vti address
+''
+set vpn ipsec esp-group compression 'disable'
+set vpn ipsec esp-group lifetime '86400'
+set vpn ipsec esp-group mode 'tunnel'
+set vpn ipsec esp-group pfs 'enable'
+set vpn ipsec esp-group proposal 1 encryption 'aes256gcm128'
+set vpn ipsec esp-group proposal 1 hash 'sha512'
+set vpn ipsec ike-group close-action 'none'
+set vpn ipsec ike-group dead-peer-detection action 'restart'
+set vpn ipsec ike-group dead-peer-detection interval '30'
+set vpn ipsec ike-group dead-peer-detection timeout '120'
+set vpn ipsec ike-group ikev2-reauth 'no'
+set vpn ipsec ike-group key-exchange 'ikev2'
+set vpn ipsec ike-group lifetime '28800'
+set vpn ipsec ike-group mobike 'disable'
+set vpn ipsec ike-group proposal 1 dh-group '20'
+set vpn ipsec ike-group proposal 1 encryption 'aes256gcm128'
+set vpn ipsec ike-group proposal 1 hash 'sha512'
+set vpn ipsec ipsec-interfaces interface ''
+set vpn ipsec logging log-level '2'
+set vpn ipsec options disable-route-autoinstall
+set vpn ipsec site-to-site peer authentication id ''
+set vpn ipsec site-to-site peer authentication pre-shared-secret ''
+set vpn ipsec site-to-site peer authentication remote-id ''
+set vpn ipsec site-to-site peer connection-type 'initiate'
+set vpn ipsec site-to-site peer ike-group ''
+set vpn ipsec site-to-site peer ikev2-reauth 'no'
+set vpn ipsec site-to-site peer local-address ''
+set vpn ipsec site-to-site peer vti bind ''
+set vpn ipsec site-to-site peer vti esp-group ''
+```