CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


** Announcing the #CPUGchallenge **

I'm very happy to announce that CPUG will be hosting "The CPUG Challenge" during CPX this year.
It promises to be a fun and interesting event that will test (and maybe even expand) your knowledge of Check Point.
Whether or not you plan to attend CPX, we have something for you. Please check out this post or the CPUGchallenge.com web site for more information. -E

 

Results 1 to 5 of 5

Thread: Difference between SecureXL and default behavior of firewall

  1. #1
    Join Date
    2016-10-17
    Posts
    2
    Rep Power
    0

    Default Difference between SecureXL and default behavior of firewall

    Hi,

    I just read about SecureXL and could not figure out how SecureXL is different of the default behaviour of the firewall. Mean, if SecureXL is enabled, the firewall will not check rest of the packets deeply and allow if it finds session for same. But is it not same what normally firewall do?

    So can someone please explain to me how it is different?

  2. #2
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    1,934
    Rep Power
    10

    Default Re: Difference between SecureXL and default behavior of firewall

    Quote Originally Posted by stavrohit11 View Post
    Hi,

    I just read about SecureXL and could not figure out how SecureXL is different of the default behaviour of the firewall. Mean, if SecureXL is enabled, the firewall will not check rest of the packets deeply and allow if it finds session for same. But is it not same what normally firewall do?

    So can someone please explain to me how it is different?
    This is a quite deep topic covered extensively in my book but I will try to summarize.

    When SecureXL is enabled (the default), all inbound packets arrive at the SecureXL driver first.

    If the packet is associated with a new connection, SecureXL first tries to decide if this new connection matches an existing template (i.e. has similar attributes except for one value [usually the source port]) to a prior connection that was already permitted by a rule base lookup. If so the connection is immediately permitted by SecureXL and the overhead of a top-down, first-fit evaluation of the entire rule base is avoided. This is the so-called Session Rate Acceleration or "templating" part of SecureXL. Its purpose is to avoid full-fledged rule base lookups for new connections which can become quite costly as the rule base size increases. If a template for the new connection does not exist, SecureXL sends the packet up to the INSPECT driver for a full-fledged rule-base lookup. If the new connection is allowed SecureXL notes the result of the rule base lookup and also observes how the packet is routed in preparation for the next stage.

    Next (regardless of whether the packet is associated with a new connection or existing one) SecureXL must determine which of the three processing paths the connection is eligible to use. The three processing paths in increasing order of overhead are SXL (Accelerated Path), PXL (Medium Path) and F2F (Firewall Path). See the attached diagram for a good depiction of the three paths. Obviously it is desirable for packets to be processed in the most efficient path possible. However this depends on which blades/features are enabled and need to examine the candidate traffic, so SecureXL will decide which path is needed for that particular connection. On most of today's firewalls the overwhelming majority of traffic typically ends up in the Medium Path (PXL) due to blades like APCL, URLF, and IPS being enabled. This optimum path selection performed by SecureXL is known as Throughput Acceleration and is performed at the start of a new connection, and is essentially trying to minimize the amount of CPU used for inspection without sacrificing security.

    One other associated feature of SecureXL is Automatic Interface Affinity, which spreads the processing of SoftIRQ's across multiple cores to ensure buffering misses (RX-DRP counter, viewable with netstat -ni) do not occur at the network interface level as frames are transferred from the physical NIC card to the firewall kernel for processing.

    When SecureXL is disabled there is no templating (all new connections incur a full-fledged rule base lookup), all traffic is forced into the Firewall Path (F2F) by default, and all SoftIRQ processing is crammed onto Core 0 which makes packet buffering misses (RX-DRP) more likely on a busy firewall.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	CheckPoint_Processing_Paths.jpg 
