Aruba EdgeConnect Enterprise

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.

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 Open external link 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 Open external link 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).

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. 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 Open external link .

• 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

Request
curl -X POST "https://api.cloudflare.com/client/v4/accounts/<account_id>/magic/ipsec_tunnels?validate_only=true" \
     -H "X-Auth-Email: user@example.com" \
     -H "X-Auth-Key: XXXXXXXXXX" \
     -H "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

Request
curl -X POST "https://api.cloudflare.com/client/v4/accounts/<account_id>/magic/ipsec_tunnels" \
     -H "X-Auth-Email: user@example.com" \
     -H "X-Auth-Key: XXXXXXXXXX" \
     -H "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"}]}'

Response
{
"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.

Request
curl -X POST "https://api.cloudflare.com/client/v4/accounts/<account_id>/magic/ipsec_tunnels/e70536b11daa47e09ff046fbb9800e4f/psk_generate?validate_only=true" \
     -H "X-Auth-Email: user@example.com" \
     -H "X-Auth-Key: XXXXXXXXXX" \
     -H "Content-Type: application/json"

Response
{
"result": {
"ipsec_id": "<ipsec_id>",
"ipsec_tunnel_id": "<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 the previous step. 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

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

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)
→ to the Cloudflare private GRE endpoint IP (10.4.8.11)
→ to the GCP West lan0 IP on the West EdgeConnect (10.30.0.3)
→ to the GCP West client (10.30.0.4).

This validates the east-west traffic flow through Cloudflare Magic WAN.

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)
→ to the Cloudflare private IPSec endpoint IP (192.168.10.11)
→ to the GCP West EdgeConnect private IPSec endpoint IP (192.168.15.10)
→ to the GCP West client (10.77.0.10).

This validates the east-west traffic flow through Cloudflare Magic WAN.