Which of the following should be configured on the router to filter traffic at the router level access control list anti spoofing rules SSH telnet?

Solution ID	sk100500
Technical Level
Product	Quantum Security Gateways, ClusterXL, Cluster - 3rd party, VSX
Version	R75.45 (EOL), R75.46 (EOL), R75.47 (EOL), R76 (EOL), R77 (EOL), R77.10 (EOL), R77.20, R77.30 (EOL), R80.10 (EOL), R80.20, R80.30, R80.40
OS	Gaia
Platform / Model	All
Date Created	2014-11-12 00:00:00.0
Last Modified	2021-01-28 06:40:00.0

Solution

This article explains how to configure Policy-Based Routing (PBR) on Gaia OS to route traffic according to user-defined policies.

Table of Contents:

1. Introduction

2. Support for Policy-Based Routing (PBR)

3. Limitations

4. Configuring Policy-Based Routing (PBR)

   1. In Gaia Portal

   2. In Clish

   3. Configuring PBR with 2 ISPs:

5. Verifying Policy-Based Routing (PBR) configuration

6. Related documentation

7. Related solutions

(1) Introduction

• 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

The Policy Rules also specify the action to take if the traffic is matched:

• Prohibit: Send a "Prohibit" message to the sending host.
• Unreachable: Send an "Unreachable" message to the sending host.
• Table: Process the traffic according to rules defined in an "Action Table"

You can define many Policy Rules. Traffic is compared with all the rules in order of the 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 (this may include single hosts to entire networks) 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.
For example, a company may want all traffic from a specific source to use a different route instead of using the default gateway; this can be defined in the action tables for Policy-Based Routing (PBR).

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, it is then 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, the packet is then 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 (refer to sk101562).

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

(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
  • URL Filtering
  • IPS
  • Locally-generated traffic
  • Security Servers
  • Data Loss Prevention (DLP) blade
  • VPN Domain Based
  • VPN Route Based (VPN + PBR is supported starting in R80.40 Jumbo Hotfix Take 10 and R81 Jumbo Hotfix Take 2. 
  • Remote Access VPN
  • 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: For VSX mode, see Section 2 (Support for Policy-Based Routing).

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

Make sure 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:

   

   Parameter	Description
   Table Name	The name of the Policy Table.
   Table ID	A numerical ID for the Policy Table. Assigned by the system.
   Default Route	The default static route in the system routing table.
   Destination	The destination of the route.
   Subnet mask	Subnet mask for the destination of the route.
   Next Hop Type	Select 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 address	Next hop gateway IPv4 address.
   Gateway Interface	Security Gateway interface that leads to the next hop gateway.
   Gateway Priority	The 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

    

    Parameter	Description
    Priority	Many 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.
    Action	The 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.
    Match	This 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 that routing is working as expected, refer to "(5) Verifying Policy-Based Routing (PBR) configuration" section.

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

Note: For VSX mode, see section 2 (Support for Policy-Based Routing (PBR) above. To configure a Virtual Router / Virtual System, you must first change the context to that Virtual Device with the "set virtual-system <VSID>" command.

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 higher, 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.

(4-C) Configuring PBR with 2 ISPs

1. PBR Table 1 has already been configured to use ISP1.

2. Configure PBR for a new route to take ISP2:

a. Go to Gaia Portal > View Mode > Advanced > Advanced Routing > Policy Based Routing > Add > Action Table and enter the information for the following:

• • • Table Name
    • Destination
    • Subnet Mask
    • Next Hop Type
    • Add Gateway: IP Address or Network Interfaces

3. Add Policy Rule:

• • Priority
  • Table
  • Interface
  • Source IP: x.x.x.x and Subnet Mask: x.x.x.x
  • Destination: x.x.x.x and Subnet Mask: x.x.x.x
  • Service Port 
  • Protocol

4. Verify the Policy-Based Routing Configuration: [Expert@HostName]# ip rule list

5. Action Table: [Expert@HostName]# ip route list table TABLE_ID

Note: Make sure the default route points at ISP1, and that you have a PBR rule that says the network for which you want to use ISP2 has a default route through ISP2. 

(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 eth2.

• Method 2

  Another method of verifying that 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 (eth2) 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.

• Gaia Administration Guide (R75.40, R75.40VS, R76, R77.X, R80.10).
• Gaia Advanced Routing Administration Guide (R75.40, R75.40VS, R76, R77.X, R80.10)

• sk86187 - Policy Based Routing fails when only default route tables defined
• sk101562 - Policy Based Routing rules matching NATed source address do not work
• sk84480 - Security Gateway on Gaia OS does not send ARP Replies to the directly connected network after adding a Policy-Based Route (PBR) for that network
• sk70380 - Gaia FAQ - Frequently Asked Questions

Applies To:

• This SK replaces sk51564

Which of the following is the most important thing to do to prevent console access to the router?

Which of the following is the most important way to prevent console access to a network switch?

Which of the following types of proxies can be used for Web filtering?

Which of the following is the best solution to allow access to private resources from the Internet?