how to disable SecureXL for specific src to specific dst

[Jeff_Gao]

Dear Team

    sk104468 said that we can disable securexl for specific ip address, I want to disable securexl for specific src ip to specific dest ip  or specific src networks to specific dest networks,how to do it ,thanks!

[HeikoAnkenbrand]

Hi @Jeff_Gao 

As far as I know, this is possible for src and dst. More read here sk104468: How to disable SecureXL for specific IP addresses.

Excluded from PSLXL path (src and dst possible):                        sk156672 - SecureXL Fast Accelerator (fw fast_accel) for R80.20 and above
Excluded from SecureXL (only specific ip address possible):      sk104468: How to disable SecureXL for specific IP addresses 
Excluded SecureXL from VPN:                                                          sk151114 - "fwaccel off" does not affect disabling acceleration of VPN tunnels in R80.20 and above.

More informations here:
- R80.x - Security Gateway Architecture (Logical Packet Flow)
- R80.x - Performance Tuning Tip - SecureXL Fast Accelerator in R80.20 JHF103

[Timothy_Hall · Accepted solution]

Actually sk104468 says this is possible with these directives, although I've never used them:

tcp_f2f_conns = { <src, dest, dport> };
udp_f2f_conns = { <src, dest, dport> };

You can use ranges as well, so you can do something like this in table.def:

tcp_f2f_conns = { <10.0.0.0, 10.0.0.255>, <192.168.0.0, 192.168.0.255>, <1, 65535> };

udp_f2f_conns = { <10.0.0.0, 10.0.0.255>, <192.168.0.0, 192.168.0.255>, <1, 65535> };

ICMP always goes F2F so there is no directive for that protocol.

Just tried it in my lab and it seems to work, first line of output is port range, second is source IP range, third is destination IP range:

[Expert@R81:0]# fw tab -t tcp_f2f_conns
localhost:
-------- tcp_f2f_conns --------
static, id 254
<00000001, 0000ffff>
<0a000000, 0a0000ff>
<c0a80000, c0a800ff>

[Expert@R81:0]# fw tab -t udp_f2f_conns
localhost:
-------- udp_f2f_conns --------
static, id 255
<00000001, 0000ffff>
<0a000000, 0a0000ff>
<c0a80000, c0a800ff>

[Jeff_Gao]

@Timo thanks,this is i wanted.

[Martin_Hofbauer]

Although Checkpoint says in sk104468 that f2f_addresses( or tcp_f2f_conns/udp_f2f_conns )  should be placed in "table.def"  it can be done smarter:

"table.def" is not the best place for it. This file is overwritten on every major upgrade !

Checkpoint has already created a specific file for this $FWDIR/conf/user.def.<FW-version_of_GWs>  ( which will be taken over to the next version, too )
(see https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...)

The only thing you have to create (which is not documented) is a "wrapper" around the statment which Tim has written:
e.g. For R80.xx Gateays you have to use $FWDIR/conf/user.def.FW1  file:

#ifndef __user_def__
#define __user_def__

#ifndef IPV6_FLAVOR

//
// User defined INSPECT code
//

f2f_addresses = {<10.0.0.0, 10.0.0.255>, <192.168.0.0, 192.168.0.255>};

// range_src1 = { <10.0.0.0, 10.7.255.254> };
//
// udp_f2f_conns = { <(range_src1), 10.0.134.1, 53>, <(range_src1),10.0.135.1,53> }

#endif /* ifndef IPV6_FLAVOR */

//
// User defined INSPECT code
//

[Jeff_Gao]

@Timothy_Hall  It seems no working:

[Expert@SH-5600:0]# fw tab -t tcp_f2f_conns
localhost:
-------- tcp_f2f_conns --------
static, id 251
<00000001, 0000ffff>
<01010100, 010101ff>
<02020200, 020202fe>

[Timothy_Hall]

Looks like it is working fine to me, the fw tab output values are in hexadecimal.  You need to run fw tab -t udp_f2f_conns to see the UDP entries.

[juppo]

Is there a way to have multiple entries?

I'd like to exclude a range of source IPs from multiple destination hosts and I wondered what the format would be for that?

e.g. the following seems clear enough if I want to exclude source 10.0.0.0/24 to destination 1.1.1.1 on tcp port 443

tcp_f2f_conns = { <10.0.0.0, 10.0.0.255>, <1.1.1.1>, <443> };

However if I also wanted to exclude the destination 2.2.2.2 how would this look?

[_Val_]

Please read sk104468

[juppo]

Thanks _Val_ I did read sk104468 first and have successfully applied this with multiple entries for f2f_addresses however it doesn't give the format for multiple tcp_f2f_conns

I need to add some additional entries and I could just add them to the f2f_addresses however 90% of the traffic is from a source that is working perfectly fine with SecureXL enabled, so I only want to specifically disable it for the affected traffic flows, hence wanting to use tcp_f2f_conns

[_Val_]

Something like this should work:

tcp_f2f_conns =
{
<A.A.A.A, B.B.B.B, 443>,
<C.C.C.C, D.D.D.D, 80>
};

[Daniel_Kavan]

Hi and thank you,

Does this syntax need to be INSIDE the f2f_addresses = {} brackets?  Looks like they are NOT needed in a post further down.

tcp_f2f_conns = { <10.0.0.0, 10.0.0.255>, <192.168.0.0, 192.168.0.255>, <1, 65535> };

udp_f2f_conns = { <10.0.0.0, 10.0.0.255>, <192.168.0.0, 192.168.0.255>, <1, 65535> };

Also, I was wondering if you could have src or dst as ANY.

