Editing Ip Rule Set Entries; Ip Rule Set Folders - D-Link NetDefend DFL-210 User Manual

3.5.4. Editing IP rule set Entries

NAT
SAT
Drop
Reject
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.
3.5.4. Editing IP rule set Entries
After adding various rules to the rule set editing any line can be achieved in the Web-UI by right
clicking on that line.
A context menu will appear with the following options:
Edit
Delete
Disable/Enable
Move options

3.5.5. IP Rule Set Folders

This functions like an Allow rule, but with dynamic address translation (NAT) enabled
(see Section 7.2, "NAT" in Chapter 7, Address Translation for a detailed description).
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
Section 7.4, "SAT" in Chapter 7, Address Translation for a detailed description).
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.
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.
This allows the contents of the rule to be changed.
This will remove the rule permanently from the rule set.
This allows the rule to be disabled but left in the rule set. While disabled the
rule set line will not affect traffic flow and will appear grayed out in the user
interface. It can be re-enabled at any time.
The last section of the context menu allows the rule to be moved to a
different position in the rule set and therefore have a different precedence
113
Chapter 3. Fundamentals