D-Link DFL-260 Product Manual - Page 120
Editing IP rule set Entries, Actions, Allow, NAT, Address Translation
UPC - 790069296802
View all D-Link DFL-260 manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 120 highlights
3.5.4. Editing IP rule set Entries Chapter 3. Fundamentals • Destination Network • Service When an IP rule is triggered by a match then one of the following Actions can occur: Allow The packet is allowed to pass. As the rule is applied to only the opening of a connection, an entry in the "state table" is made to record that a connection is open. The remaining packets related to this connection will pass through the NetDefendOS "stateful engine". FwdFast Let the packet pass through the NetDefend Firewall without setting up a state for it in the state table. This means that the stateful inspection process is bypassed and is therefore less secure than Allow or NAT rules. Packet processing time is also slower than Allow rules since every packet is checked against the entire rule set. NAT 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). SAT 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). 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. 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 rule can be achieved in the Web Interface by right clicking on that line. 120