This tells NetDefendOS to perform static address translation. A
SAT
rule always requires a
matching
Allow
,
NAT
or
FwdFast
IP rule further down the rule set (see
Chapter 7, Address Translation
for a detailed description).
•
Drop
This tells NetDefendOS to immediately discard the packet. This is an "impolite" version of
Reject
in that no reply is sent back to the sender. It is often preferable since it gives a potential
attacker no clues about what happened to their packets.
•
Reject
This acts like
Drop
but will return a
TCP RST
or
ICMP Unreachable
message, informing the
sending computer that the packet was dropped. This is a "polite" version of the
Drop
IP rule
action.
Reject
is useful where applications that send traffic wait for a timeout to occur before realizing
that the traffic was dropped. If an explicit reply is sent indicating that the traffic was dropped,
the application need not wait for the timeout.
Note: Some actions alter TCP sequence numbers
In some situations with certain types of network equipment, the TCP sequence number
needs to remain the same as data traffic traverses the firewall.
It is therefore important to know that only the
FwdFast
action guarantees that the TCP
sequence number is unaltered. Other IP rule actions, such as
Allow
and
NAT
change the
TCP sequence number as traffic flows through NetDefendOS.
Logging
When an
IP Rule
or
IP Policy
object is created the default is that logging is enabled. This means
that a log message is generated whenever either is triggered. This behavior can be altered by
disabling logging on the individual rule or policy object.
Bi-directional Connections
A common mistake when setting up IP Rules is to define two rules, one rule for traffic in one
direction and another rule for traffic coming back in the other direction. In fact nearly all IP Rules
types allow
bi-directional
traffic flow once the initial connection is set up. The Source Network
and Source Interface in the rule means the source of the initial connection request. If a
connection is permitted and then becomes established, traffic can flow in either direction over it.
The exception to this bi-directional flow is
FwdFast
rules. If the
FwdFast
action is used, the rule
will not allow traffic to flow from the destination back to the source. If bi-directional flow is
required then two
FwdFast
rules are needed, one for either direction. This is also the case if a
FwdFast
rule is used with a
SAT
rule.
Using Reject
In certain situations the
Reject
action is recommended instead of the
Drop
action because a
"polite" reply is required from NetDefendOS. An example of such a situation is when responding
to the IDENT user identification protocol. Some applications will pause for a timeout if
Drop
is
used and
Reject
can avoid such processing delays.
Chapter 3: Fundamentals
234
Summary of Contents for NetDefendOS
Page 30: ...Figure 1 3 Packet Flow Schematic Part III Chapter 1 NetDefendOS Overview 30 ...
Page 32: ...Chapter 1 NetDefendOS Overview 32 ...
Page 144: ...Chapter 2 Management and Maintenance 144 ...
Page 284: ...Chapter 3 Fundamentals 284 ...
Page 392: ...Chapter 4 Routing 392 ...
Page 419: ... Host 2001 DB8 1 MAC 00 90 12 13 14 15 5 Click OK Chapter 5 DHCP Services 419 ...
Page 420: ...Chapter 5 DHCP Services 420 ...
Page 573: ...Chapter 6 Security Mechanisms 573 ...
Page 607: ...Chapter 7 Address Translation 607 ...
Page 666: ...Chapter 8 User Authentication 666 ...
Page 775: ...Chapter 9 VPN 775 ...
Page 819: ...Chapter 10 Traffic Management 819 ...
Page 842: ...Chapter 11 High Availability 842 ...
Page 866: ...Default Enabled Chapter 13 Advanced Settings 866 ...
Page 879: ...Chapter 13 Advanced Settings 879 ...