Apply suggestions from code review

Co-authored-by: marciocloudflare <[email protected]>

Author: securitypedant

src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx

@@ -21,22 +21,22 @@ Every organization and network is different, and as such there is no one-size-fi
 
 The first decision for a Magic WAN Connector deployment is its location in the network, and this relates to whether the organization wants to keep the existing Customer Premises Equipment (CPE, edge router or firewall at a site), and if so, for what reason. Experience shows that this decision usually leads to three different topologies:
 
-- **Connector replacing the CPE** (Figure 1a) \- When the link is an Internet connection and the organization does not have any real use of existing equipment since the Connector supports all the required networking features such as DHCP, DNS, NAT, Trunking (801.1Q), IP access lists, breakout traffic, etc. Examples could be:
+- **Connector replacing the CPE** (Figure 1a): When the link is an Internet connection and the organization does not have any real use of existing equipment since the Connector supports all the required networking features such as DHCP, DNS, NAT, Trunking (801.1Q), IP access lists, breakout traffic, etc. Examples could be:
 
-  1. The transition from MPLS to Internet-based connectivity, where the MPLS router probably does not add any value in the deployment.
-  2. An Internet-facing CPE reaching, or already having exceeded, its end of life.
-  3. An Internet-facing CPE that is redundant with Magic WAN Connector and can be removed for simplicity's sake.
+  - The transition from MPLS to Internet-based connectivity, where the MPLS router probably does not add any value in the deployment.
+  - An Internet-facing CPE reaching, or already having exceeded, its end of life.
+  - An Internet-facing CPE that is redundant with Magic WAN Connector and can be removed for simplicity's sake.
 
-- **Connector north of the CPE** (Figure 1b) \- This option might be preferred when the existing CPE is a firewall, and the organization wants to keep it for:
+- **Connector north of the CPE** (Figure 1b): This option might be preferred when the existing CPE is a firewall, and the organization wants to keep it for:
 
-  1. Additional LAN protection as a result of a defense-in-depth approach.
-  2. Advanced segmentation requirements, for example allowing/blocking traffic between segments based on various Layer 3 to Layer 7 rules, since Magic WAN Connector supports segmentation only on layers 3 and 4 of the OSI model.
+  - Additional LAN protection as a result of a defense-in-depth approach.
+  - Advanced segmentation requirements, for example allowing/blocking traffic between segments based on various Layer 3 to Layer 7 rules, since Magic WAN Connector supports segmentation only on layers 3 and 4 of the OSI model.
 
-- **Connector south of the CPE** (Figure 1c) \- Reasons for installing Magic WAN Connector south of an existing Internet-facing CPE might be:
-  1. CPE cannot be replaced because it connects to a broadband service with a presentation (for example RJ-11) or protocol (for example PPPoE) that Magic WAN Connector does not support
-  2. CPE cannot be replaced because it is part of a fiber service that only works with that specific hardware, such as an ISP-provided ONT (Optical Network Terminal).
-  3. CPE cannot be replaced (yet) because it is part of an active managed service
-  4. CPE cannot be replaced because it is a firewall that the organization wants to keep in place for other reasons (technical or contractual)
+- **Connector south of the CPE** (Figure 1c): Reasons for installing Magic WAN Connector south of an existing Internet-facing CPE might be:
+  - CPE cannot be replaced because it connects to a broadband service with a presentation (for example RJ-11) or protocol (for example PPPoE) that Magic WAN Connector does not support.
+  - CPE cannot be replaced because it is part of a fiber service that only works with that specific hardware, such as an ISP-provided ONT (Optical Network Terminal).
+  - CPE cannot be replaced (yet) because it is part of an active managed service.
+  - CPE cannot be replaced because it is a firewall that the organization wants to keep in place for other reasons (technical or contractual).
 
 ![Figure 1: Connector location options: (a) replacing CPE, (b) north of CPE , (c) south of CPE.](~/assets/images/reference-architecture/magic-wan-connector-deployment/figure01.svg "Figure 1. Connector location options: (a) replacing CPE, (b) north of CPE , (c) south of CPE")
 
@@ -52,9 +52,9 @@ Magic WAN Connector can use two or more WAN ports for uplinks, and therefore it
 
 ### Full HA
 
-In this type of setup, a redundant device is configured to take over in case of a failure in the primary device, allowing seamless traffic failover and ensuring uninterrupted access to applications, data, and services. This approach enhances network resilience, improves service reliability, and helps maintain productivity by reducing the risk of single points of failure..
+In this type of setup, a redundant device is configured to take over in case of a failure in the primary device, allowing seamless traffic failover and ensuring uninterrupted access to applications, data, and services. This approach enhances network resilience, improves service reliability, and helps maintain productivity by reducing the risk of single points of failure.
 
-Figure 3 below illustrates the deployment topology where Magic WAN Connector supports full HA. Using an election process, one device becomes active and the other becomes passive. To achieve this, the two Connectors must connect to a LAN switch on the same Layer 2 domain (i.e. VLAN) for heartbeat messages to be sent between them. active/passive means that the active Connector is the only device that propagates traffic at any point in time.
+Figure 3 below illustrates the deployment topology where Magic WAN Connector supports full HA. Using an election process, one device becomes active and the other becomes passive. To achieve this, the two Connectors must connect to a LAN switch on the same Layer 2 domain (like a VLAN) for heartbeat messages to be sent between them. Active/passive means that the active Connector is the only device that propagates traffic at any point in time.
 
 ![Figure 3. Full HA with dual Connectors and dual uplinks.](~/assets/images/reference-architecture/magic-wan-connector-deployment/figure03.svg "Figure 3. Full HA with dual Connectors and dual uplinks.")
 
