Checkpoint Firewall Policy Based Routing and limitation.

Checkpoint Policy Based Routing and limitation.


Policy-Based Routing (PBR) lets user create routing tables that enable Gaia OS to direct traffic to appropriate destinations by defining a policy to filter the traffic based on one or more of the following:
  • Interface, at which a packet arrives.
  • Source IPv4 address and subnet mask.
  • Destination IPv4 address and subnet mask.
  • Service Port (e.g.: FTP, SSH, Telnet) added starting in R77.30
  • Protocol Number (e.g.: TCP, UDP, ICMP) added starting in R77.30

You can define many Policy Rules. Traffic is compared with all the rules, in order of rules priority - one rule at a time, according to the priority that is configured for the rule.
Policy-Based Routing (PBR) can be used to direct traffic based on where it is coming from to where it is going (also single hosts or entire networks). This greatly improves the control that network administrators have in regards to the routing of traffic through a network.

Policy-Based Routing (PBR) static routes have priority over static routes in the OS routing table. When a packet arrives at the OS, the packet is checked for a match to a Policy-Based Routing (PBR) static route:
  • If the packet matches, then the packet is forwarded according to the priority of the Policy-Based Routing (PBR) static route.
  • If the packet does not match a Policy-Based Routing (PBR) static route, then the packet is forwarded according to the priority of the static routes in the OS routing table.
Routing and Firewall Processing
It is important to note that routing tables, including PBR tables, are checked after firewall processing is complete.
This means that in situations such as NAT, routing rules are checked against the original source address.




(2) Support for Policy-Based Routing (PBR)

Operating SystemsPBR is supported on the following Gaia OS versions:
  • Security Gateways / Clusters:
    • R75.40 Gaia+
    • R75.45 / R75.46 / R75.47
    • R76
    • R77 / R77.10 / R77.20 / R77.30
    • R80.10 and above
  • VSX mode (only on Virtual Routers):
    • R75.40VS / R76 / R77 and above
HardwareAll Check Point appliances and Open Servers that are supported by the above Gaia OS versions
ClusteringPBR is supported in the following clusters:
  • ClusterXL High Availability
  • ClusterXL Load Sharing Unicast
  • ClusterXL Load Sharing Multicast
  • VRRP
Note:
PBR must be configured on each of the cluster members individually, and the configuration must be identical.
VSXPBR can be configured only on Virtual Routers in the SmartDashboard. When VSX mode is enabled, Gaia Portal is disabled on Security Gateway as it is not supported in VSX mode, and the Clish command "set pbr" command is disabled for Virtual Systems. Furthermore, configuration in the SmartDashboard supports only Source Address and Mask, and Destination Address and Mask.
Notes:
  • Virtual Router is not compatible with VSLS.
  • In VSX mode, PBR supports Source IP, Destination IP and Interface, but not the additional parameters (service port and protocol) that were added starting in R77.30.

(3) Limitations

  • The following features are supported by PBR only starting in R77.30:
    • Service Port-based routing
    • Protocol-based routing
  • The following features are not supported by PBR by default, and are available only as a Request for Enhancement (RFE) via Check Point local office:
    • PBR with Source Port routing
    • PBR with Ping for reachability detection (available only for R77.20)
  • The following features/blades are not supported with PBR:
    • IPv6
    • Locally-generated traffic
    • Security Servers
    • Data Loss Prevention (DLP) blade
    • Anti-Spam blade
    • Mail Transfer Agent (MTA) (relevant for Threat Emulation/Threat Extraction/Data Loss Prevention/Anti-Spam blades)
    • ISP Redundancy
    • The following applications (which use Check Point Active Streaming [CPAS]):
      • VoIP (H323, SIP, Skinny, etc.)
      • HTTPS Inspection
      • HTTP Header Spoofing
      • HTTP Proxy
      • IMAP in IPS

(4) Configuring Policy-Based Routing (PBR)

Note: In VSX mode, Policy Based Routing (PBR) can be configured only in the SmartDashboard and only on Virtual Routers (via the Advanced Routing configuration).
In Gateway mode, Policy Based Routing (PBR) can be configured in Gaia Portal, or in Clish.
The configuration process consists of two parts:
  • Configuring the Action Table
  • Configuring the PBR Rules
