- Products
- Learn
- Local User Groups
- Partners
-
More
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
IDC Spotlight -
Uplevel The SOC
Important! R80 and R80.10
End Of Support around the corner (May 2021)
69% of my traffic is F2F. I am not running IPS or HTTPS inspection. The majority of the traffic is VPN traffic and currently IP compression is not enabled in the community. I am currently running VSX. Any ideas? Below is some output.
[Expert@fwoc2:3]# fwaccel stats -s
Accelerated conns/Total conns : 93/302 (30%)
Accelerated pkts/Total pkts : 2709202/8804447 (30%)
F2Fed pkts/Total pkts : 6095245/8804447 (69%)
PXL pkts/Total pkts : 0/8804447 (0%)
QXL pkts/Total pkts : 0/8804447 (0%)
[Expert@fwoc2:3]# fw ver
This is Check Point's software version R77.30 - Build 161
[Expert@fwoc2:3]# free -m
total used free shared buffers cached
Mem: 64206 6783 57423 0 1053 2323
-/+ buffers/cache: 3407 60799
Swap: 18449 0 18449
[Expert@fwoc2:3]# netstat -ni
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
lo3 16436 0 3528958 0 0 0 3528958 0 0 0 LRU
wrp192 1500 0 9080691 0 0 0 237149 0 0 0 BMRU
wrp193 1500 0 826888 0 0 0 1641614 0 0 0 BMRU
wrp194 1500 0 649853 0 0 0 2264704 0 0 0 BMRU
wrp195 1500 0 19642 0 0 0 568489 0 0 0 BMRU
wrp196 1500 0 47075 0 0 0 580195 0 0 0 BMRU
[Expert@fwoc2:3]# fwaccel stat
Accelerator Status : on
Accept Templates : enabled
Drop Templates : disabled
NAT Templates : disabled by user
Accelerator Features : Accounting, NAT, Cryptography, Routing,
HasClock, Templates, Synchronous, IdleDetection,
Sequencing, TcpStateDetect, AutoExpire,
DelayedNotif, TcpStateDetectV2, CPLS, McastRouting,
WireMode, DropTemplates, NatTemplates,
Streaming, MultiFW, AntiSpoofing, Nac,
ViolationStats, AsychronicNotif, ERDOS,
NAT64, GTPAcceleration, SCTPAcceleration,
McastRoutingV2
Cryptography Features : Tunnel, UDPEncapsulation, MD5, SHA1, NULL,
3DES, DES, CAST, CAST-40, AES-128, AES-256,
ESP, LinkSelection, DynamicVPN, NatTraversal,
EncRouting, AES-XCBC, SHA256
[Expert@fwoc2:3]# fw ctl multik stat
fw: CoreXL is disabled
[Expert@fwoc2:0]# fw ctl affinity -l -r
CPU 0: Mgmt Sync
CPU 1: eth3-01 eth3-02
CPU 2:
CPU 3:
CPU 4:
CPU 5:
CPU 6:
CPU 7:
CPU 8:
CPU 9:
CPU 10:
CPU 11:
CPU 12:
CPU 13:
CPU 14:
CPU 15:
CPU 16:
CPU 17:
CPU 18:
CPU 19:
All:
The medium path is not available without CoreXL. Thus traffic is forwarded to the F2F path, because CoreXL is deactivated.
My recommendations:
- First step enable CoreXL on a 20 core system.
- Second step optimize your rules for accept templates.
- Afterwards eneble drop and nat templates
- Optimize affinity on VSX
- Update your firewall to R80.10+ for VPN multicore support
Some more information to your questions:
Accept Template - Feature that accelerates the speed, at which a connection is established by matching a new connection to a set of attributes. When a new connection matches the Accept Template, subsequent connections are established without performing a rule match and therefore are accelerated. Accept Templates are generated from active connections according to policy rules. Currently, Accept Template acceleration is performed only on connections with the same destination port (using wildcards for source ports).
Accept Tamplate is enabled by default if SecureXL is used.
Throughput Acceleration - The first packets of a new TCP connection require more processing when processed by the firewall module. If the connection is eligible for acceleration, after minimal security processing the packet is offloaded to the SecureXL device associated with the proper egress interface. Subsequent packets of the connection can be processed on the accelerated path and directly sent from the inbound to the outbound interface via the SecureXL device.
Connection Rate Acceleration SecureXL also improves the rate of new connections (connections per second) and the connection setup/teardown rate (sessions per second). To accelerate the rate of new connections, connections that do not match a specified 5 tuple are still processed by SecureXL. For example, if the source port is masked and only the other 4 tuple attributes require a match. When a connection is processed on the accelerated path, SecureXL creates a template of that connection that does not include the source port tuple. A new connection that matches the other 4 tuples is processed on the accelerated path because it matches the template. The firewall module does not inspect the new connection, increasing firewall connection rates.
Can we see the output of: enabled_blades
Also, do you know why CoreXL is disabled on a Gateway with 20 cores?
The medium path is not available without CoreXL. Thus traffic is forwarded to the F2F path, because CoreXL is deactivated.
My recommendations:
- First step enable CoreXL on a 20 core system.
- Second step optimize your rules for accept templates.
- Afterwards eneble drop and nat templates
- Optimize affinity on VSX
- Update your firewall to R80.10+ for VPN multicore support
Some more information to your questions:
Accept Template - Feature that accelerates the speed, at which a connection is established by matching a new connection to a set of attributes. When a new connection matches the Accept Template, subsequent connections are established without performing a rule match and therefore are accelerated. Accept Templates are generated from active connections according to policy rules. Currently, Accept Template acceleration is performed only on connections with the same destination port (using wildcards for source ports).
Accept Tamplate is enabled by default if SecureXL is used.
Throughput Acceleration - The first packets of a new TCP connection require more processing when processed by the firewall module. If the connection is eligible for acceleration, after minimal security processing the packet is offloaded to the SecureXL device associated with the proper egress interface. Subsequent packets of the connection can be processed on the accelerated path and directly sent from the inbound to the outbound interface via the SecureXL device.
Connection Rate Acceleration SecureXL also improves the rate of new connections (connections per second) and the connection setup/teardown rate (sessions per second). To accelerate the rate of new connections, connections that do not match a specified 5 tuple are still processed by SecureXL. For example, if the source port is masked and only the other 4 tuple attributes require a match. When a connection is processed on the accelerated path, SecureXL creates a template of that connection that does not include the source port tuple. A new connection that matches the other 4 tuples is processed on the accelerated path because it matches the template. The firewall module does not inspect the new connection, increasing firewall connection rates.
Has nothing to do with your problem, but you can also enable drop and nat templates.
Drop Template - Feature that accelerates the speed, at which a connection is dropped by matching a new connection to a set of attributes. When a new connection matches the Drop Template, subsequent connections are dropped without performing a rule match and therefore are accelerated. Currently, Drop Template acceleration is performed only on connections with the same destination port (does not use wildcards for source ports).
Drop Template is disabled by default if SecureXL is used. It can be activated via smart Dashboard and does not require a reboot of the firewall.
NAT Templates - Using SecureXL Templates for NAT traffic is critical to achieve high session rate for NAT. SecureXL Templates are supported for Static NAT and Hide NAT using the existing SecureXL Templates mechanism. Normally the first packet would use the F2F path. However, if SecureXL is used, the first packet will not be forwarded to the F2F path if Accept Tamplate and NAT Template match. Enabling or disabling of NAT Templates requires a firewall reboot.
More you can found here in my articles:
R80.x Security Gateway Architecture (Logical Packet Flow)
R80.x Security Gateway Architecture (Content Inspection)
Or in this Check Point SK's:
SecureXL Mechanism
SecureKnowledge: SecureXL SecureKnowledge: NAT Templates
SecureKnowledge: VPN Core
SecureKnowledge: CoreXL
SecureKnowledge: CoreXL Dynamic Dispatcher in R77.30 / R80.10 and above
SecureKnowledge: Best Practices - Security Gateway Performance
If you want to update you can use these documents:
Performance Tuning R80.10 Administratio Guide
Performance Tuning R80.20 Administration Guide
David,
your shown utilization is realy poor. Maybe all of your traffic can‘t be accelerated. Have a look at SecureXL Mechanism chapter (1) Acceleration of packets . There is a good description which traffic isn‘t accelerated.
And too I recommend to enable CoreXL on a 20 core system with VSX. At the moment you don‘t need the cores but later with more traffic I‘m sure you need 😉
best regards
Wolfgang Becher
I'll be honest... I don't think I've seen a Check Point deployment where CoreXL would be off but SecureXL on. I think the best place to start would be to get CoreXL fired up and set correctly. The default configuration for a 20-core Gateway would be 2 SND's and 18 FWK's. It seems to me the first step is to analyzing performance would be to get this enabled.
Can you also run fwaccel stats -p to display the F2F Packets / SecureXL violations?
I also missed that this was VSX in your OP. How many VS's run on this GW or cluster?
It looks like the SecureXL stats you provided were from vs3. Have you looked at those performance numbers for each VS on the system? Are you seeing mostly F2F on everything?
I am running two active VSs and 2 VSs in standby. Here is the output for the other active VS:
[Expert@fwoc2:4]# fwaccel stats -s
Accelerated conns/Total conns : 215/267 (80%)
Accelerated pkts/Total pkts : 342488/546064 (62%)
F2Fed pkts/Total pkts : 196019/546064 (35%)
PXL pkts/Total pkts : 7557/546064 (1%)
QXL pkts/Total pkts : 0/546064 (0%)
[Expert@fwoc2:4]# vsenv 3
Context is set to Virtual Device fwoc2_atm-branch (ID 3).
Ok, so this looks like it is really just the one VS that is affected. This one has a much lower rate of F2F connections!
From sk98722 This is the list of violation counters and their descriptions:
It looks like TCP conn is F2Fed has the highest number of violations. This would indicate that the Firewall is explicitly determining the traffic doesn't qualify for acceleration.
Maybe as a next step, use fwaccel conns command and look for connections marked with an "F" as these are the connections being sent to F2F. See if there's any pattern in terms of the type of traffic. In sk98348, the following debug is also given to log reasons for F2F connections. If you go this route, it would only apply to new connections.
[Expert@HostName]# fw ctl debug 0 [Expert@HostName]# fwaccel dbg resetall [Expert@HostName]# sim dbg resetall [Expert@HostName]# fw ctl debug -buf 32000 [Expert@HostName]# fwaccel dbg + offload [Expert@HostName]# sim dbg + f2f [Expert@HostName]# fwaccel dbg list [Expert@HostName]# sim dbg list [Expert@HostName]# fw ctl kdebug -T -f > /var/log/debug.txt
In chapter 1 what exactly is meant by "packets that match a service that uses a Resource"?
Resources are legacy objects used to integrate third-party servers with a Check Point Firewall, such as URL Filtering (Websense) or Anti-Virus (Trend Micro). Traffic matching these resource objects must always go F2F:
Actually it is quite simple, the Medium Path (PXL) where traffic tends to congregate on most firewalls is not available unless CoreXL is enabled. So any traffic that cannot be fully handled in SXL is going straight to F2F because CoreXL is disabled. Get CoreXL enabled (unless you are using Traditional Mode VPNs or route-based VPNs on your R77.30 gateway) and post the statistics again, hopefully most of what is now in F2F will be PXL which is just fine.
I also hate to be "that guy" but it is probably worth pointing out that in R77.30, individual VS's only run in 32-bit mode; despite the GAIA Operating System itself being 64-bit. I'm assuming this box must be pretty beefy if it has 20-cores. You would definitely get some benefits by upgrading to R80.20.
When you do upgrade to R80.20, you have to manually set the VS's to run in 64-bit mode:
[hostname@expert:0]# vs_bits [-stat | 32 | 64 ]
Be aware it does issue a cpstop and cpstart on the vsx gateway.
There were also huge improvements made to SecureXL. Most things can be accelerated & templated now and the list of exceptions shrinks dramatically.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY