Firewall policies, zones, and NAT
Firewall policies, zones, and NAT
This domain tests the packet-matching pipeline: zone pairs, first-match policy evaluation, policy actions, and the three NAT forms. You must know which address a policy sees after NAT.
Core rules
- A zone-pair policy is evaluated from-zone to to-zone in order; the first match wins. If no zone-specific policy matches, global policies are evaluated, then the implicit deny.
- Match criteria include source address, destination address, application, and source identity; actions include permit, deny, and reject. Logging and session close are policy options.
- Source NAT translates the source address, destination NAT translates the destination, and static NAT creates a fixed one-to-one mapping.
- Destination NAT is applied before policy lookup, so the policy must match the translated destination address. Source NAT is applied after policy lookup, so the policy matches the original source address.
- Destination NAT to an address outside the ingress interface subnet usually needs proxy ARP.
Worked example
Trust hosts 10.10.10.0/24 need HTTP to the internet through ge-0/0/1. Create a source NAT rule matching 10.10.10.0/24 with interface translation on ge-0/0/1. The policy from trust to untrust matches source 10.10.10.0/24, destination any, application junos-http, action permit. Because source NAT happens after policy evaluation, the policy uses 10.10.10.x, not the public interface address. If you instead published an internal server with destination NAT, the untrust-to-trust policy would need the private translated address.
Traps
The most common error is matching the pre-NAT destination in a destination NAT policy. Also watch NAT rule order, missing proxy ARP, and a policy that permits the application but not the return path. The implicit deny is easy to forget when no counters increment.