Ensure the following items have been completed before attempting to configure PBR:
  • The Security Gateway must be fully configured (including all the relevant Software Blades)
  • Policy must be installed on Security Gateway
  • Basic routing should be working as expected
Example Scenario:
The following scenario will be used to demonstrate the PBR configuration both in Gaia Portal and in Clish:
  • Required configuration:
    • Traffic from the Remote Office network (192.168.1.0/24) destined for the Home Office network (10.1.0.0/16) should be routed via the MPLS Router at 192.168.128.100
    • All other non-local traffic should be sent via the router to the ISP at 192.168.128.74

  • The diagram below shows the network layout:

(4-A) Configuring Policy-Based Routing (PBR) in Gaia Portal

  1. Connect to Gaia Portal on Security Gateway with web browser at https://Gaia_IP_Address
  2. Make sure the View Mode displayed in the upper right-hand corner is set to Advanced:

  3. Go to 'Advanced Routing' pane - click on 'Policy Based Routing':

    The following page opens on the right-hand side:

  4. In the 'Action Table' section, click on 'Add' button:

  5. 'Add Policy Table with Static Route' window opens:

    ParameterDescription
    Table NameThe name of the Policy Table.
    Table IDA numerical ID for the Policy Table. Assigned by the system.
    Default RouteThe default static route in the system routing table.
    DestinationThe destination of the route.
    Subnet maskSubnet mask for the destination of the route.
    Next Hop TypeSelect one of these:
    • Normal: Accept and forward packets.
    • Reject: Drop packets and send unreachable messages.
    • Black Hole: Drop packets but don't send unreachable messages.
    Gateway IP addressNext hop gateway IPv4 address.
    Gateway InterfaceSecurity Gateway interface that leads to the next hop gateway.
    Gateway PriorityThe preference of the particular route. Range: 1-8.

  6. Configure the Policy Table:
    Note: The 'Next Hop Type' field is flagged as an error because setting this field to 'Normal' requires at least one entry in the gateway table. We will add the Gateway in the next step.

  7. In the 'Add Gateway' section, click on 'Add Gateway' button.
    Note: You can select either 'IP Address' or 'Network Interfaces'. For the purposes of this example, we will choose 'IP Address'.

  8. Configure the Gateway and click on 'OK' button:

  9. Check the final Policy Table configuration and click on 'Save' button:

  10. In the 'Policy Rules' section, click on 'Add' button:

  11. 'Add Policy Rule' window opens:
    Note: This screenshot is from R77.30

    ParameterDescription
    PriorityMany Policy Rules can be defined. Traffic is compared to each rule, in order of their priorities, until a match is found or all Policy Rules have been checked.
    ActionThe action to take when traffic matches the rule:
    • Prohibit - Send a Prohibit message to the sending host.
    • Unreachable - Send an Unreachable message to the sending host.
    • Table - Perform the actions defined in an Action Table.
    MatchThis section specifies the criteria traffic must match in order for the Policy Rule to apply. One or more of the following may be used; in this case, traffic must match each criteria in order for the system to apply the Policy Rule.
    • Interface - The interface on which the traffic was received from the host by the Security Gateway.
    • Source, Subnet mask - The IPv4 address and subnet mask of the source.
    • Destination, Subnet mask - The IPv4 address and subnet mask of the destination.
    • Service port – Enter the service port. Some pre-defined ports are: FTP data (20), Telnet (23), HTTP(80), POP2(109).
    • Protocol – Enter the protocol number. Some pre-defined protocols are: ICMP(1), TCP(6), UDP(17).

  12. Configure the Policy Rule and click on 'Save' button:

  13. Check the final Policy Based Routing configuration:

  14. To verify routing is working as expected, refer to "(5) Verifying Policy-Based Routing (PBR) configuration" section.

