Security Policies, NAT, and Authentication
Policy evaluation
Security policies are evaluated top-down and stop at the first match; ordering is therefore a security control. A broadly permissive rule placed above a specific deny rule shadows it. Most firewalls end with an implicit deny-all, often logged. A policy matches on ingress/egress zone (or interface), source, destination, service, and optionally user or application identity. NAT should not be treated as a substitute for policy: translated traffic still needs a permitting rule, and some platforms match policy before translation while others match after destination translation.
NAT fundamentals
Source NAT (SNAT) hides internal addresses and is applied after routing. Destination NAT (DNAT), often called a virtual IP or port forward, rewrites the destination before routing and is commonly used to publish internal services. Traps include: forgetting the return path for DNAT, allowing the public address instead of the translated address in policy, and missing NAT exemption for site-to-site VPN traffic that must not be translated.
Authentication
Identity can be established locally or through LDAP, RADIUS, or TACACS+, with MFA and single sign-on adding stronger assurance. User or group objects can appear in policies, but authentication only occurs when the matching policy requires it. Common pitfalls: a service is blocked before the captive portal can load, group membership is cached, or timeouts expire the session silently.
Worked example
An internal web server 192.168.10.20 is published on 203.0.113.10:443. The DNAT rule maps the public address to the private one; the policy must permit external zone to internal zone for the translated destination and service, and the server's default gateway must return traffic through the firewall. Test with the public address, not the private one.