Firewall and Network Security
Firewall and Network Security
This domain tests rule evaluation, NAT, VPN enforcement, and cluster behavior on Check Point gateways. The exam expects you to predict which rule matches a packet and where NAT and encryption are applied.
Core rules
- Rules are evaluated top-down within a layer; the first matching rule applies. The cleanup rule is implicit and usually drops or rejects unmatched traffic.
- Implied rules (control connections, DHCP, DNS, and similar traffic) are evaluated before or after explicit rules depending on their position; do not assume explicit rules always win.
- Source and destination are directional. A rule from A to B does not automatically permit B to A unless the service is bidirectional or a return rule exists.
- NAT is applied before the firewall rule match for hide NAT and static NAT, so the rule often sees translated addresses in many designs. NAT rules are evaluated top-down independently of security rules.
- VPN communities add encryption to matching rules; a rule with a VPN community only matches traffic within that community, and unencrypted traffic may fall through to another rule.
- ClusterXL provides High Availability or Load Sharing. The cluster VIP is the address clients use; sync and CCP keep state consistent. Accelerated connections can bypass slow-path inspection, so SecureXL and CoreXL affect troubleshooting.
- Policy installation on a cluster pushes to all members; a failed member can leave the cluster in a degraded state.
Worked example
A client at 10.1.1.10 connects to a web server at 192.168.5.20 on port 443. The gateway hides 10.1.1.0/24 behind 203.0.113.5. A rule permits HTTP and HTTPS from the internal network to the server. The packet matches: NAT translates the source to 203.0.113.5, then the security rule matches on the original internal source and the server destination because the rule's address objects are pre-NAT in this design. Return traffic is un-NATed by the gateway's NAT table. If the rule used the translated address as source, it would not match, which is a common design error.
Traps
- Assuming NAT rules are evaluated after security rules.
- Placing a broad Any-to-Any rule above a specific rule and then wondering why the specific rule has zero hits.
- Forgetting that implied rules may permit traffic you thought was blocked.
- Ignoring SecureXL when a packet capture shows traffic that does not appear in rule hit counts.