Scenario
BR-01 offers guest Wi-Fi on service VPN 30 (10.30.1.0/24). Guests must reach the internet directly at the branch, using NAT on the local internet transport, without crossing to the corporate network. Risky and inappropriate web categories are blocked, and the guest network has basic limits. This lab builds the policy and checks it from a guest PC.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Site IDs, VPN numbers and colours are examples. Features and keywords depend on the router, the release and the licence, so check your release.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Task 1: confirm the guest zone
Confirm that VPN 30 is in a zone of its own and that traffic from it to the corporate zone and to the data centre is denied.
Show the answer for task 1
Zones are groups of service VPNs. Traffic inside a zone flows freely, and traffic between zones is denied unless a zone-pair rule allows it. So the guest zone holds VPN 30 and nothing else, and no zone pair exists from GUEST to CORP. A route into the data centre should not exist for VPN 30 either: do not advertise 10.30.1.0/24 beyond BR-01, or keep VPN 30 out of the VPN lists in any policy that spreads prefixes. A missing route and a missing allow rule are two separate layers, and having both is cheap.
Task 2: direct internet access for VPN 30 only
Send VPN 30 traffic out of the local internet transport with NAT. Leave VPN 10 as it is: corporate users keep their existing exit, which may be through a hub.
Show the answer for task 2
There are two common ways. A data policy on the VPN 30 traffic whose action is to use the internet transport in VPN 0 with NAT, or a service-side configuration with a default route in VPN 30 that points to the internet exit, plus NAT on the internet interface. Which one is available, and the exact keywords, depend on the release.
! Outline, not exact CLI. Build it in SD-WAN Manager and check your release.
data-policy GUEST-DIA (applied to VPN list: 30, direction: from-service)
sequence 10 match source 10.30.1.0/24
action accept, nat use-vpn 0
default-action accept
NAT on BR-01 internet interface (transport VPN 0): enabled, overload
inside source: VPN 30 trafficOutline of the two parts: steer VPN 30 to the internet transport, and translate its addresses on the way out. Without NAT, guest packets leave with private 10.30.1.x source addresses and the internet cannot reply. Guest DHCP and the guest gateway are not shown.
Only VPN 30 is matched. VPN 10 and VPN 40 are not in the policy, so they are not affected. Do not use a match of "any source" unless you intend to change every VPN on the branch.
Task 3: the guest to internet zone rule
The internet side is a zone too. Write a zone-pair rule from GUEST to the internet (the self or internet zone name your release uses) with action inspect.
Show the answer for task 3
- Zone pair GUEST to internet, one rule that matches the services guests need (web, DNS, and others you list), action inspect.
- Inspect is stateful, so replies from the internet are allowed without a second rule.
- Add a rule that drops traffic from guests to private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) before the general allow, so a guest cannot probe corporate addresses that happen to be reachable by the internet exit.
- Basic limits: block the services you do not want (for example file sharing and remote administration ports), and consider a rate limit or per-client cap where your release offers one.
Task 4: URL filtering
Attach URL filtering to the guest rule. Block categories by name, apply a reputation threshold, show a block page, and add an allow list for the domains guests need before they can log in.
Show the answer for task 4
- Categories to block: choose from the category list in your release, for example adult content, gambling, malware and phishing sites, anonymisers and proxies. The list is a policy decision for the organisation.
- Reputation: set a minimum reputation so that unknown or low-reputation sites are blocked even when their category is allowed. A strict level blocks more legitimate sites, so test it.
- Block page: for plain HTTP the router can show a page. For HTTPS without decryption it cannot show a page, because the browser would reject it, so the connection is reset and the guest sees a browser error.
- Allow list: add the captive-portal host and any domain needed for sign-in or terms acceptance. Allow-list entries are checked ahead of the categories.
Task 5: DNS for guests
Show the answer for task 5
Hand guests a public or filtered resolver through DHCP on VPN 30, not the internal DNS servers. Reasons: internal names should not be visible to visitors, the internal resolvers should not be reachable from the guest zone, and a filtered resolver adds a second layer of blocking. The DNS query must be allowed in the zone rule to that resolver only. If a DNS-layer security service is used, guests can go to it directly. See the lesson on DNS and web-layer security for how its local-domain bypass works.
Task 6: verify from a guest PC
Connect a PC to the guest Wi-Fi. It should receive an address in 10.30.1.0/24. Run three tests.
guest-pc$curl -sI https://example.com | head -n 1 HTTP/2 200
guest-pc$curl -sI https://blocked-category.example.net | head -n 1 curl: (35) Recv failure: Connection reset by peer
guest-pc$ping 10.10.1.1 PING 10.10.1.1 (10.10.1.1): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 --- 10.10.1.1 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss
BR-01#show sdwan zbfw drop-statistics Drop reason Packets Policy default action drop (GUEST -> CORP) 2 URL filter block (GUEST -> internet) 1
In the Manager, open the monitoring pages for BR-01 and look at the firewall and URL filtering views. The blocked category should show as a URL filtering event with the category name, and the session counts for the guest zone pair should have grown. If your release shows NAT translations in the monitoring pages, check that VPN 30 sessions are listed there.
Break and fix
Fault 1: guests have no internet
The guest PC has an address and can ping its gateway, but nothing outside loads.
Show the diagnosis and fix
Work outwards from the guest. Gateway reachable: LAN is fine. Next check whether VPN 30 has a route to the internet exit (a default route, or a data policy that matches). Then check NAT on the internet interface. If NAT or the exit route for VPN 30 is missing, packets either have nowhere to go, or leave with a private source address and no reply returns. Fix: add the exit (policy or default route) for VPN 30 and enable NAT for it. Confirm with the NAT table and the source address seen by the website.
Fault 2: guests can reach corporate hosts
A guest laptop reaches 10.10.1.1. The firewall policy has a zone for guests and one for corporate.
Show the diagnosis and fix
Both VPN 10 and VPN 30 were added to the same zone. Traffic inside one zone flows freely, so the firewall does not filter it. Diagnose by listing the zone membership in the policy: VPN 30 must be the only member of GUEST. Fix: move VPN 30 into its own zone, then check that no route leak joins the two VPNs. A zone is a group of VPNs, so the grouping is the control.
Fault 3: expected HTTPS blocks do not happen
The policy blocks a specific video page on a large site, but guests still open it. Other categories are blocked as expected.
Show the diagnosis and fix
HTTPS is encrypted, and without decryption the router sees the server name only. It can block the domain, or the category the domain belongs to, but not one path on it. Fix by changing the expectation: block by category or domain, accept that a whole site is blocked or allowed, or decrypt guest traffic with the TLS proxy. Decryption requires the organisation's CA certificate on every guest device, which visitors rarely accept, and it raises privacy questions. For guest Wi-Fi, category and domain policy is the usual choice. This is a design opinion rather than a Cisco rule.
What to record
- The guest policy before and after: zone membership, zone pairs, DIA policy and NAT.
- The list of blocked categories, the reputation setting and the allow list, with the reason for each.
- The three guest tests with date and time, and the matching counters.
- The DNS servers handed to guests.
- The guest terms and any logging notice, agreed with whoever is responsible for privacy.
- Change approval and rollback plan.
Test yourself on guest access
A guest can ping 10.10.1.1. VPN 30 and VPN 10 are both in the zone BRANCH-USERS. What is the cause?
Guests can reach their gateway but no websites. VPN 30 has no default route to the internet exit and no matching data policy. What is the fix?
What does a guest see when a blocked-category HTTPS site is filtered without decryption?
Why give guests a public or filtered DNS resolver and not the internal one?