Designing Zones and Interzone Policy for a Campus with Guest Wi-Fi
A university is deploying a Huawei USG6650 firewall with four network segments: staff VLAN 10.20.0.0/16, guest Wi-Fi 192.168.30.0/24, a DMZ web server farm 172.16.20.0/24, and the Internet. A database server for the web application sits on the staff segment at 10.20.5.10. Requirements are: guests may use only DNS, HTTP and HTTPS to the Internet and must not reach any internal segment; staff may manage the firewall over HTTPS from 10.20.0.0/16; DMZ web servers must initiate TCP 3306 to the database; all other interzone traffic must be denied. A junior engineer proposes placing the guest network in the Trust zone and writing a deny rule for guest-to-staff traffic, and placing the firewall management address in the DMZ because administrators are on the staff network. The current configuration has a default permit rule at the bottom of the policy list while the team builds out rules.
1. Critique the junior engineer's zoning and policy proposal, and describe the zone and policy design you would implement.
Read the worked answer
Putting guests in Trust is unsafe. Trust is the most privileged internal zone; a single misordered rule, a missing deny, or a policy exception can expose staff resources. The proposed deny rule also depends on rule ordering and does not protect against guest-to-guest or guest-to-firewall traffic. Placing the management address in DMZ is also wrong: DMZ is a lower-trust zone for externally reachable servers, and management access from Trust would then be an interzone flow to a zone exposed to attack. Management belongs to the Local zone, which represents the firewall itself; administrative access should be restricted by service and source address.
A better design uses a dedicated Guest zone (or a separate virtual system/VSYS if scale requires). Zones: Trust for staff, Guest for Wi-Fi, DMZ for web servers, Untrust for Internet, Local for the device. Policies: Guest to Untrust permit DNS, TCP 80, TCP 443; Guest to Trust, Guest to DMZ, and Guest to Local deny. Trust to Local permit HTTPS only from 10.20.0.0/16 to the management address. DMZ to Trust permit TCP 3306 from 172.16.20.0/24 to 10.20.5.10 only. Trust to Untrust permit required business traffic. DMZ to Untrust deny unless updates require a narrow exception. Remove the default permit and end with an explicit deny-all, logging denies.
2. The web servers in DMZ initiate database connections to Trust. Explain why no Trust-to-DMZ policy is required for the return traffic, and what would break that assumption.
Read the worked answer
The firewall is stateful. When the first TCP SYN from 172.16.20.x to 10.20.5.10:3306 is permitted by the DMZ-to-Trust policy, the firewall creates a session entry containing the tuple, sequence information, and translation state. Return packets from the database match that session and are allowed without a separate policy lookup in the Trust-to-DMZ direction. This is why a single unidirectional policy is sufficient for client-initiated connections and why writing a broad reverse policy is both unnecessary and risky.
The assumption breaks if the session is not created or is removed: for example, asymmetric routing where the return packet arrives at a different firewall or interface, a policy change or session aging that clears the entry, or a timeout shorter than the application's idle period. It also breaks for protocols that open separate reverse connections, such as active FTP or some VoIP and multimedia protocols, which need protocol inspection or additional policies. If the database initiates a separate connection back to the web server, that is a new flow and needs its own policy. Troubleshooting should therefore check session existence and aging, not just policy counters.
3. What logging and verification steps would you use to prove the design is working and to catch policy-ordering mistakes?
Read the worked answer
Enable logging on the deny rules and on the sensitive permit rules: Guest-to-Trust, Guest-to-DMZ, Guest-to-Local, and the DMZ-to-Trust database permit. Send logs to a syslog server with accurate timestamps and review zone, source, destination, port, and action. Use policy hit counters to confirm which rule matches traffic, especially when a broad permit sits above a specific deny. Run display security-policy statistics and inspect session tables for the database flow to confirm the return direction is handled by the existing session.
Verification tests should be explicit: from a guest client, attempt DNS, HTTP and HTTPS to the Internet (expected permit), then attempt SSH and SMB to a staff host and HTTPS to the firewall management address (expected deny with logs). From a DMZ server, test TCP 3306 to the database (permit) and TCP 3389 to a staff workstation (deny). From a staff host, test HTTPS to the management address. After each test, compare the expected rule with the actual hit counter and log entry. Finally, remove the temporary default permit only after all required flows are covered, and keep an explicit deny-all with logging so future gaps are visible rather than silently allowed.