Apply suggestions from code review

Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com>

Author: securitypedant

src/content/docs/reference-architecture/design-guides/securing-guest-wireless-networks.mdx

@@ -73,7 +73,7 @@ In this configuration:
 
 1. A subnet is assigned to the guest wireless VLAN.
 2. The default gateway for that subnet is configured on an interface (or virtual interface) of an upstream network device such as a firewall or router.
-3. The device segments guest network traffic from internal network traffic while also acting as a secure gateway to the public internet.
+3. The device segments guest network traffic from internal network traffic while also acting as a secure gateway to the public Internet.
 
 ### Configure DNS for the guest network
 
@@ -146,11 +146,11 @@ Inform your guests why their access was blocked by configuring [custom block mes
 
 ### Recommended policies
 
-Cloudflare has several additional recommended DNS policies that can be found [here](/learning-paths/secure-internet-traffic/build-dns-policies/recommended-dns-policies/) in the “Secure your internet traffic” implementation guide. These policies are designed to enhance your organization's overall security and should also be factored in when setting up policies for your internal production web traffic.
+Cloudflare has several additional recommended DNS policies that can be found in the [Secure your internet traffic implementation guide](/learning-paths/secure-internet-traffic/build-dns-policies/recommended-dns-policies/). These policies are designed to enhance your organization's overall security and should also be factored in when setting up policies for your internal production web traffic.
 
 ### Visibility into Guest DNS Internet Activity
 
-With DNS traffic now routed through Cloudflare and your wireless networks secured, you can gain detailed visibility into your guests' Internet activity using logs and advanced logging tools. Every DNS request is [logged](/cloudflare-one/insights/logs/gateway-logs/) in Cloudflare and our dashboard provides a simple search interface. These logs help you understand how your policies are applied and detect trends or patterns in guest internet usage, providing actionable insights to fine-tune your security configurations.
+With DNS traffic now routed through Cloudflare and your wireless networks secured, you can gain detailed visibility into your guests' Internet activity using logs and advanced logging tools. Every DNS request is [logged](/cloudflare-one/insights/logs/gateway-logs/) in Cloudflare and our dashboard provides a simple search interface. These logs help you understand how your policies are applied and detect trends or patterns in guest Internet usage, providing actionable insights to fine-tune your security configurations.
 
 For advanced telemetry and seamless data management, consider enabling **Logpush** in your Cloudflare dashboard. Sending these logs to an external source, most commonly a SIEM platform, brings the following benefits:
 
@@ -160,7 +160,7 @@ For advanced telemetry and seamless data management, consider enabling **Logpush
 - **Real-Time Alerts**: Leverage SIEM integration to trigger automated alerts and responses based on suspicious DNS activity.
 - **Operational Insights**: Gain a deeper understanding of guest browsing behavior to identify performance bottlenecks or optimize content filtering policies.
 
-By leveraging logs, Logpush, and SIEM integrations, you not only enhance visibility into guest internet activity but also strengthen your organization's overall security posture.
+By leveraging logs, Logpush, and SIEM integrations, you not only enhance visibility into guest Internet activity but also strengthen your organization's overall security posture.
 
 ## Going beyond DNS filtering
 
@@ -172,7 +172,7 @@ Up to this point all methods mentioned have revolved around DNS, mainly due to t
 
 For these reasons you should also consider applying security in layers and add network centric enforcement to compliment the protections provided via DNS.
 
-![Figure 4: This diagram shows how to connect guest networks to cloudflare and the high level traffic flow to reach internet resources.](~/assets/images/reference-architecture/securing-guest-wireless-networks/figure4.svg "Figure 4: This diagram shows how to connect guest networks to cloudflare and the high level traffic flow to reach internet resources.")
+![Figure 4: This diagram shows how to connect guest networks to Cloudflare and the high level traffic flow to reach Internet resources.](~/assets/images/reference-architecture/securing-guest-wireless-networks/figure4.svg "Figure 4: This diagram shows how to connect guest networks to Cloudflare and the high level traffic flow to reach Internet resources.")
 
 To provide network level filtering, Cloudflare must be in the traffic path for more than just the DNS request. This is achieved by routing Internet-bound traffic over an [IPsec](https://www.cloudflare.com/learning/network-layer/what-is-ipsec/) tunnel to Cloudflare. Cloudflare's [Magic WAN](/magic-wan/) service allows  third-party devices to establish IPsec or GRE tunnels to the Cloudflare network. It is also possible to just deploy our [Magic WAN Connector](/magic-wan/configuration/connector/), a pre-configured lightweight network appliance that automatically creates the tunnel back to Cloudflare and can be managed remotely. Once traffic reaches Cloudflare multiple security controls can be overlaid such as:
 
@@ -183,8 +183,8 @@ Below is the high level traffic flow that correlates to the above diagram:
 
 1. Internet destined traffic will be routed to cloudflare from connected guest networks, this can be easily done with a policy based route. In most guest Wi-Fi setups devices will only be expected to generate internet bound traffic so in most cases a Policy based route referencing ANY as the destination will be sufficient. Ex Source 192.168.53.0/24 to Destination ANY next hop Cloudflare IPsec tunnel.
 2. Once traffic reaches the cloudflare edge it will first be inspected by magic firewall. Magic Firewall can be used to create network and transport layer blocks which would allow admins to restrict access to certain destination IP's or ports, a common policy could be blocking all DNS traffic not directed towards cloudflare DNS resolvers. Custom lists can be used to import existing lists customers may already have. [IDS](/magic-firewall/about/ids/) can be enabled to monitor if any guest users are attempting to launch known exploits from your Guest network. Managed threat [lists](/waf/tools/lists/managed-lists/#managed-ip-lists) allow you to use cloudflare's auto updated threat intel to block known threats like known malware repositories or botnets.
-3. Traffic is then forwarded to cloudflare gateway. At gateway network based policies can be created using the same Content categories and Security risks mentioned earlier within DNS based policies, the benefit is when these filters are applied at the network level, even if a user bypasses DNS these policies can still be applied providing multi tiered enforcement. It would be recommended to mirror DNS based rules in accordance with your organization's acceptable use policy. Cloudflare Gateway also acts as a secure outbound proxy and as such can SNAT private address to internet routable public addresses, by default rfc 1918 addresses will automatically be SNAT to Shared cloudflare egress ip's. This removes the need for managing PAT directly from your edge device and also provides a layer of privacy as traffic will source from cloudflare owned ip's when browsing internet sites. Dedicated Egress ip's unique to your account can also be provided and egress ip selection controlled via policy.
-4. Traffic is now routed to the final internet destination, return traffic will be routed back through cloudflare edge and returned to the corresponding IPsec tunnel.
+3. Traffic is then forwarded to Cloudflare gateway. At gateway network based policies can be created using the same Content categories and Security risks mentioned earlier within DNS based policies, the benefit is when these filters are applied at the network level, even if a user bypasses DNS these policies can still be applied providing multi tiered enforcement. It would be recommended to mirror DNS based rules in accordance with your organization's acceptable use policy. Cloudflare Gateway also acts as a secure outbound proxy and as such can SNAT private address to Internet routable public addresses, by default rfc 1918 addresses will automatically be SNAT to Shared Cloudflare egress ip's. This removes the need for managing PAT directly from your edge device and also provides a layer of privacy as traffic will source from Cloudflare owned ip's when browsing Internet sites. Dedicated Egress ip's unique to your account can also be provided and egress ip selection controlled via policy.
+4. Traffic is now routed to the final Internet destination, return traffic will be routed back through Cloudflare edge and returned to the corresponding IPsec tunnel.
 
 ## Summary