New reference architecture diagram - Magic WAN Connector deployment options #18203
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![hyperlint-ai[bot]](https://avatars.githubusercontent.com/in/718456?s=60&v=4){kind=small}
src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
Outdated
Show resolved
Hide resolved
src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
Outdated
Show resolved
Hide resolved
src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
Show resolved
Hide resolved
src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
Outdated
Show resolved
Hide resolved
src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
Outdated
Show resolved
Hide resolved
src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
Outdated
Show resolved
Hide resolved
src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
Outdated
Show resolved
Hide resolved
src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
Outdated
Show resolved
Hide resolved
src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
Outdated
Show resolved
Hide resolved
src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
Outdated
Show resolved
Hide resolved
Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com>
Deploying cloudflare-docs with
|
| Latest commit: |
0b20394
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://e32d9b26.cloudflare-docs-7ou.pages.dev |
| Branch Preview URL: | https://sthorpe-ra-magic-wan-connect.cloudflare-docs-7ou.pages.dev |
Minor changes
marciocloudflare
approved these changes
Nov 18, 2024
|
|
||
| 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: |
There was a problem hiding this comment.
Suggested change
| - **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: |
Comment on lines
+26
to
+28
| 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. |
There was a problem hiding this comment.
Suggested change
| 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. |
There was a problem hiding this comment.
We only use numbers for steps that have to be performed in a particular order. I think here we should change to a regular unordered list.
| 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. | ||
|
|
||
| - **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: |
There was a problem hiding this comment.
Suggested change
| - **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: |
Comment on lines
+32
to
+33
| 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. |
There was a problem hiding this comment.
Suggested change
| 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. |
| 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. | ||
|
|
||
| - **Connector south of the CPE** (Figure 1c) \- Reasons for installing Magic WAN Connector south of an existing Internet-facing CPE might be: |
There was a problem hiding this comment.
Suggested change
| - **Connector south of the CPE** (Figure 1c) \- Reasons for installing Magic WAN Connector south of an existing Internet-facing CPE might be: | |
| - **Connector south of the CPE** (Figure 1c): Reasons for installing Magic WAN Connector south of an existing Internet-facing CPE might be: |
|
|
||
|  | ||
|
|
||
| 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: |
There was a problem hiding this comment.
Suggested change
| 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 | ||
| 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 |
There was a problem hiding this comment.
Suggested change
| 4. All other traffic exits via the on premises firewall | |
| 4. All other traffic exits via the on-premises firewall |
|
|
||
| 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: | ||
|
|
||
| 1. Local devices use the on premises firewall as their default gateway |
There was a problem hiding this comment.
Suggested change
| 1. Local devices use the on premises firewall as their default gateway | |
| 1. Local devices use the on-premises firewall as their default gateway |
Comment on lines
+107
to
+108
| 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. |
There was a problem hiding this comment.
Suggested change
| 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. |
Comment on lines
+112
to
+113
| 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. |
There was a problem hiding this comment.
Suggested change
| 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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
New reference architecture diagram - Magic WAN Connector deployment options