IP flow rule priorities and how they apply to multiple vap groups

book

Article ID: 168111

calendar_today

Updated On:

Products

XOS

Issue/Introduction

IP flow rule priorities and how they apply to multiple vap groupsN/A

Cause

Understand  applicability of flow rules and multiple VAP group scenarios

Resolution

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

 

Workaround

N/A