The NPM checks primary actions for each VAP group independently.
When the packet ingresses the NPM, it will record an action for all VAP groups that have a rule to match this flow. In our case, an ICMP packet matches a “loadbalance” rule in VAP group fw_intranet (slot 3, for example) but it also matches a “drop” rule in VAP group fw_internet with a priority of 11.
The next criteria the NPM will try to match before it executes ANY action is reachability. An action is recorded for both groups because each has a rule to match ICMP.
However, because the NPM receives a packet on a circuit that is bound only to the VAP group fw_intranet, the action recorded for this VAP group is the only action taken at this time. Because only one VAP group is reachable to this packet, the different priorities are irrelevant across the VAP groups.
When only one VAP group is reachable, priority only helps determine which rule within a VAP group should be matched. In our case, the priority 11 determines that the “no_icmp” rule should be matched over the “internet_lb “ rule, but that is all (remember the default priority is 10).
Now imagine you want to setup an IDS VAP group and send traffic simultaneously to the IDS and fw_intranet VAP group. First you will tap the circuit “intranet”. This makes the IDS and fw_intranet VAP group reachable on the same circuit.
Now priority could possibly play a role between the VAP groups.
However, in our case, we are deploying IDS… which means we enable promiscuous mode on the tap circuit. Promiscuous mode will allow the IDS group to see all flows that match one of its flow rules regardless of priority between the ids and intranet VAP groups… this is important.
To send all traffic simultaneously to the IDS and fw_intranet VAP groups, enable promiscuous mode on the circuit intranet for the IDS VAP group and configure a loadbalance rule for the IDS VAP group.
One example of where priority would play a role is when we want to be specific about the protocols that will be forwarded to IDS.
Here is my configuration. It’s one of our strong points to leverage the NPM to make the IDS more efficient by forwarding ONLY desired protocols to that VAP group. Packet loss is a major factor with IDS and the fw:ids ratio, in terms of packet processing, is almost 4:1. Many customers will be interested in seeing HTTP only on an external IDS.
I can avoid forcing the IDS to receive those protocols which are not being monitored with this configuration, which should improve my ratio.
In this configuration, the IDS VAP group only has logic for source and dest port 80. No other traffic will be forwarded to the IDS group.
vap-group fw_intranet
flow-rule-set intranet_rules
ip-flow-rule intranet_lb
action load-balance
activate
vap-group fw_internet
flow-rule-set internet_rules
ip-flow-rule internet_lb
action load-balance
activate
ip-flow-rule no_icmp
priority 11
protocol 1 1
activate
vap-group iss
flow-rule-set iss_frs
ip-flow-rule iss_80_src
action load-balance
priority 11
source-port 80 80
activate
ip-flow-rule iss_80_dst
action load-balance
destination-port 80 80
activate
circuit intranet circuit-id 1
vap-group fw_intranet
ip-forwarding
ip 172.17.1.1/24 172.17.1.255
vap-group iss
promiscuous-mode
Notice the ip-flow-rule “iss_80_src” with a priority of 11. Unfortunately, creating only a flow rule for destination port 80 is not enough for bi-directional processing. I must create this source port rule to be sure that the IDS will see the return flows for HTTP traffic. Another issue is that the source-port 80 and dest-port 80 ip-flow-rules cannot coexist with the same priority. Also a limitation. So I must increase the priority of one of the two rules. In this case I am forced to increase the source-port 80 rule priority to 11. This priority would be higher than the default priority of my loadbalance rule for my intranet firewall. Of course, firewall must also receive this flow.
Reachability plays a role here.
Assume the HTTP request is generated from 172.17.1.x/24. Because a packet with a source port of 80 MUST be a response packet, with our configuration, reachability will prevent the packet from performing the priority 11 source-port 80 action in IDS before it will perform the action for the priority 10 loadbalance rule for fw_intranet. As it egresses fw_intranet, it will fire on the source port 80 rule and IDS will see it.
If the 172.17.1.0/24 segment was HOSTING the web server, and HTTP requests were inbound destined for the 172.17.1.0/24 segment, I would switch the priority on the IDS rules so that source port 80 is now priority 10 and destination port 80 is priority 11. Reachability will help determine the path of the packet. And when the HTTP server responds, the packets that hit the NPM will be sourced with port 80, matching both firewall loadbalance and ids source port 80 rules both at priority 10. Just as above, the inbound packet with a destination of 80 would reach fw_intranet first and then ids.
Another easy way to do this is to be sure the fw_intranet group has a loadbalance rule with priority 11 and ids has a rule of 11 and 10. With promiscuous mode enabled on the IDS intranet circuit, the firewall priority 11 rule AND the ids priority 10 rule will fire simultaneously. At this time reachability is irrelevant because every scenario will match a flow rule. Promiscuous mode makes this possible.
If we were not deploying IDS, and instead we had 2 firewalls sitting side by side, we would not enable promiscuous mode. If the firewalls were bound to the same circuits, meaning both were reachable, the priority would always determine which way the packet would go.
Here’s a sample configuration. The customer wants only specific protocols to traverse each firewall.
The goal is to enable syncing on the general purpose firewall but to disable sync on the firewall intended to process HTTP and DNS, to increase the new session per second capabilities in Checkpoint.
The drop_dst rules are there to mask the IPs on the fw00sync group from the rest of the world.
Notice here that the IDS group has only any/any/loadbalance + promiscuous and this IDS sees everything.
vap-group fw00sync
flow-rule-set lb_sync
ip-flow-rule InternetIP2_drop_dst
priority 30
destination-addr 172.16.1.1 172.16.1.1
activate
ip-flow-rule IM2IP2_drop_dst
priority 30
destination-addr 172.17.1.1 172.17.1.1
activate
ip-flow-rule fw00sync_statefull_pop_dst
action load-balance
priority 29
destination-port 110 110
activate
ip-flow-rule fw00sync_statefull_pop_src
action load-balance
priority 28
source-port 110 110
activate
vap-group fw00nosync
flow-rule-set lb_nosync
ip-flow-rule fw00nosync_http_dst
action load-balance
priority 29
destination-port 80 80
activate
ip-flow-rule fw00nosync_http_src
action load-balance
priority 28
source-port 80 80
activate
ip-flow-rule fw00nosync_smtp_dst
action load-balance
priority 29
destination-port 25 25
activate
ip-flow-rule fw00nosync_smtp_src
action load-balance
priority 28
source-port 25 25
activate
ip-flow-rule fw00nosync_dns_dst
action load-balance
priority 29
destination-port 53 53
activate
ip-flow-rule fw00nosync_dns_src
action load-balance
priority 28
source-port 53 53
activate
ip-flow-rule fw00nosync_icmp
action load-balance
priority 27
protocol 1 1
activate
vap-group ids00iss
flow-rule-set lb_ids
ip-flow-rule loadbal_ids
action load-balance
activate
#
circuit FWMGMT
vap-group fw00sync
ip-forwarding
ip 192.168.30.231 255.255.255.0 192.168.30.255 increment-per-vap 192.168.30.232
vap-group fw00nosync
ip-forwarding
ip 192.168.30.233 255.255.255.0 192.168.30.255 increment-per-vap 192.168.30.234
circuit Internet
vrrp 1
priority backup-1
mac-usage vrrp-mac
failover-group internet_backup
vap-group fw00sync
ip-forwarding
ip 172.16.1.2 255.255.255.0 172.16.1.255
vap-group fw00nosync
ip-forwarding
ip 172.16.1.1 255.255.255.0 172.16.1.255
vap-group ids00iss
promiscuous-mode
circuit IM2
vrrp 2
priority backup-1
mac-usage vrrp-mac
failover-group internet_backup
vap-group fw00sync
ip-forwarding
ip 172.17.1.2 255.255.255.0 172.17.1.255
vap-group fw00nosync
ip-forwarding
ip 172.17.1.1 255.255.255.0 172.17.1.255