Remote city workers often join from untrusted café Wi-Fi, then VPN into municipal systems. What firewall posture best fits that path?
Select an answer to reveal the explanation.
Short Explanation
Café Wi-Fi is untrusted even after a VPN pops up. Treat VPN ingress with stateful firewall policy, not blanket trust. Café splash pages are not municipal EAP-TLS.
Full Explanation
Remote city workers who join from untrusted café Wi-Fi and then VPN into municipal systems should face stateful firewall policy on that VPN ingress as an untrusted entry path. The VPN authenticates and encrypts the tunnel, but the traffic that emerges into city networks still needs inspection, allowlisting, and logging appropriate to remote access. Treating café-origin sessions as automatically equivalent to on-campus EAP-TLS clients over-trusts the path and the endpoint posture. Permitting any protocol from any Wi-Fi SSID straight into an EHR VLAN without inspection ignores both remote-access risk and clinical data sensitivity. Disabling all VPN accounting so café sessions leave no logs removes accountability required for municipal audits. Trusting café captive portals as equivalent to city EAP-TLS confuses a third-party splash page with enterprise authentication. Exam caveat: split-tunnel decisions change what the firewall sees—document whether full-tunnel is required for workers who handle sensitive systems so policy enforcement remains consistent. Operational check: connect a test laptop over a public SSID via VPN, verify firewall logs show the session as remote or untrusted ingress, and confirm only approved municipal destinations succeed while direct EHR shortcuts without policy fail.