CPUG: The Check Point User Group

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


Tim Hall has done it again! He has just released the 2nd edition of "Max Power".
Rather than get into details here, I urge you to check out this announcement post.
It's a massive upgrade, and well worth checking out. -E

 

Results 1 to 7 of 7

Thread: SecureXL and ICMP

  1. #1
    Join Date
    2007-05-15
    Posts
    21
    Rep Power
    0

    Default SecureXL and ICMP

    Hiya,

    Going by the docs it has that ICMP disables SecureXL which was always my understanding. However I've been re-organising our rulebase a bit and seeing that SecureXL is disabled after rules much further down than the first ICMP rule? We did have some client-auth higher up and once moving them down a bit they are where its getting disabled so just trying to work out what the story is. Is it not giving the correct rule numbers or... ? We have some rules that have a lot of ICMP (monitoring tools etc) so wondering if we would see a performance hit by having these near the top due to the very high hit counts or if it is "actually" disabling secureXL so better to put near the end of the rulebase to maximise improvements from acceleration for other things?

    Other than running "fwaccel stats -s" are there better ways to monitor the "real" performance benefits to aid in deciding if rules that have high hitcounts but disable SecureXL will actually have better overall performance benefits having it nearer the top and disabling securexl further down, or if its better to have near the bottom sort of thing.

    Cheers

  2. #2
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,251
    Rep Power
    14

    Default Re: SecureXL and ICMP

    Quote Originally Posted by cameronem View Post
    Hiya,

    Going by the docs it has that ICMP disables SecureXL which was always my understanding. However I've been re-organising our rulebase a bit and seeing that SecureXL is disabled after rules much further down than the first ICMP rule? We did have some client-auth higher up and once moving them down a bit they are where its getting disabled so just trying to work out what the story is. Is it not giving the correct rule numbers or... ? We have some rules that have a lot of ICMP (monitoring tools etc) so wondering if we would see a performance hit by having these near the top due to the very high hit counts or if it is "actually" disabling secureXL so better to put near the end of the rulebase to maximise improvements from acceleration for other things?

    Other than running "fwaccel stats -s" are there better ways to monitor the "real" performance benefits to aid in deciding if rules that have high hitcounts but disable SecureXL will actually have better overall performance benefits having it nearer the top and disabling securexl further down, or if its better to have near the bottom sort of thing.

    Cheers
    There are two parts to SecureXL: Packet/Throughput Acceleration and Session Rate Acceleration/Templating.

    ICMP is never Throughput Accelerated nor Session Rate Accelerated but has no effect on Session Rate Acceleration templating further down in the rulebase. You can use ICMP anywhere in your rulebase (including as an implied rule with positioning set to First) and it will have no effect on whether the rules below it can be templated.

    When it comes to Session Rate Acceleration, there are two situations that can keep a connection/rule from getting templated:

    1) Use of individual Services that can't be templated, but do not impact the templating of other rules below - ICMP, connections with a special "handler/protocol type" like FTP and H.323, GRE

    2) Use of certain objects in the rulebase that disable acceleration from that point on in the rulebase - this is what you see in "fwaccel stat" when it says "disabled from rule #XXX". If you don't see that message you don't have this condition present and all accepted traffic will potentially be templated, subject to #1. Situations known to disable templating for the rule using it and all rules below it are domain objects, time objects, and Legacy Authentication (User/Session/Client) rules.

    So I think your "fwaccel stats -s" output is correct. Generally you want the rules with the highest hit counts towards the top of the rulebase as much as possible.
    Last edited by ShadowPeak.com; 2015-03-14 at 11:45.

  3. #3
    Join Date
    2007-05-15
    Posts
    21
    Rep Power
    0

    Default Re: SecureXL and ICMP

    Awesome thanks :) That sure clears things up regarding ICMP for me :)

  4. #4
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,251
    Rep Power
    14

    Default Re: SecureXL and ICMP

    Quote Originally Posted by cameronem View Post
    Awesome thanks :) That sure clears things up regarding ICMP for me :)
    You're welcome, these two functions of SecureXL get confused with each other all the time. You may have noticed I prefer to call Packet/Throughput Acceleration "acceleration" (in my classes I will also sometimes call this "shortcutting" or "shunting") and Session Rate Acceleration "templating"; unless anyone else can come up with more applicable terminology I'm sticking with these terms going forward. :-)

  5. #5
    Join Date
    2007-05-15
    Posts
    21
    Rep Power
    0

    Default Re: SecureXL and ICMP

    Hi Again,

    So I've been doing a lot of tuning etc of the rulebase for rule ordering etc and haven't been able to find much in terms of an explanation of what the violations actually mean in particular what I've bolded? Do you have a link or anything that explains them in more detail? Obviously not everything will go through SecureXL but more out of interest cause why not try and get as much as possible :)

    I'm especially surprised by the "routing decision err" one, It'd make sense if there was no default route but why would there be a routing error if there is a default? Especially since its a pretty high count


    fwaccel stats -p
    F2F packets:
    --------------
    Violation Packets Violation Packets
    -------------------- --------------- -------------------- ---------------
    pkt is a fragment 1966845 pkt has IP options 0
    ICMP miss conn 521895731 TCP-SYN miss conn 6951844
    TCP-other miss conn 187773 UDP miss conn 345401182

    other miss conn 21824 VPN returned F2F 0
    ICMP conn is F2Fed 0 TCP conn is F2Fed 14289669
    UDP conn is F2Fed 134925 other conn is F2Fed 0
    uni-directional viol 0 possible spoof viol 0
    TCP state viol 396715 out if not def/accl 0
    bridge, src=dst 0 routing decision err 980329
    sanity checks failed 0 temp conn expired 3298
    fwd to non-pivot 0 broadcast/multicast 0
    cluster message 0 partial conn 0
    PXL returned F2F 77050 cluster forward 0 Have this one on other FW
    chain forwarding 0 general reason 0

  6. #6
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,251
    Rep Power
    14

    Default Re: SecureXL and ICMP

    Quote Originally Posted by cameronem View Post
    Hi Again,

    So I've been doing a lot of tuning etc of the rulebase for rule ordering etc and haven't been able to find much in terms of an explanation of what the violations actually mean in particular what I've bolded? Do you have a link or anything that explains them in more detail? Obviously not everything will go through SecureXL but more out of interest cause why not try and get as much as possible :)

    I'm especially surprised by the "routing decision err" one, It'd make sense if there was no default route but why would there be a routing error if there is a default? Especially since its a pretty high count


    fwaccel stats -p
    F2F packets:
    --------------
    Violation Packets Violation Packets
    -------------------- --------------- -------------------- ---------------
    pkt is a fragment 1966845 pkt has IP options 0
    ICMP miss conn 521895731 TCP-SYN miss conn 6951844
    TCP-other miss conn 187773 UDP miss conn 345401182

    other miss conn 21824 VPN returned F2F 0
    ICMP conn is F2Fed 0 TCP conn is F2Fed 14289669
    UDP conn is F2Fed 134925 other conn is F2Fed 0
    uni-directional viol 0 possible spoof viol 0
    TCP state viol 396715 out if not def/accl 0
    bridge, src=dst 0 routing decision err 980329
    sanity checks failed 0 temp conn expired 3298
    fwd to non-pivot 0 broadcast/multicast 0
    cluster message 0 partial conn 0
    PXL returned F2F 77050 cluster forward 0 Have this one on other FW
    chain forwarding 0 general reason 0
    I don't believe these are documented anywhere but I'll take a shot, keep in mind these are just educated guesses.

    I think "miss conn" refers to a packet for which a session acceleration template is not available. This would frankly happen quite a bit of the time especially with TCP. Note how TCP SYN packets are broken out separately (and a much higher number) than all other TCP flag combinations combined. At least the first time a new, never-seen-before TCP connection (i.e. can't just mask/ignore the source port number to match a previous TCP connection) starts the Accelerated Path would punt it up into F2F and increment the "TCP-SYN miss conn" counter. I'd guess that "TCP-other miss conn" would be TCP ACK/PSH packets associated with a connection that has been timed out of the state table or lingering RST/FIN packets after a TCP connection has been removed from the firewall's state table but one or both of the endpoints have not yet figured out it is dead. ICMP can never be templated so the "ICMP miss conn" counter basically shows every ICMP packet the Accelerated Layer has received and is a big number. These counters may also refer to situations where connections cannot be throughput rate accelerated by SecureXL, hard to tell.

    "con is F2Fed" connections probably refer to connections that the Accelerated Path knows about and are considered valid, but the connection is subject to some kind of inspection that is forcing it up to the Medium or Firewall Path such as IPS, APCTL/URLF, Threat Prevention, etc and therefore Throughput Rate Acceleration is not possible.

    I'd guess "routing decision error" means that the Accelerated Path does not know the egress interface for a packet that has arrived on the SecureXL acceleration device on the inbound interface side, and had to send it up the inbound Firewall Path, through Gaia IP routing, down the outbound Firewall Path, and back into the SecureXL acceleration device on the outbound interface side so SecureXL could "see" where the packet was supposed to egress. From that point on the Accelerated Path would know where the packet should egress and would shortcut the packet directly across in the Accelerated Path thus skipping the inbound/outbound Firewall Path and Gaia IP routing. Another guess is that it could also be directed IP broadcasts (i.e. 192.168.1.255) or generic broadcasts (0.0.0.0/255.255.255.255) showing up and SecureXL doesn't know how to route them. They shouldn't be routed unless there is some kind of helper address or DHCP Relay present anyway and perhaps this counter is incremented when it doesn't know how to route these packets (Gaia IP routing wouldn't either though so perhaps SecureXL just discards the broadcast packets itself and increments this counter).

    The only thing I would think "cluster forward" would indicate is possibly the presence of asymmetric routing between the firewall cluster members in a Load Sharing (active/active) scenario. Perhaps it is indicating the "flush and ack" scenario (sk100226) occurring in the Accelerated Path? If so I'd think this counter would be zero in a High Availability (active/passive) scenario.

    Once again these are just guesses, I'm sure there is someone deep inside Check Point who knows the definitive answers. :-)

  7. #7
    Join Date
    2005-08-14
    Location
    Gig Harbor, WA, USA
    Posts
    2,494
    Rep Power
    17

    Default Re: SecureXL and ICMP

    F2F means "Forwarded to Firewall" i.e. slowpath (not accelerated).
    Actually packets that are subject to IPS, et al are still accelerated by SecureXL assuming CoreXL is enabled via the Medium Path (PXL).
    http://phoneboy.org
    Unless otherwise noted, views expressed are my own

Similar Threads

  1. SecureXL vs CoreXL
    By avilT in forum Miscellaneous
    Replies: 10
    Last Post: 2013-03-07, 00:47
  2. icmp drop:ICMP request sent by replying peer
    By nz-ipv6 in forum Miscellaneous
    Replies: 2
    Last Post: 2012-01-12, 10:51
  3. VPN and SecureXL
    By manrag in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 5
    Last Post: 2010-09-28, 08:24
  4. SecureXL
    By Testing-123 in forum Check Point IP Appliances and IPSO (Formerly Sold By Nokia)
    Replies: 1
    Last Post: 2008-09-17, 17:02
  5. SecureXL
    By charliey_2000 in forum Check Point IP Appliances and IPSO (Formerly Sold By Nokia)
    Replies: 12
    Last Post: 2007-12-27, 16:29

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
  •