Firewall Filters and Security Policies
Firewall Filters and Security Policies tests two different mechanisms that are easy to conflate: stateless firewall filters and stateful, zone-based security policies. You must know where each is evaluated and which one can see a session.
Firewall filters
Filters are stateless and applied to an interface or VLAN. Terms are evaluated top-down, first match wins, and an implicit discard applies if no term matches. Actions include accept, discard, reject, count, log, policer, and CoS actions such as forwarding-class and loss-priority. Two-color policers mark conforming/exceeding; three-color policers add a medium burst. Ingress filters run before flow processing, so a filter can drop traffic before a policy ever sees it.
Security policies
Policies are stateful and evaluated once per session, first packet only, in this order: from-zone to-zone policy set, then global policy, then default deny. Match fields include source-address, destination-address, application, source-identity, and dynamic application. Actions are permit, deny, reject, or tunnel. Use insert to control order, and enable logging or counting on the term you care about.
Worked example
Permit HTTPS from 10.10.0.0/16 to any untrust destination, log it, and explicitly deny the rest: set the ALLOW-WEB policy match source-address WEB and application junos-https, then permit and log session-close. Then add a DENY-REST policy with application any and action deny. Reasoning: the default deny is implicit and has no useful counters; an explicit deny policy gives hit counts and logs. Order matters-put ALLOW-WEB before DENY-REST.
Traps
- Applying an ingress filter and expecting it to match translated addresses; filters see pre-NAT packets.
- Using reject when a silent drop is required; reject sends TCP RST or ICMP unreachable.
- Forgetting that policy source-identity needs user firewall and a working identity source.