You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/reference-architecture/diagrams/sase/magic-wan-connector-deployment.mdx
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,7 +25,7 @@ The first decision for a Magic WAN Connector deployment is its location in the n
25
25
26
26
1. The transition from MPLS to Internet-based connectivity, where the MPLS router probably does not add any value in the deployment.
27
27
2. An Internet-facing CPE reaching, or already having exceeded, its end of life.
28
-
3. An internet-facing CPE that is redundant with Magic WAN Connector and can be removed for simplicity’s sake.
28
+
3. An Internet-facing CPE that is redundant with Magic WAN Connector and can be removed for simplicity's sake.
29
29
30
30
-**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:
31
31
@@ -34,7 +34,7 @@ The first decision for a Magic WAN Connector deployment is its location in the n
34
34
35
35
-**Connector south of the CPE** (Figure 1c) \- Reasons for installing Magic WAN Connector south of an existing Internet-facing CPE might be:
36
36
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
37
-
2. CPE cannot be replaced because it is part of a fiber service that only works with that specific hardware (e.g. ISP-provided ONT)
37
+
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).
38
38
3. CPE cannot be replaced (yet) because it is part of an active managed service
39
39
4. CPE cannot be replaced because it is a firewall that the organization wants to keep in place for other reasons (technical or contractual)
40
40
@@ -76,16 +76,16 @@ The main use case for this type of deployment is based on the fact that many org
76
76
This type of hybrid architecture requires the MPLS Customer Edge router (CE) or some other L3 device in the LAN to route traffic via different interfaces depending on the destination. Traffic flows in this scenario as follows:
77
77
78
78
1. Devices on the local network use the MPLS CE (or some other local L3 device) as their default gateway
79
-
2. Private traffic is sent towards the MPLS network (e.g. MPLS CE knows how to route these as it receives RFC1918 ranges via BGP from the MPLS network)
79
+
2. Private traffic is sent towards the MPLS network. For example, the MPLS CE knows how to route these because it receives RFC1918 ranges via BGP from the MPLS network.
80
80
3. Internet traffic from both LAN and MPLS network is sent towards the Magic WAN Connector (MPLS CE/L3 gateway points a static default route towards the Connector)
81
81
82
-
All traffic towards internal locations and self-hosted applications follows the MPLS path, while traffic to cloud-based and SaaS applications follows the local internet breakout path, protected by Cloudflare security services.
82
+
All traffic towards internal locations and self-hosted applications follows the MPLS path, while traffic to cloud-based and SaaS applications follows the local Internet breakout path, protected by Cloudflare security services.
83
83
84
84
### Split tunneling
85
85
86
-
In some deployments, customers might want to protect only specific protocols using Cloudflare security services such as our [secure web gateway](https://developers.cloudflare.com/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.
86
+
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.
87
87
88
-

88
+

89
89
90
90
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:
91
91
@@ -94,28 +94,28 @@ In this example, the organization wants Cloudflare to protect all Internet web t
94
94
3. Web traffic (TCP 80/443) is sent towards Cloudflare via the Magic WAN Connector
95
95
4. All other traffic exits via the on premises firewall
96
96
97
-
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.
97
+
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.
98
98
99
99
### Protecting segments / segmentation
100
100
101
-
Another advanced group of use cases that Magic WAN Connector can support is local segmentation, and protection of specific local networks. To achieve that, and depending on an organization’s current architecture, line of business, security policies, and compliance requirements, Magic WAN Connector can be installed in any location south of the site edge device to provide more granular network security, as illustrated in figure 6 and described in the following paragraphs.
101
+
Another advanced group of use cases that Magic WAN Connector can support is local segmentation, and protection of specific local networks. To achieve that, and depending on an organization's current architecture, line of business, security policies, and compliance requirements, Magic WAN Connector can be installed in any location south of the site edge device to provide more granular network security, as illustrated in figure 6 and described in the following paragraphs.
102
102
103
103

104
104
105
105
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:
106
106
107
107
1.**Internet security**: Segment 1 adheres to Cloudflare security policies, bypassing the local firewall policy.
108
-
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.
108
+
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.
109
109
110
110
The example also shows how Magic WAN Connector can be used to provide two types of local network segmentation:
111
111
112
-
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.
112
+
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.
113
113
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.
114
114
115
115
To summarize, Magic WAN Connector is a Zero-Touch Provisioning ([ZTP](https://en.wikipedia.org/wiki/Zero-touch_provisioning)) device that organizations can use to connect to Cloudflare and consume advanced security and connectivity services, while keeping operational costs low.
0 commit comments