A housing authority needs an IPv4 ACL that allows HTTPS to a civic portal VIP from guest networks while denying other TCP to that VIP. Which ACL capability is required?
Select an answer to reveal the explanation.
Short Explanation
Guest Wi-Fi needs a bouncer who checks both the address and the service. Extended ACLs read protocol and ports—standard ACLs only glance at who sent the packet.
Full Explanation
A housing authority that must allow HTTPS to a civic portal VIP from guest networks while denying other TCP to that VIP requires an extended ACL. Extended ACLs can match protocol, source and destination addresses, and TCP ports such as 443, which is exactly the granularity needed to permit HTTPS while refusing other TCP services to the same VIP. The correct capability works because the policy is service-specific, not merely source-address-specific. Using a standard ACL numbered 1–99 that supposedly matches destination TCP ports without addresses fails because standard ACLs match source IPv4 addresses only and cannot select destination TCP ports. Relying on uRPF loose mode alone to open HTTPS without ACL entries fails conceptually: uRPF validates reverse-path plausibility of sources; it does not implement application permit/deny policy for port 443. A time-range with no access-list statements fails because a schedule object does nothing by itself—ACEs must reference the time-range to affect forwarding. Exam caveat: remember implicit deny at the end of the ACL; if return traffic or related flows also traverse the same filter direction, they need explicit permits or a design that filters only the unwanted forward direction. Operational check: craft extended ACEs permitting TCP to the VIP on port 443 from guest sources, deny other TCP to the VIP as required, apply inbound/outbound correctly on the guest path, and confirm with hit counters and HTTPS test sessions from guest networks.