@@ -83,16 +83,16 @@ All traffic towards internal locations and self-hosted applications follows the
 
 ### Split tunneling
 
-In some deployments, customers might want to protect only specific protocols using Cloudflare security services such as our [secure web gateway](/cloudflare-one/policies/gateway/), the rest of the traffic routes through the existing edge device (router or firewall). Figure 5 illustrates such a use case.
+In some deployments, customers might want to protect only specific protocols using Cloudflare security services such as our [secure web gateway](/cloudflare-one/policies/gateway/), while the rest of the traffic routes through the existing edge device (router or firewall). Figure 5 illustrates such a use case.
 
 ![Figure 5. 'Split Tunneling' use case.](~/assets/images/reference-architecture/magic-wan-connector-deployment/figure05.svg "Figure 5. 'Split Tunneling' use case.")
 
-In this example, the organization wants Cloudflare to protect all Internet web traffic (HTTP/HTTPS), while the rest of the traffic flows out via the existing firewall. The latter could be traffic towards existing VPNs, or non-web traffic exiting the site, but protected by the on-prem firewall. This method could take the advantage of local device policy-based routing (PBR) capabilities, for example:
+In this example, the organization wants Cloudflare to protect all Internet web traffic (HTTP/HTTPS), while the rest of the traffic flows out via the existing firewall. The latter could be traffic towards existing VPNs, or non-web traffic exiting the site, but protected by the on-premises firewall. This method could take the advantage of local device policy-based routing (PBR) capabilities, for example:
 
-1. Local devices use the on premises firewall as their default gateway
+1. Local devices use the on-premises firewall as their default gateway
 2. Firewall uses PBR to direct appropriate traffic to the right destination
 3. Web traffic (TCP 80/443) is sent towards Cloudflare via the Magic WAN Connector
-4. All other traffic exits via the on premises firewall
+4. All other traffic exits via the on-premises firewall
 
 As long as PBR capability exists locally, and the ISP provides at least two public IP addresses to the organization, the possibilities of splitting traffic towards the Magic WAN Connector are endless, and really depend on each organization's unique environment and use cases.
 
@@ -104,13 +104,13 @@ Another advanced group of use cases that Magic WAN Connector can support is loca
 
 In this example, the Magic WAN Connector will create an IPsec tunnel to Cloudflare through the on premises firewall and local Internet connection. Subnet A and B are both connected to the Magic WAN Connector, but have no direct connection with each other. This will enable a couple of use cases:
 
-1. **Internet security**: Segment 1 adheres to Cloudflare security policies, bypassing the local firewall policy.
-2. **Site-to-site connectivity**: Segment 1 can connect to local segments in other locations (or entire sites, for example Site 2), depending on the organization's policy.
+- **Internet security**: Segment 1 adheres to Cloudflare security policies, bypassing the local firewall policy.
+- **Site-to-site connectivity**: Segment 1 can connect to local segments in other locations (or entire sites, for example Site 2), depending on the organization's policy.
 
 The example also shows how Magic WAN Connector can be used to provide two types of local network segmentation:
 
-1. **Intra-segment**: Traffic between LAN ports on the same Connector is blocked by default, hence, Subnet A and Subnet B in Segment 1 cannot talk to each other. The administrator would have to explicitly allow this traffic flow by using configuration logic similar to IP access lists. This ability to hairpin local traffic via the Connector's LAN ports, avoids traffic tromboning via the Cloudflare platform (that is, travel out and back in via the Magic WAN tunnel), which could result in those segments losing connectivity to each other in the event of Internet circuit outage. Therefore, this capability allows local nodes that do not necessarily require Internet access to function, for example printers, file servers, network attached storage (NAS) nodes, and various Internet of Things (IoT) devices, to continue being accessible by local hosts in different segments during Internet outages.
-2. **Inter-segment**: Magic WAN Connector does not allow any inbound traffic on its WAN ports. Therefore, Segments 1 and 2 cannot talk to each other.
+- **Intra-segment**: Traffic between LAN ports on the same Connector is blocked by default, hence, Subnet A and Subnet B in Segment 1 cannot talk to each other. The administrator would have to explicitly allow this traffic flow by using configuration logic similar to IP access lists. This ability to hairpin local traffic via the Connector's LAN ports, avoids traffic tromboning via the Cloudflare platform (that is, travel out and back in via the Magic WAN tunnel), which could result in those segments losing connectivity to each other in the event of Internet circuit outage. Therefore, this capability allows local nodes that do not necessarily require Internet access to function, for example printers, file servers, network attached storage (NAS) nodes, and various Internet of Things (IoT) devices, to continue being accessible by local hosts in different segments during Internet outages.
+- **Inter-segment**: Magic WAN Connector does not allow any inbound traffic on its WAN ports. Therefore, Segments 1 and 2 cannot talk to each other.
 
 To summarize, Magic WAN Connector is a Zero-Touch Provisioning (ZTP) device that organizations can use to connect to Cloudflare and consume advanced security and connectivity services, while keeping operational costs low.