Guest Internet Access Without Internal Reachability
A guest Wi-Fi VLAN 172.16.50.0/24 must reach the internet but must not reach any RFC1918 address, including corporate 10.0.0.0/8 and the payment DMZ 192.168.100.0/24. The firewall has zones Guest, Trust, DMZ, and Untrust. The administrator creates a deny rule from Guest to any with destination RFC1918 addresses, application any, service any, placed at the bottom of the rulebase, below an allow rule from Guest to Untrust using application any and service any. Guests report they can still open an SSH session to 10.20.30.40 and reach 192.168.100.10 on port 8443. Public websites work normally.
1. Why do guests still reach RFC1918 addresses, and what is the minimal correct policy change?
Read the worked answer
The allow rule above the deny matches first. PAN-OS evaluates security rules top-down; once Guest-to-Untrust with application any and service any matches, the later deny is never evaluated. Also, a destination zone of Untrust does not exclude RFC1918 addresses. The minimal fix is to move the RFC1918 deny above the allow, or replace the allow with a positive allow to internet destinations that excludes RFC1918 and then deny all. Prefer deny above allow for clarity. Keep the deny application any and service any so it catches SSH, 8443, and future applications. Verify with test traffic and inspect session details. Do not rely on URL filtering for IP destinations.
2. After moving the deny, a guest still reaches 192.168.100.10 on 8443. The deny lists 192.168.100.0/24. What do you check?
Read the worked answer
Check zone membership and NAT. If the guest gateway interface is in the Trust zone, the traffic is intra-zone Trust-to-Trust and never hits the Guest rules; the default intra-zone action may allow it. Verify the interface zone and the session details showing source and destination zones. Check destination NAT: if a DNAT rule translates a public address to 192.168.100.10, ensure the deny matches the address the security policy evaluates after NAT. Check for a more specific allow above the deny, and for IPv6 or another path. Fix the zone assignment or add an intra-zone deny; do not just add another rule below.
3. How would you design the rulebase so guests get internet access but no internal access, while allowing DNS and DHCP?
Read the worked answer
Use explicit zones and least privilege. Rules: allow Guest to Untrust for web-browsing, ssl, dns, and dhcp with service application-default and security profiles; deny Guest to Trust and DMZ with logging; deny Guest to Guest, or allow DHCP only to the internal DHCP server if required; finish with a cleanup deny. Place denies above broad allows if a broad allow is used. Use application-default rather than service any, but note some applications need explicit ports. For DNS and DHCP, allow only to the internal resolver and DHCP server, not to any. Log at session end and use deny logs for visibility. Avoid destination any in the allow; if used, pair it with a negate for RFC1918 or follow it with a deny.