Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Magic] Deleted non-ascii chars #18562

Merged
merged 1 commit into from
Dec 4, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions src/content/docs/magic-cloud-networking/get-started.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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`
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand Down
2 changes: 1 addition & 1 deletion src/content/docs/magic-network-monitoring/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -76,7 +76,7 @@ Provides HTTP DDoS attack protection for zones onboarded to Cloudflare in additi

<RelatedProduct header="Cloudflare Network Interconnect" href="/network-interconnect/" product="network-interconnect">

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.

</RelatedProduct>

Expand Down
2 changes: 1 addition & 1 deletion src/content/docs/magic-transit/get-started.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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).

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand Down
2 changes: 1 addition & 1 deletion src/content/docs/magic-transit/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ Magic Firewall is a firewall-as-a-service (FWaaS) delivered from the Cloudflare
</RelatedProduct>

<RelatedProduct header="Cloudflare Network Interconnect" href="/network-interconnect/" 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.
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.
</RelatedProduct>

<RelatedProduct header="DDoS Protection" href="/ddos-protection/" product="ddos-protection">
Expand Down
4 changes: 2 additions & 2 deletions src/content/docs/magic-transit/network-interconnect.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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 <GlossaryTooltip term="maximum segment size (MSS)">MSS clamping</GlossaryTooltip>, as this supports IP packets with 1,500 bytes.

For more information about Network Interconnect, refer to the [Cloudflare Network Interconnect documentation](/network-interconnect/).
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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.
:::
Expand Down Expand Up @@ -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:

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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**.
Expand All @@ -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).

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand Down
Loading
Loading