(4-B) Configuring Policy-Based Routing (PBR) in Clish


  1. Connect to command line on Gaia OS (over SSH, or console).
  2. Log in to Clish.
  3. Ensure you have the database lock, so you can change Gaia configuration:
    HostName> lock database override
  4. Create your Action Table:
    HostName> set pbr table NAME_of_ACTION_TABLE static-route NETWORK_ADDRESS/MASK_LENGTH nexthop gateway address IP_ADDRESS on
    Based on our example scenario:
    HostName> set pbr table HomeOfficeMLPS static-route 10.1.0.0/16 nexthop gateway address 192.168.128.100 on
  5. Create the Policy Rule:
    HostName> set pbr rule priority PRIORITY match from NETWORK_ADDRESS/MASK_LENGTH
    HostName> set pbr rule priority PRIORITY action table NAME_of_ACTION_TABLE
    
    Based on our example scenario:
    HostName> set pbr rule priority 1 match from 192.168.1.0/24
    HostName> set pbr rule priority 1 action table HomeOfficeMLPS 
    
    Note: If you are using service port or protocol in R77.30 or above, then example commands are:
    HostName> set pbr rule priority 2 match port 22
    HostName> set pbr rule priority 2 match protocol tcp
    
  6. Save Gaia configuration:
    HostName> save config
  7. Check the final Policy Based Routing configuration:
    HostName> show pbr summary
    HostName> show pbr tables
    HostName> show pbr rules
    
    Based on our example scenario:
  8. To verify routing is working as expected, refer to "(5) Verifying Policy-Based Routing (PBR) configuration" section.

(5) Verifying Policy-Based Routing (PBR) configuration

  • Method 1

    One method of verifying PBR is configured correctly is to use these commands (in Expert mode):
    • To list the policy rules:
      [Expert@HostName]# ip rule list
      Based on our example scenario:

      Each line is a routing rule, with the priority, matching criteria, and action to take.
      The results show us there are four rules for routing traffic.
      The second line, with a priority of 1, matches the policy we defined (if we had configured the policy with a priority of 3, it still would have been second in the list, but with a priority of 3).
      The action for this rule, "lookup 1", says traffic matching the specified criteria will be handled according to Action Table with ID 1.
    • To list the action tables:
      [Expert@HostName]# ip route list table TABLE_ID
      Based on our example scenario:

      The results show that traffic destined for 10.1.0.0/16 will be routed via 10.10.10.1 out the interface eth1.

  • Method 2

    Another method of verifying Policy Based Routing is working correctly is to capture the traffic using the 'tcpdump' command.
    In our example scenario, all traffic destined for the Home Office Network (10.1.0.0/16) should be destined for the MPLS router at 192.168.128.100, and all other traffic should be destined for the ISP router at 192.168.128.74
    Since both traffic going to the Internet and traffic going to the Home Office exit via the same interface, we need to use the MAC address of each router to identify them in the tcpdump output.
    To obtain the MAC addresses of the routers, enter the following command in Clish:
    HostName> show arp dynamic all
    Based on our example scenario:
    • Display the dynamic ARP entries:
      Note: In this example, there has been recent traffic to both the Internet and to the Home Office.

      Based on these results:
      • Traffic coming to and arriving from the Home Office network should have a Source MAC address or Destination MAC address of 00:0C:29:F3:06:76
      • All other traffic should have a Source MAC address or Destination MAC address of 00:0C:29:C9:24:C9
      To determine this, run the 'tcpdump' command (in Expert mode) on the relevant interface (eth1) with the "-e" flag.
    • Capture the traffic:
      Note: In this example, a host in the Remote Office network is pinging a host in the Home Office.

      The first packet in the output is the ICMP Echo Request from the host in the remote network (192.168.1.5), to the host in the Home Office network (10.1.0.1).
      The Destination MAC address is 00:0c:29:f3:06:76.
      As shown in the output from 'show arp dynamic all' command, this is the MAC address of the MPLS router, which is expected, if the PBR rules are working correctly.
      The second packet is the ICMP Echo Response, which has a Source MAC address of 00:0C:29:F3:06:76, indicating it came from the MPLS router, as expected.

Comments

Popular posts from this blog

Download IOS Image for Router

tcpdumps in Checkpoint Firewall