[Matlu]

Hello, @Timothy_Hall 

Is it normal for SecureXL to cause problems in certain types of traffic?
For example, a scenario, where you have a manager monitoring many routers that are in different locations, and that flow goes through your Check Point.
The connectivity works fine, the only detail is that “visually” the manager “observes” your monitored equipment as “OFFLINE”, and no apparent root-cause of blocking is found.

Something that turns out to be a solution, is to “turn off” and “turn on” the SXL, and with this, everything works normally.

Can SXL cause problems of this kind?
Does it make sense to always have SXL enabled on Check Point boxes?
What is the process of SXL if one wants to observe it with the cpwd_admin list?

Cheers. 🙂

[Timothy_Hall]

Three Questions:

1) What is the polling management traffic specifically? 

If part of it is ICMP Echo Request packets, those are always F2F/slowpath so the state of SecureXL should be irrelevant.

If it is also SNMP (UDP/161), stateful inspection tracks a virtual session for that UDP traffic in the state table.  Because there is no real concept of a "connection" for UDP, traffic must be exchanged every 40 seconds by default to keep that session "open" and continually tracked.  If it times out a new "session" must start, and unless you are using gateway code prior to R80.20 the first packet of every new connection/session goes F2F/slowpath then is hopefully offloaded in the Medium or Fastpath.

2) What specific service are you using to match the SNMP polling traffic in your policy?  If "Any" is selected in the Accept rule you will get service "snmp" which is straight UDP/161 and will behave as I stated in point 1 (so will snmp-read).  If however you use Snmp-Read-Only instead this will always go slowpath (and disable SecureXL Accept Templating) because that service has raw inspection code embedded in it.

3) What path is your polling traffic in?  This polling session must be alive to use the subsequent commands so first run fw ctl multik gconn and make sure the session is alive and appears here.  Next run fwaccel conns and find the session, if you see an "S" flag it is Medium Path, no "S" flag means fastpath.  If the session does not appear at all in the fwaccel conns output it is slowpath which can be verified by seeing it in fw tab -t connections -z.

Suggestions:

1) Running fwaccel off;fwaccel on has zero impact on existing connections/sessions in R80.20+, they stay wherever they are.  New connections/sessions started while SecureXL is off are simply never offloaded and remain in the slowpath.  I don't see how doing this is having an impact on your problem unless I'm not understanding it correctly, or it is some strange quirk of UPPAK.  It is not possible to permanently disable SecureXL since version R80.20.

2) For whatever service you are using to match the polling traffic, trying increasing its UDP session timeout from 40 seconds to whatever your default polling interval is plus 10 seconds on the Advanced screen of the service itself.  This will help keep the session established and tracked without starting new ones all the time.

3) If the above didn't help and you determined that the polling traffic is fastpath or Medium Path, try forcing it all F2F/slowpath with an f2f_addresses or udp_f2f_conns directive for the polling traffic, that will keep it from ever offloading and remain in the slowpath at all times.  See if that has an effect on the problem.  Whether KPPAK or UPPAK is in use should be irrelevant if you take this approach.  

4) Finally if there are still problems, you can try disabling UPPAK and switch back to KPPAK via cpconfig.  I would not recommend doing this without consulting TAC first and letting them examine your problem.  The process name to observe if UPPAK is enabled is called "usim" or "usim_x86".

[Matlu]

Hello, @Timothy_Hall 

By “UPPAK” you mean what we observe when we throw the command “fwaccel stat”. command, right?

The related point to know, how the Monitoring Manager interacts with these routers that are in different locations, is a bit strange.

According to the Monitoring Manager administrator's comment, they do not “configure” SNMP to monitor these routers that are in different locations.
“Apparently, they simply configure the IP of each element (Router), and I get the impression that they use ICMP to “see” in the monitoring manager platform if the devices are ONLINE or OFFLINE.

Actually, in the platform they see the devices in ONLINE, but this was after “disabling and re-enabling the SXL”, and that's why I have been left with the doubt.

Are there any basic commands to know if the SXL is dropping packets?

Because when I checked the IP of the manager in the SMC logs, everything was green (Good), but they really noticed that “little detail”, that they saw their devices OFFLINE in their platform.

Cheers.

[Timothy_Hall]

Without knowing more about what the actual polling traffic is and what OFFLINE actually means it is difficult to speculate further.  I wouldn't necessarily blame UPPAK for what you are seeing.  If it is just ICMP it is unlikely to be a SecureXL problem.

[Matlu]

OFFLINE is the way the “Monitoring Manager” visualizes a device that is “connected” to its platform.

It does not really affect service, but for the MONITORING part it is important that if a device is well configured, they can see it with the description of “ONLINE” in their platform.

The command fw ctl zdebug drop is helpful to know if the SXL of the FW is dropping packets?

Or are there commands that help a little more in the diagnosis?

[Timothy_Hall]

Use fw ctl zdebug + drop to see all drops including in SecureXL.  

[Matlu]

Hi,

The problem has reoccurred

This forces us every so often to play with ‘Disable and re-enable’ the SXL

Is it possible to make exceptions in the GW for a particular flow?

For example when your source is 10.123.50.50 and the destination is all remote routers with a general segment like 200.117.x.x/16

I would not want to leave SXL completely disabled (I don't think it is convenient)

I have a single GW with URLF+APPC blades that is hooked to a SMART-1 Cloud

[PhoneBoy]

Leaving SecureXL disabled will definitely decrease your overall throughput/performance.
fast_accel is one way to ensure specific traffic is forced into Fastpath: https://support.checkpoint.com/results/sk/sk156672