diff --git a/src/content/docs/magic-cloud-networking/get-started.mdx b/src/content/docs/magic-cloud-networking/get-started.mdx index de5bdf1a8f6ed1..d83ebc84ef1071 100644 --- a/src/content/docs/magic-cloud-networking/get-started.mdx +++ b/src/content/docs/magic-cloud-networking/get-started.mdx @@ -6,9 +6,9 @@ sidebar: --- -To get started with Magic Cloud Networking you need to give Cloudflare permission to interact with cloud providers on your behalf. You might have multiple provider accounts for the same cloud provider — for example, you might want Cloudflare to manage virtual private clouds (VPCs) belonging to two different AWS accounts. +To get started with Magic Cloud Networking you need to give Cloudflare permission to interact with cloud providers on your behalf. You might have multiple provider accounts for the same cloud provider - for example, you might want Cloudflare to manage virtual private clouds (VPCs) belonging to two different AWS accounts. -Once Cloudflare has the credentials required to access your cloud environments, Magic Cloud Networking will automatically begin discovering your cloud resources — like routing tables and virtual private networks. Discovered resources appear in your [Cloud resource catalog](/magic-cloud-networking/manage-resources/#cloud-resource-catalog). +Once Cloudflare has the credentials required to access your cloud environments, Magic Cloud Networking will automatically begin discovering your cloud resources - like routing tables and virtual private networks. Discovered resources appear in your [Cloud resource catalog](/magic-cloud-networking/manage-resources/#cloud-resource-catalog). ## 1. Set up cloud credentials @@ -42,7 +42,7 @@ Before you can connect Magic Cloud Networking to your cloud provider, you first } ``` -2. Follow the [instructions on AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) to create an IAM user up until step 4 — do not check the **Provide users access to the AWS Management Console** option. +2. Follow the [instructions on AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) to create an IAM user up until step 4 - do not check the **Provide users access to the AWS Management Console** option. 3. **In Give users permissions to manage their own security credentials** (step 7 of the AWS instructions) select **Attach policies directly**, and add the following policies: - `AmazonEC2ReadOnlyAccess` diff --git a/src/content/docs/magic-cloud-networking/manage-resources.mdx b/src/content/docs/magic-cloud-networking/manage-resources.mdx index 0fa9a0bf364a69..9ee6e1b708bc47 100644 --- a/src/content/docs/magic-cloud-networking/manage-resources.mdx +++ b/src/content/docs/magic-cloud-networking/manage-resources.mdx @@ -10,7 +10,7 @@ sidebar: Your cloud environment is built from individual cloud resources, like virtual private clouds (VPCs), subnets, virtual machines (VMs), route tables, and routes. Magic Cloud Networking discovers all of your cloud resources and stores their configuration and status in the Cloud resource catalog, a read-only snapshot of your cloud environment. Discovery runs regularly in the background, keeping your catalog up to date as your environment changes. -When Magic Cloud Networking creates or modifies configurations in the cloud provider — for example, to deploy a managed IPsec on-ramp for Magic WAN — the created resources will be labeled as **Managed** in the resource catalog. +When Magic Cloud Networking creates or modifies configurations in the cloud provider - for example, to deploy a managed IPsec on-ramp for Magic WAN - the created resources will be labeled as **Managed** in the resource catalog. To browse the resources in your catalog: diff --git a/src/content/docs/magic-network-monitoring/index.mdx b/src/content/docs/magic-network-monitoring/index.mdx index 255bc6691e14c2..ac682fdcebd219 100644 --- a/src/content/docs/magic-network-monitoring/index.mdx +++ b/src/content/docs/magic-network-monitoring/index.mdx @@ -76,7 +76,7 @@ Provides HTTP DDoS attack protection for zones onboarded to Cloudflare in additi -Connects your network infrastructure directly with Cloudflare – rather than using the public Internet – for a more reliable and secure experience. +Connects your network infrastructure directly with Cloudflare - rather than using the public Internet - for a more reliable and secure experience. diff --git a/src/content/docs/magic-transit/get-started.mdx b/src/content/docs/magic-transit/get-started.mdx index 926eb56ddcd5ec..226d4efd15cc62 100644 --- a/src/content/docs/magic-transit/get-started.mdx +++ b/src/content/docs/magic-transit/get-started.mdx @@ -9,7 +9,7 @@ import { GlossaryTooltip, Render } from "~/components"; Before you can begin using Magic Transit, be sure to complete the onboarding steps below. Cloudflare can significantly accelerate this timeline during active-attack scenarios. -## ​​1. Scope your configuration +## 1. Scope your configuration The onboarding process begins with an initial kickoff call where Cloudflare engages with your organization to confirm the scope and timeline for setting up Magic Transit. diff --git a/src/content/docs/magic-transit/how-to/advertise-prefixes.mdx b/src/content/docs/magic-transit/how-to/advertise-prefixes.mdx index a5eab839be866a..40794657f3984d 100644 --- a/src/content/docs/magic-transit/how-to/advertise-prefixes.mdx +++ b/src/content/docs/magic-transit/how-to/advertise-prefixes.mdx @@ -68,7 +68,7 @@ Withdrawing a prefix should propagate across Cloudflare's global network almost ## Border Gateway Protocol (BGP) control for advertisements -Use BGP to control the advertisement status of your prefix — advertised or withdrawn — from Cloudflare's global network for on-demand deployment scenarios. BGP Control works by establishing BGP sessions to Cloudflare's globally distributed Route Reflectors, which will initiate propagation of your prefix advertisement across Cloudflare's global network. +Use BGP to control the advertisement status of your prefix - advertised or withdrawn - from Cloudflare's global network for on-demand deployment scenarios. BGP Control works by establishing BGP sessions to Cloudflare's globally distributed Route Reflectors, which will initiate propagation of your prefix advertisement across Cloudflare's global network. Prefixes can be advertised from Cloudflare's network in a supported on-demand method such as BGP Control, or dynamically via the UI, API, or [Magic Network Monitoring](/magic-transit/magic-network-monitoring/). During the onboarding of your on-demand prefixes, please specify whether you want BGP-controlled advertisement or dynamic advertisement (via dashboard/API/Magic Network Monitoring). diff --git a/src/content/docs/magic-transit/how-to/run-endpoint-health-checks.mdx b/src/content/docs/magic-transit/how-to/run-endpoint-health-checks.mdx index fdfca832504b58..f6abb438e51ffe 100644 --- a/src/content/docs/magic-transit/how-to/run-endpoint-health-checks.mdx +++ b/src/content/docs/magic-transit/how-to/run-endpoint-health-checks.mdx @@ -6,7 +6,7 @@ sidebar: --- -Magic Transit uses endpoint health checks to determine the overall health of your [inter-network connections](/magic-transit/reference/tunnels/). Probes originate from Cloudflare infrastructure, outside customer network namespaces, and target IP addresses deep within your network, beyond the tunnel-terminating border router. These “long distance” probes are purely diagnostic. +Magic Transit uses endpoint health checks to determine the overall health of your [inter-network connections](/magic-transit/reference/tunnels/). Probes originate from Cloudflare infrastructure, outside customer network namespaces, and target IP addresses deep within your network, beyond the tunnel-terminating border router. These "long distance" probes are purely diagnostic. When choosing which endpoint IP addresses to monitor with health checks, use these guidelines: diff --git a/src/content/docs/magic-transit/index.mdx b/src/content/docs/magic-transit/index.mdx index 5932f0d14ab7c6..06cdfc1a892f83 100644 --- a/src/content/docs/magic-transit/index.mdx +++ b/src/content/docs/magic-transit/index.mdx @@ -46,7 +46,7 @@ Magic Firewall is a firewall-as-a-service (FWaaS) delivered from the Cloudflare -Cloudflare Network Interconnect (CNI) allows you to connect your network infrastructure directly with Cloudflare – rather than using the public Internet – for a more reliable and secure experience. +Cloudflare Network Interconnect (CNI) allows you to connect your network infrastructure directly with Cloudflare - rather than using the public Internet - for a more reliable and secure experience. diff --git a/src/content/docs/magic-transit/network-interconnect.mdx b/src/content/docs/magic-transit/network-interconnect.mdx index 2292745a66708c..4146857c2fd5db 100644 --- a/src/content/docs/magic-transit/network-interconnect.mdx +++ b/src/content/docs/magic-transit/network-interconnect.mdx @@ -10,7 +10,7 @@ head: import { GlossaryTooltip } from "~/components"; -Cloudflare Network Interconnect (CNI) allows you to connect your network infrastructure directly with Cloudflare – rather than using the public Internet – for a more reliable and secure experience. With CNI, you can bring Cloudflare's full suite of network functions to your physical network edge. +Cloudflare Network Interconnect (CNI) allows you to connect your network infrastructure directly with Cloudflare - rather than using the public Internet - for a more reliable and secure experience. With CNI, you can bring Cloudflare's full suite of network functions to your physical network edge. Use Cloudflare Network Interconnect with Magic Transit to improve throughput and harden infrastructure to attack. @@ -30,7 +30,7 @@ With Classic CNI you need to [set up an onboarding process](/network-interconnec With Classic CNI, you can create: -- **GRE tunnels over CNI**: For ingress and egress traffic. To accommodate overhead from additional headers, you will need to set the MTU size of your GRE tunnel interface to 1,476 bytes and your MSS clamp to be 1,436 bytes. These are used to backhaul data from the data center where traffic is ingested — close to the end user — to the facility with the CNI link. +- **GRE tunnels over CNI**: For ingress and egress traffic. To accommodate overhead from additional headers, you will need to set the MTU size of your GRE tunnel interface to 1,476 bytes and your MSS clamp to be 1,436 bytes. These are used to backhaul data from the data center where traffic is ingested - close to the end user - to the facility with the CNI link. - **CNI connections without GRE tunnels**: For ingress traffic from Cloudflare to customer device. There is no need to set MSS clamping, as this supports IP packets with 1,500 bytes. For more information about Network Interconnect, refer to the [Cloudflare Network Interconnect documentation](/network-interconnect/). diff --git a/src/content/docs/magic-wan/configuration/connector/configure-hardware-connector/index.mdx b/src/content/docs/magic-wan/configuration/connector/configure-hardware-connector/index.mdx index 70fecfd3dd6a15..6084dadae15f3e 100644 --- a/src/content/docs/magic-wan/configuration/connector/configure-hardware-connector/index.mdx +++ b/src/content/docs/magic-wan/configuration/connector/configure-hardware-connector/index.mdx @@ -115,7 +115,7 @@ If there is a firewall deployed upstream of the Magic WAN Connector, configure t ### WAN with a static IP address -After activating your Connector, you can use it in a network configuration with the WAN interface set to a static IP address — that is, an Internet configuration that is not automatically set by DHCP. +After activating your Connector, you can use it in a network configuration with the WAN interface set to a static IP address - that is, an Internet configuration that is not automatically set by DHCP. To use your Connector on a network configuration with a static IP: diff --git a/src/content/docs/magic-wan/configuration/connector/configure-hardware-connector/sfp-port-information.mdx b/src/content/docs/magic-wan/configuration/connector/configure-hardware-connector/sfp-port-information.mdx index efebef6c18fb4a..436e85e5cea56d 100644 --- a/src/content/docs/magic-wan/configuration/connector/configure-hardware-connector/sfp-port-information.mdx +++ b/src/content/docs/magic-wan/configuration/connector/configure-hardware-connector/sfp-port-information.mdx @@ -36,7 +36,7 @@ Cloudflare successfully deployed commonly available 10G modules that are also co - StarTech Dell EMC Twinax SFP+ DAC - Ubiquiti multi-mode, duplex, 10 Gbps fiber transceiver modules -Keep in mind that SFP+ modules/cables have to be compatible at both ends, that is, both sides of the connection should be 10 Gbps, and it should really be the same module/cable that is compatible with both hardware stacks. The choice of module/optic/cable ultimately depends on your specific interoperability needs, and it is much less of a “plug and play” situation as one expects from RJ45. +Keep in mind that SFP+ modules/cables have to be compatible at both ends, that is, both sides of the connection should be 10 Gbps, and it should really be the same module/cable that is compatible with both hardware stacks. The choice of module/optic/cable ultimately depends on your specific interoperability needs, and it is much less of a "plug and play" situation as one expects from RJ45. ## Recover from unsupported SFP+ inputs diff --git a/src/content/docs/magic-wan/configuration/connector/configure-virtual-connector.mdx b/src/content/docs/magic-wan/configuration/connector/configure-virtual-connector.mdx index 417906b4db8846..0f8f35add75b9a 100644 --- a/src/content/docs/magic-wan/configuration/connector/configure-virtual-connector.mdx +++ b/src/content/docs/magic-wan/configuration/connector/configure-virtual-connector.mdx @@ -52,7 +52,7 @@ Use VLAN ID `0` when: - Connected to a Port Group or Distributed Port Group that is associated with a specific VLAN. - Connected to a Port Group or Distributed Port Group that is configured as a trunk that requires untagged packets. -You can also configure subinterfaces on the Virtual Connector by associating the network interface with a Port Group or Distributed Port Group trunk and specifying a VLAN ID in addition to the port associated with the network interface (VLAN ID `1`–`4094`). +You can also configure subinterfaces on the Virtual Connector by associating the network interface with a Port Group or Distributed Port Group trunk and specifying a VLAN ID in addition to the port associated with the network interface (VLAN ID `1`-`4094`). Refer to [VMWare's documentation](https://kb.vmware.com/s/article/1003825) for more information. ::: @@ -123,7 +123,7 @@ You cannot use the same license key twice, or reuse a key once the virtual machi ### WAN with a static IP address -After activating your Virtual Connector, you can use it in a network configuration with the WAN interface set to a static IP address — that is, an Internet configuration that is not automatically set by DHCP. +After activating your Virtual Connector, you can use it in a network configuration with the WAN interface set to a static IP address - that is, an Internet configuration that is not automatically set by DHCP. To use your Virtual Connector on a network configuration with a static IP: diff --git a/src/content/docs/magic-wan/configuration/connector/device-metrics.mdx b/src/content/docs/magic-wan/configuration/connector/device-metrics.mdx index 66554873c9e507..44801318093165 100644 --- a/src/content/docs/magic-wan/configuration/connector/device-metrics.mdx +++ b/src/content/docs/magic-wan/configuration/connector/device-metrics.mdx @@ -18,7 +18,7 @@ To check for Connector metrics: 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account. 2. Go to **Magic WAN** > **Configuration** > **Connectors**. 3. Select the Connector you want to check metrics for. -4. In the side panel that opens, scroll down to **​​Usage information**. +4. In the side panel that opens, scroll down to **Usage information**. ### Query metrics with GraphQL diff --git a/src/content/docs/magic-wan/configuration/connector/network-options/nat-subnet.mdx b/src/content/docs/magic-wan/configuration/connector/network-options/nat-subnet.mdx index ee61ba63df6013..ef8800593c32b2 100644 --- a/src/content/docs/magic-wan/configuration/connector/network-options/nat-subnet.mdx +++ b/src/content/docs/magic-wan/configuration/connector/network-options/nat-subnet.mdx @@ -4,7 +4,7 @@ title: Enable NAT for a subnet --- -Each subnet (directly-attached or routed) must have a unique address space within your Magic WAN. You can re-use address spaces locally by enabling static network address translation (NAT) for a subnet. NAT is static. This means that inbound connections — from Magic WAN to the site behind the Connector — are allowed, and connections do not have to be initiated by hosts behind the Connector. NAT is also 1:1, that is, the Connector will translate between corresponding addresses in two equal-sized prefixes. +Each subnet (directly-attached or routed) must have a unique address space within your Magic WAN. You can re-use address spaces locally by enabling static network address translation (NAT) for a subnet. NAT is static. This means that inbound connections - from Magic WAN to the site behind the Connector - are allowed, and connections do not have to be initiated by hosts behind the Connector. NAT is also 1:1, that is, the Connector will translate between corresponding addresses in two equal-sized prefixes. To enable NAT, supply a WAN-facing address prefix the same size as the subnet's prefix, and the Magic WAN Connector will translate between the two. @@ -16,7 +16,7 @@ For example: With the example above, outbound traffic from host `192.168.100.13` in the subnet is translated to `10.10.100.13` in the Connector (and vice versa for incoming traffic). :::note -Even if NAT is enabled, the local prefix for a subnet must be unique within its LAN. It can, however, be reused on other LANs or other sites. Overlay-facing prefixes — that is, a subnet's NAT prefix if NAT is enabled, and its local prefix otherwise — must always be unique across your whole Magic WAN. +Even if NAT is enabled, the local prefix for a subnet must be unique within its LAN. It can, however, be reused on other LANs or other sites. Overlay-facing prefixes - that is, a subnet's NAT prefix if NAT is enabled, and its local prefix otherwise - must always be unique across your whole Magic WAN. ::: ## Create NATs for subnets diff --git a/src/content/docs/magic-wan/configuration/manually/third-party/fortinet.mdx b/src/content/docs/magic-wan/configuration/manually/third-party/fortinet.mdx index 262d2e8b08927e..8b99a37dba0b96 100644 --- a/src/content/docs/magic-wan/configuration/manually/third-party/fortinet.mdx +++ b/src/content/docs/magic-wan/configuration/manually/third-party/fortinet.mdx @@ -24,7 +24,7 @@ Before proceeding, ensure that you have the anycast IPs associated with your acc ### Magic IPsec Tunnels -Cloudflare recommends customers configure two Magic IPsec tunnels per firewall/router — one to each of the two anycast IP addresses. +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 **Magic WAN** > **Configuration**. @@ -37,7 +37,7 @@ Cloudflare recommends customers configure two Magic IPsec tunnels per firewall/r ### 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. +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)](/magic-wan/reference/traffic-steering/#equal-cost-multi-path-routing) 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). @@ -136,7 +136,7 @@ end #### Add Phase 2 interfaces -Add two `phase2-interfaces` — one for each of the two `phase1-interfaces` as follows: +Add two `phase2-interfaces` - one for each of the two `phase1-interfaces` as follows: ```txt fortigate # config vpn ipsec phase2-interface @@ -169,8 +169,8 @@ Configure the virtual tunnel interfaces that were automatically added when speci 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`). +- `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. @@ -430,7 +430,7 @@ Packet captures allow you to determine whether or not the policy-based routing r 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. +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 diff --git a/src/content/docs/magic-wan/configuration/manually/third-party/juniper.mdx b/src/content/docs/magic-wan/configuration/manually/third-party/juniper.mdx index 748cbdbe422120..3a7bc95f10851a 100644 --- a/src/content/docs/magic-wan/configuration/manually/third-party/juniper.mdx +++ b/src/content/docs/magic-wan/configuration/manually/third-party/juniper.mdx @@ -25,7 +25,7 @@ This section of the document will cover the configuration of: 1. Start by [creating the IPsec tunnels](/magic-wan/configuration/manually/how-to/configure-tunnels/#add-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. + - **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**: This is the public IP address the tunnel will be established with on the Juniper SRX. - **Cloudflare endpoint**: One of the two Cloudflare anycast IP addresses. - **Pre-shared key**: Choose **Add pre-shared key later**. @@ -54,7 +54,7 @@ This document assumes that the **trust zone** behind the Juniper SRX firewall ha [Magic static routes](/magic-wan/configuration/manually/how-to/configure-static-routes/) define which tunnel(s) to route traffic through for a given subnet. Since two tunnels are configured to each endpoint, it is necessary to configure two static routes. -Cloudflare leverages [equal-cost multi-path routing](/magic-wan/reference/traffic-steering/) to control steering of traffic across the tunnels. The default priority for each route is `100` — traffic will be load-balanced across the two tunnels equally. You can modify the priorities as needed. +Cloudflare leverages [equal-cost multi-path routing](/magic-wan/reference/traffic-steering/) to control steering of traffic across the tunnels. The default priority for each route is `100` - traffic will be load-balanced across the two tunnels equally. You can modify the priorities as needed. 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. @@ -148,7 +148,7 @@ interfaces { ### 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. If your security policy blocks `ping` by default, you will need to create a firewall-filter to allow ICMP from the [Cloudflare IPv4 address space](https://www.cloudflare.com/ips-v4) — not covered in this tutorial. +Add `ping` and `ike` to the security zone containing the external interface used to establish the IPsec tunnels to Cloudflare. If your security policy blocks `ping` by default, you will need to create a firewall-filter to allow ICMP from the [Cloudflare IPv4 address space](https://www.cloudflare.com/ips-v4) - not covered in this tutorial. ```txt set security zones security-zone untrust interfaces ge-0/0/2.0 host-inbound-traffic system-services ping @@ -187,7 +187,7 @@ set security ike proposal cf_ike_magic_wan_prop lifetime-seconds 28800 #### IKE policies -Define two IKE policies — one for each of the two Magic IPsec tunnels: +Define two IKE policies - one for each of the two Magic IPsec tunnels: **Tunnel 1 (SRX220_IPSEC_01)** @@ -207,7 +207,7 @@ set security ike policy cf_magic_wan_pol_02 pre-shared-key ascii-text "$9$sH4GD< #### 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. +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 (SRX220_IPSEC_01)** @@ -243,7 +243,7 @@ set security ipsec proposal cf_ipsec_magic_wan_prop lifetime-seconds 28800 #### IPsec policies -Define two IPsec policies — one for each of the two Magic IPsec tunnels. It is crucial to ensure that: +Define two IPsec policies - one for each of the two Magic IPsec tunnels. It is crucial to ensure that: - [Anti-replay](/magic-wan/reference/anti-replay-protection/) protection is disabled. - Use [`no-anti-replay`](https://www.juniper.net/documentation/us/en/software/junos/interfaces-adaptive-services/topics/ref/statement/no-anti-replay-edit-services.html) as the setting @@ -314,7 +314,7 @@ static { Define security policies to permit traffic flows destined for Magic WAN protected resources. The source/destination zones will need to 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, then to add more stringent rules once general connectivity is established successfully. +There are two very simple rules to allow traffic bidirectionally - it is generally recommended to start with a similar policy, then to add more stringent rules once general connectivity is established successfully. **From Cloudflare to *trust*:** diff --git a/src/content/docs/magic-wan/configuration/manually/third-party/palo-alto.mdx b/src/content/docs/magic-wan/configuration/manually/third-party/palo-alto.mdx index 606ef5b8f8db78..b0152e5b96ad25 100644 --- a/src/content/docs/magic-wan/configuration/manually/third-party/palo-alto.mdx +++ b/src/content/docs/magic-wan/configuration/manually/third-party/palo-alto.mdx @@ -821,7 +821,7 @@ Repeat these commands for the respective tunnel to ensure the IKE SA(s) display #### 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: +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 @@ -938,7 +938,7 @@ While we will leverage policy-based forwarding to implement policy-based routing Cloudflare Magic WAN implements [equal-cost multi-path (ECMP) routing](/magic-wan/reference/traffic-steering/#equal-cost-multi-path-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. +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 @@ -1356,7 +1356,7 @@ set rulebase security rules Cloudflare_Magic_WAN_to_Trust_Allow rule-type univer ### 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. +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. diff --git a/src/content/docs/magic-wan/configuration/manually/third-party/pfsense.mdx b/src/content/docs/magic-wan/configuration/manually/third-party/pfsense.mdx index 98dbab6fee4f42..5c22b0cbe82c74 100644 --- a/src/content/docs/magic-wan/configuration/manually/third-party/pfsense.mdx +++ b/src/content/docs/magic-wan/configuration/manually/third-party/pfsense.mdx @@ -33,8 +33,8 @@ The following IP addresses are used throughout this tutorial. Any legally routab | 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` | -| Magic WAN static routes — Prefix | `10.1.100.0/24` | `10.1.100.0/24` | -| Magic WAN static routes — Next hop | `PF_TUNNEL_01` | `PF_TUNNEL_02` | +| Magic WAN static routes - Prefix | `10.1.100.0/24` | `10.1.100.0/24` | +| Magic WAN static routes - Next hop | `PF_TUNNEL_01` | `PF_TUNNEL_02` | ## 1. Configure Magic WAN IPsec tunnels 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 819128cc6bd6e3..086b836f091508 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 @@ -8,7 +8,7 @@ This tutorial contains configuration information and a sample template for using ## 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. diff --git a/src/content/docs/magic-wan/index.mdx b/src/content/docs/magic-wan/index.mdx index 7a482c929e87fd..ba703fdc82c6ae 100644 --- a/src/content/docs/magic-wan/index.mdx +++ b/src/content/docs/magic-wan/index.mdx @@ -27,7 +27,7 @@ import { Magic WAN provides secure, performant connectivity and routing for your entire corporate networking, reducing cost and operation complexity. [Magic Firewall](/magic-firewall/) integrates smoothly with Magic WAN, enabling you to enforce network firewall policies at Cloudflare's global network, across traffic from any entity within your network. -With Magic WAN, you can securely connect any traffic source — data centers, offices, devices, cloud properties — to Cloudflare's network and configure routing policies to get the bits where they need to go, all within one SaaS solution. +With Magic WAN, you can securely connect any traffic source - data centers, offices, devices, cloud properties - to Cloudflare's network and configure routing policies to get the bits where they need to go, all within one SaaS solution. Magic WAN supports a variety of on-ramps including any device that supports anycast GRE or IPsec tunnels. To make it easier to onboard your cloud properties, you can use [Magic Cloud Networking](/magic-wan/configuration/magic-cloud-networking/), which automates the process of creating on-ramps from your cloud networks. @@ -112,8 +112,8 @@ Learn how to [get started](/magic-wan/get-started/). product="network-interconnect" > Cloudflare Network Interconnect (CNI) allows you to connect your network - infrastructure directly with Cloudflare – rather than using the public - Internet – for a more reliable and secure experience. + infrastructure directly with Cloudflare - rather than using the public + Internet - for a more reliable and secure experience. anycast tunnels from Cloudflare's global network to your locations. -You must assign a route priority to each tunnel–subnet pair in your configuration, as follows: +You must assign a route priority to each tunnel-subnet pair in your configuration, as follows: - Lower values have greater priority. - When the priority values for prefix entries match, Cloudflare uses equal-cost multi-path (ECMP) packet forwarding to route traffic. {props.magicWANecmp} For more on how Cloudflare uses ECMP packet forwarding, refer to Traffic steering. diff --git a/src/content/partials/magic-transit/static-routes/static-routes2-prefixes-smaller-24.mdx b/src/content/partials/magic-transit/static-routes/static-routes2-prefixes-smaller-24.mdx index ec16a1f67035f1..c3302e122d5ca4 100644 --- a/src/content/partials/magic-transit/static-routes/static-routes2-prefixes-smaller-24.mdx +++ b/src/content/partials/magic-transit/static-routes/static-routes2-prefixes-smaller-24.mdx @@ -3,7 +3,7 @@ --- -## ​​Map route prefixes smaller than `/24` +## Map route prefixes smaller than `/24` You must provide your prefixes and the tunnels that should be mapped to for Cloudflare to route your traffic from our global network to your data centers via anycast tunnels. Use the table below as reference. diff --git a/src/content/partials/magic-transit/static-routes/static-routes3.mdx b/src/content/partials/magic-transit/static-routes/static-routes3.mdx index 5ed745eb27f2df..47d9cfccbbdb7e 100644 --- a/src/content/partials/magic-transit/static-routes/static-routes3.mdx +++ b/src/content/partials/magic-transit/static-routes/static-routes3.mdx @@ -58,7 +58,7 @@ By default, you can only add static routes with [RFC 1918](https://datatracker.i If your use case requires IP prefixes outside RFC 1918, contact your Cloudflare customer service manager. -## ​​Create a static route +## Create a static route @@ -110,7 +110,7 @@ curl https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/routes \ -## ​​Edit a static route +## Edit a static route @@ -156,7 +156,7 @@ https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/routes \ -## ​​Delete static route +## Delete static route diff --git a/src/content/partials/magic-transit/traffic-steering.mdx b/src/content/partials/magic-transit/traffic-steering.mdx index c5c44f126ef4a0..a960b3f51387d1 100644 --- a/src/content/partials/magic-transit/traffic-steering.mdx +++ b/src/content/partials/magic-transit/traffic-steering.mdx @@ -51,7 +51,7 @@ Using ECMP has a number of consequences: As a result, ECMP provides load balancing across tunnels with the same prefix and priority. :::note[Note:] -Packets in the same flow use the same tunnel unless the tunnel priority changes. Packets for different flows can use different tunnels depending on which tunnel the flow's 4-tuple – source and destination IP and source and destination port – hash to. +Packets in the same flow use the same tunnel unless the tunnel priority changes. Packets for different flows can use different tunnels depending on which tunnel the flow's 4-tuple - source and destination IP and source and destination port - hash to. ::: ### Examples diff --git a/src/content/partials/magic-transit/tunnel-health/tunnel-health-checks.mdx b/src/content/partials/magic-transit/tunnel-health/tunnel-health-checks.mdx index f78698ea382802..e6db5d0f82c59e 100644 --- a/src/content/partials/magic-transit/tunnel-health/tunnel-health-checks.mdx +++ b/src/content/partials/magic-transit/tunnel-health/tunnel-health-checks.mdx @@ -17,7 +17,7 @@ Cloudflare encapsulates the ICMP reply packet and sends the probe across the tun Every Cloudflare data center configured to process your traffic sends tunnel health check probes. The rate at which these health check probes are sent varies based on tunnel and location. This rate can also be tuned up or down on a per tunnel basis by modifying the `health_check` rate of a tunnel with the API. -When a probe attempt fails for a [healthy](#health-state-and-prioritization) tunnel, each server detecting the failure quickly probes up to two more times to obtain an accurate result. We also do the same if a tunnel has been down and probes start returning success. Because Cloudflare global network servers send probes up to every second, you can expect your network to receive several hundred health check packets per second — each Cloudflare data center will only send one health check packet as part of a probe. This represents a relatively trivial amount of traffic. +When a probe attempt fails for a [healthy](#health-state-and-prioritization) tunnel, each server detecting the failure quickly probes up to two more times to obtain an accurate result. We also do the same if a tunnel has been down and probes start returning success. Because Cloudflare global network servers send probes up to every second, you can expect your network to receive several hundred health check packets per second - each Cloudflare data center will only send one health check packet as part of a probe. This represents a relatively trivial amount of traffic. :::note[Note] To avoid control plane policies enforced by the origin network, tunnel health checks use an encapsulated ICMP reply instead of an ICMP echo request. To use echo request packets, change your health check type to **Request** in your tunnels. Refer to Configure tunnel endpoints to learn how to change this setting. @@ -75,7 +75,7 @@ Once a tunnel is in the down state, global network servers continue to emit prob Tunnels in a degraded state transition to healthy when the failure rate for the previous 30 probes is less than 0.1%. This transition may take up to 30 minutes. -{props.productName}'s tunnel health check system allows a tunnel to quickly transition from healthy to degraded or down, but tunnel transition occurs slowly from degraded or down to healthy. This scenario is referred to as hysteresis — which is when a system's output depends on its history of past inputs — and dampens changes to tunnel routing caused by flapping and other intermittent network failures. +{props.productName}'s tunnel health check system allows a tunnel to quickly transition from healthy to degraded or down, but tunnel transition occurs slowly from degraded or down to healthy. This scenario is referred to as hysteresis - which is when a system's output depends on its history of past inputs - and dampens changes to tunnel routing caused by flapping and other intermittent network failures. :::note[Note] Cloudflare always attempts to send traffic over available tunnel routes with the highest priority (lowest route value), even when all configured tunnels are in an unhealthy state. diff --git a/src/content/partials/magic-wan/anti-replay-protection.mdx b/src/content/partials/magic-wan/anti-replay-protection.mdx index 48dcde84c95cae..e8b6ce10dd6678 100644 --- a/src/content/partials/magic-wan/anti-replay-protection.mdx +++ b/src/content/partials/magic-wan/anti-replay-protection.mdx @@ -10,7 +10,7 @@ If you use {props.productName} and anycastAdd tunnels to learn how to set up replay protection. Review the information below to learn about replay attacks, why we recommend disabling IPsec anti-replay, and related considerations. -## ​​Replay attacks +## Replay attacks Replay attacks occur when a malicious actor intercepts and records a packet, and later sends the recorded packet to the target network again with an intent that benefits the attacker. @@ -22,7 +22,7 @@ An attacker likely cannot open or close the garage door by guessing the encrypti To prevent this replay attack, a user could add a packet number to each command sent to the garage door. The first could be `packet 1`, the second `packet 2` and so on, and the garage door would only accept packets containing the next number in the sequence each time. For example, after the garage door receives `packet 1`, it would only accept packet 2, and if an attacker tries to replay `packet 1`, the request is ignored. -## ​​IPsec anti-replay protection +## IPsec anti-replay protection IPsec anti-replay protection works similarly to the prevention example in the scenario above. Each IPsec packet sent is assigned a sequence number by the sender. The receiver tracks which sequence numbers it has already seen and only accepts packets in a small window around the highest value the receiver has seen, and the window is typically 64-1024 packets. A window is used instead of strict sequencing because sometimes packets are reordered or lost on the Internet - having a range of acceptable packet sequence numbers helps absorb these issues. @@ -30,11 +30,11 @@ IPsec anti-replay protection works similarly to the prevention example in the sc Cloudflare's global anycast network consists of thousands of servers in hundreds of data centers around the world. Similar to Cloudflare's anycast GRE tunnel implementation, Cloudflare's IPsec implementation is also anycast, which enables users to enjoy all the benefits of Cloudflare's anycast network architecture. These benefits include unparalleled performance and low latency, greatly simplified configuration and management, and native network resiliency with automatic failover. By default, any packet for {props.productName} may go through any one of these servers where it will be encrypted and encapsulated with IPsec and sent to our user's router. -IPsec anti-replay protection was not designed for such a distributed scenario — the protection scheme is designed for a single sender and single receiver. For a single sender, keeping track of the sequence number is trivial, and the sequence number is stored in memory and incremented for every packet sent. If replay protection is enabled for {props.productName} IPsec tunnels, packets for a single tunnel are routed to one server that keeps track of the sequence number. This means the replay protection mechanism will work correctly, but users lose the benefits of automatically distributing traffic across Cloudflare's global servers. It also will only be actioned in one direction (Cloudflare to customer network) — packets from the customer network to Cloudflare will not be routed to a single server, and will not have replay protection applied. +IPsec anti-replay protection was not designed for such a distributed scenario - the protection scheme is designed for a single sender and single receiver. For a single sender, keeping track of the sequence number is trivial, and the sequence number is stored in memory and incremented for every packet sent. If replay protection is enabled for {props.productName} IPsec tunnels, packets for a single tunnel are routed to one server that keeps track of the sequence number. This means the replay protection mechanism will work correctly, but users lose the benefits of automatically distributing traffic across Cloudflare's global servers. It also will only be actioned in one direction (Cloudflare to customer network) - packets from the customer network to Cloudflare will not be routed to a single server, and will not have replay protection applied. -## ​​Additional considerations +## Additional considerations -IPsec anti-replay protection is extremely important for transport mode — host-to-host or even app-to-app IPsec. In transport mode, an attacker has a relatively easy time identifying the encrypted protocol and identifying which packets to replay if the protocol is even subject to replay attacks. {props.productName}, however, uses tunnel mode, which is inherently much harder to successfully manage a replay attack. +IPsec anti-replay protection is extremely important for transport mode - host-to-host or even app-to-app IPsec. In transport mode, an attacker has a relatively easy time identifying the encrypted protocol and identifying which packets to replay if the protocol is even subject to replay attacks. {props.productName}, however, uses tunnel mode, which is inherently much harder to successfully manage a replay attack. There are several reasons that make replay attacks difficult with tunnel mode: diff --git a/src/content/partials/magic-wan/connector/create-site.mdx b/src/content/partials/magic-wan/connector/create-site.mdx index d166c54dfd2fdb..d485dc81468c61 100644 --- a/src/content/partials/magic-wan/connector/create-site.mdx +++ b/src/content/partials/magic-wan/connector/create-site.mdx @@ -9,7 +9,7 @@ import { GlossaryTooltip, Markdown, Render, TabItem, Tabs } from "~/components"; ### 1. Create a site -Sites represent the local network where you have installed your Magic WAN Connector — for example, a branch office location. +Sites represent the local network where you have installed your Magic WAN Connector - for example, a branch office location. You need to create a site and set up all the settings associated with it before you can connect your Magic WAN Connector to the Internet. diff --git a/src/content/partials/magic-wan/connector/ha-configs.mdx b/src/content/partials/magic-wan/connector/ha-configs.mdx index 104ca4268708d4..b216c180584d51 100644 --- a/src/content/partials/magic-wan/connector/ha-configs.mdx +++ b/src/content/partials/magic-wan/connector/ha-configs.mdx @@ -24,7 +24,7 @@ Make sure all IPs are part of the same subnet. - In the case of a failover where a Connector is acting as a DHCP server, DHCP leases will be synchronized. ::: -### ​​Create a high availability configuration +### Create a high availability configuration You cannot enable high availability for an existing site. To add high availability to an existing site in the Cloudflare dashboard, you need to delete the site and start again. diff --git a/src/content/partials/magic-wan/traceroute.mdx b/src/content/partials/magic-wan/traceroute.mdx index fea00ebe69c6fa..18ac9f1e4b6a32 100644 --- a/src/content/partials/magic-wan/traceroute.mdx +++ b/src/content/partials/magic-wan/traceroute.mdx @@ -3,6 +3,6 @@ --- -:::note[​​Run traceroute] +:::note[Run traceroute] Magic WAN clients connecting through [GRE](/magic-wan/configuration/manually/how-to/configure-tunnels/), [IPsec](/magic-wan/configuration/manually/how-to/configure-tunnels/), [CNI](/network-interconnect/) or [WARP](/cloudflare-one/connections/connect-devices/warp/) that want to perform a `traceroute` to an endpoint behind a [Cloudflare Tunnel](/cloudflare-one/connections/connect-networks/) will need to change some settings to make the command useful. Refer to [Run `traceroute`](/magic-wan/configuration/manually/how-to/traceroute/) for more information. :::