How do new connections get established through a Security Gateway with SecureXL enabled?
A.
New connections are always inspected by the firewall and if they are accepted, the subsequent
packets of the same connection will be passed through SecureXL
B.
New connection packets never reach the SecureXL module.
C.
The new connection will be first inspected by SecureXL and if it does not match the drop table
of SecureXL, then it will be passed to the firewall module for a rule match.
D.
If the connection matches a connection or drop template in SecureXL, it will either be
established or dropped without performing a rule match, else it will be passed to the firewall
module for a rule match.
A
“New connections are always inspected by the firewall and if they are accepted, the subsequent packets of the same connection will be passed through SecureXL”
from student manual:
Packets attempting to establish a new TCP connection, or a comparable UDP connection table entry in the firewall, are handled in the “slowpath”.
Once the first packet is seen by the firewall and suitable connections/flows information is off-loaded to an appliance OS, for example, further packets are handled at the OS’s interrupt-Ievel code.
0
0
A.
All the new connection creation/old connection deletion is handled
in the slowpath. However, these new connection setup packets matching 4 out of
5 tuples avoid a round trip to the firewall application, and avoiding the computing
overhead. Security is not impacted because the as conlinues to track the state of
the new connection using stateful inspection.
0
0
I think D is true.
On sk32578 you can find the following statement:
“When SecureXL is enabled, all traffic should be accelerated, except traffic that matches the following conditions:
The first packets of any new TCP session, unless a “template” exists.
…”
0
0
I am more inclined towards D as well.
0
0
I think answer D is right
0
0
It is A. see sk32578
Read carefully the content of the question and the doc.
When SecureXL is enabled, all packets should be accelerated, except packets that match the following conditions:
The first packets of any new TCP session, unless a “template” exists.
The first packet of any new UDP session.
All packets that match a service that uses a Resource.
Certain packets that match a service that is inspected by a SmartDefense/IPS or Web Intelligence feature. For example, traffic on which SSH protections are activated is not accelerated.
All packets that are supposed to be dropped or rejected, according to the rule base (unless Drop Templates are enabled – refer to sk90861).
…
> here is “supposed to be dropped or rejected”
The very first packets of the first connection on the same service will be forwarded to the Security Gateway’s kernel, which will then create a “template” of the connection and notify the SecureXL device. Any subsequent TCP connections established on the same service (where only the source port is different) will already be accelerated (as well as any other traffic, of course).
Second: how can be a template if it’s a new packet? It’s SecureXL who’s creating the template, not the user.
0
0
I think it’s A
Note that it is a NEW connection
If we loook at SK32578. Take note of ALL the conditions, most especially the “All packets that are supposed to be dropped or rejected, according to rule base”
That means the new packet goes through FIREWALL inspection first
0
0
But honestly, A and D is very confusing
0
0
If we look at a separate blog explaining SecureXL
Lookslike the answer is A
https://dreezman.wordpress.com/2012/12/11/securexl-how-it-works/
0
0
A. New connections are always inspected by the firewall and if they are accepted, the subsequent packets of the same connection will be passed through
SecureXL
0
0
A
I’ve never heard about “drop template”
0
0
+1
0
0
D ?
http://dl3.checkpoint.com/paid/4e/CP_Performance_Optimization_Guide.pdf?HashKey=1488640814_71c40686a45ad50e54fbda1e4f77d7de&xtn=.pdf
0
0