The Shaper That Doesn't Shape and the QUIC That Escapes
A FortiGate 60F has wan1 200/50 Mbps. Guest VLAN 10.50.0.0/24 and staff 10.10.0.0/24. Policy 1: staff -> wan1, service ALL, NAT, profile staff (AV, web filter, app control, certificate inspection), priority high. Policy 2: guest -> wan1, service ALL, NAT, profile guest (AV, web filter, app control, certificate inspection), traffic shaper guest-20M. The shaper object is per-IP with maximum bandwidth 20000 kbps. During an evening game update, guest traffic reaches 150 Mbps and staff VoIP degrades. Guest logs show HTTP AV scans but no web-filter entries for youtube.com; browsers show locks and the sniffer shows UDP 443 flows from guest devices.
1. Do the math on the shaper and explain why guest traffic reached 150 Mbps. What shaper configuration actually protects the WAN?
Read the worked answer
The shaper is per-IP, so the 20 Mbps limit applies independently to each guest device. With 50 guests, the theoretical aggregate is 50 x 20 Mbps = 1000 Mbps, and 150 Mbps is well within that. The WAN is 200 Mbps, so guests can consume most of it while each individual device still appears compliant.
A shared shaper applies one maximum to all traffic matching the policy. Setting guest-20M to shared with a 20000 kbps maximum caps the aggregate guest load at 20 Mbps, leaving 180 Mbps for staff and VoIP. That is the change that protects the link.
One shaper is applied per policy direction, so a per-IP shaper cannot by itself guarantee an aggregate cap. If per-user fairness is also required, use a lower per-IP value in combination with a shared aggregate control through the appropriate shaping policy design, and verify the resulting behavior with diagnose netlink interface list wan1 and shaped-traffic counters. Do not assume the per-IP value is an aggregate limit.
2. Why are youtube.com and many other flows not appearing in web-filter logs despite the profile, and what is the security impact?
Read the worked answer
The browsers are using QUIC over UDP 443. QUIC is encrypted and is not proxied by the web filter or antivirus in the same way as TCP 443; the FortiGate sees application control metadata but not the HTTP content the web filter needs. That explains HTTP AV scans without corresponding web-filter entries.
The security impact is that URL categorization, file scanning, and certificate inspection are bypassed for those flows. The usual fix is to block the QUIC application in the application control profile so browsers fall back to TCP 443, where the existing web filter, AV, and certificate inspection apply. Verify the fallback with a sniffer: UDP 443 should disappear and TCP 443 should appear for the same user.
This is a policy decision: blocking QUIC may affect some applications, but it is normally acceptable for a guest network and restores visibility.
3. Does the 'priority high' setting on the staff policy reserve bandwidth for VoIP? What would you do to protect voice during guest saturation?
Read the worked answer
No. Traffic shaping priority affects queuing only when the interface is congested; it does not reserve bandwidth. If guests are allowed to fill the link, voice can still be delayed or dropped before the priority setting helps.
The effective design is to cap the guest aggregate with a shared shaper (20 Mbps), then use priority or a guaranteed-bandwidth shaper for the staff/voice traffic. With 200 Mbps total and guests capped at 20 Mbps, roughly 180 Mbps remains; 20 concurrent voice calls at about 100 kbps each need only about 2 Mbps, so the cap alone solves most of the problem. Priority high on the voice policy then reduces jitter during any remaining congestion.
Monitor the result rather than assuming: check shaped and dropped counters and confirm that guest throughput stays at or below 20 Mbps during the next update cycle.