Views:	33 
Size:	170.2 KB 
ID:	1162  
    --
    My book "Max Power: Check Point Firewall Performance Optimization"
    now available via http://maxpowerfirewalls.com.

  3. #3
    Join Date
    2016-10-17
    Posts
    2
    Rep Power
    0

    Default Re: Difference between SecureXL and default behavior of firewall

    Quote Originally Posted by ShadowPeak.com View Post
    This is a quite deep topic covered extensively in my book but I will try to summarize.

    When SecureXL is enabled (the default), all inbound packets arrive at the SecureXL driver first.

    If the packet is associated with a new connection, SecureXL first tries to decide if this new connection matches an existing template (i.e. has similar attributes except for one value [usually the source port]) to a prior connection that was already permitted by a rule base lookup. If so the connection is immediately permitted by SecureXL and the overhead of a top-down, first-fit evaluation of the entire rule base is avoided. This is the so-called Session Rate Acceleration or "templating" part of SecureXL. Its purpose is to avoid full-fledged rule base lookups for new connections which can become quite costly as the rule base size increases. If a template for the new connection does not exist, SecureXL sends the packet up to the INSPECT driver for a full-fledged rule-base lookup. If the new connection is allowed SecureXL notes the result of the rule base lookup and also observes how the packet is routed in preparation for the next stage.

    Next (regardless of whether the packet is associated with a new connection or existing one) SecureXL must determine which of the three processing paths the connection is eligible to use. The three processing paths in increasing order of overhead are SXL (Accelerated Path), PXL (Medium Path) and F2F (Firewall Path). See the attached diagram for a good depiction of the three paths. Obviously it is desirable for packets to be processed in the most efficient path possible. However this depends on which blades/features are enabled and need to examine the candidate traffic, so SecureXL will decide which path is needed for that particular connection. On most of today's firewalls the overwhelming majority of traffic typically ends up in the Medium Path (PXL) due to blades like APCL, URLF, and IPS being enabled. This optimum path selection performed by SecureXL is known as Throughput Acceleration and is performed at the start of a new connection, and is essentially trying to minimize the amount of CPU used for inspection without sacrificing security.

    One other associated feature of SecureXL is Automatic Interface Affinity, which spreads the processing of SoftIRQ's across multiple cores to ensure buffering misses (RX-DRP counter, viewable with netstat -ni) do not occur at the network interface level as frames are transferred from the physical NIC card to the firewall kernel for processing.

    When SecureXL is disabled there is no templating (all new connections incur a full-fledged rule base lookup), all traffic is forced into the Firewall Path (F2F) by default, and all SoftIRQ processing is crammed onto Core 0 which makes packet buffering misses (RX-DRP) more likely on a busy firewall.
    Hi, Thanks for the reply.

    If we are using proxy then it is okay but if we are using connection like I mentioned below and are using SSH/TELNET/WEB or other app. will SecureXL affect it too? If yes, then how?
    And what 3 parameters will it match? Are they Source IP, Destination IP and Destination Port?

    Client ------- Firewall --------- Server

  4. #4
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    1,934
    Rep Power
    10

    Default Re: Difference between SecureXL and default behavior of firewall

    Quote Originally Posted by stavrohit11 View Post
    Hi, Thanks for the reply.

    If we are using proxy then it is okay but if we are using connection like I mentioned below and are using SSH/TELNET/WEB or other app. will SecureXL affect it too? If yes, then how?
    And what 3 parameters will it match? Are they Source IP, Destination IP and Destination Port?

    Client ------- Firewall --------- Server
    The connection will be subject to your security policies regardless of whether SecureXL is on or not; if SecureXL is on the firewall will require less CPU to perform the same operation. The main firewall security policy matches by source, destination, and service (port number) and potentially if the traffic is involved with a VPN tunnel.
    --
    My book "Max Power: Check Point Firewall Performance Optimization"
    now available via http://maxpowerfirewalls.com.

  5. #5
    Join Date
    2006-03-08
    Location
    Lausanne
    Posts
    840
    Rep Power
    12

    Default Re: Difference between SecureXL and default behavior of firewall

    Shadowpeak already explained the main points, as I see.

    Also, if you still need to understand SecureXL better, you can refer to sk98722. It has everything, including traffic flow and packet inspection charts.
    -------------

    Valeri Loukine
    CCMA, CCSM, CCSI
    http://checkpoint-master-architect.blogspot.com/

Similar Threads

  1. Difference between CISCO and Checkpoint Firewall
    By vijay_vya in forum R75.40 (GAiA)
    Replies: 20
    Last Post: 2012-12-19, 08:04
  2. Changing VPN default behavior....for traffic directed to FW peer IP address only ...
    By Eros_G in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 1
    Last Post: 2011-12-01, 15:50
  3. R70.30 P1 and Odd Behavior with VSX
    By sisu-up in forum Provider-1 (Multi-Domain Management)
    Replies: 0
    Last Post: 2010-05-13, 15:42
  4. Difference between Account and Log in the firewall rule
    By Kevin_27 in forum SmartDashboard
    Replies: 3
    Last Post: 2009-08-06, 11:31
  5. Strange VPN Behavior
    By Bruce_A in forum Check Point UTM-1 Edge Appliances
    Replies: 1
    Last Post: 2007-12-18, 07:23

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •