User`s guide

481
The following two rules are therefore equivalent:
pass in break end on ppp 0 proto icmp from any to 10.1.2.0/24 icmp-type 0
pass in break end on ppp 0 proto icmp from any to 10.1.2.0/24 icmp-type echorep
Both of these rules allow echo replies to come in from interface ppp 0 if they are addressed
to our example local network address (10.1.2.*).
In addition to having a type, ICMP packets also include an ICMP code field. The filter syntax
allows for the specification of an optional code field after the ICMP type. When specified the
code field must also match. The ICMP code field is specified with a decimal number.
For example, suppose we wish to allow only echo replies and ICMP unreachable type ICMP
packets from interface PPP 0. Then the rules would look something like this:
pass in break end on ppp 0 proto icmp from any to 10.1.2.0/24 icmp-type echorep code 0
pass in break end on ppp 0 proto icmp from any to 10.1.2.0/24 icmp-type unreach code 0
block in break end on ppp 0 proto icmp
The first two rules in this set allow in the ICMP packets that we are willing to permit and the
third rule denies all other ICMP packets in from this interface. Now if we ever expect to see
echo replies in on
ppp 0 we should allow echo requests out on that interface too. To do that
we would have the rule:
pass out break end on ppp 0 proto icmp icmp-type echo
Stateful Inspection
The Digi routing code stack contains a sophisticated scripted “Stateful Firewall” and “Route
Inspection” engine. Stateful inspection is a powerful tool that allows the unit to keep track
of a TCP/UDP or ICMP session and match packets based on the state of the connection on
which they are being carried. In addition to providing sophisticated Firewall functionality the
SF/RI engine also provides a number of facilities for tracking the “health” of routes, marking
“dead” routes as being Out Of Service (OOS) and creating rules for the automatic status
checking of routes previously marked as OOS (for use in multilevel backup/restore
scenarios).
The firewall may be used to place interface into an OOS state and also control how the
interfaces return to service. When an interface goes OOS, all routes configured to use that
interface will have their route metric set to 16 (the maximum value), meaning that some
other route with a lower metric will be selected.
When a firewall stateful inspection rule expires, a decision is made as to whether the traffic
being allowed to pass by this rule completed successfully or not. For example, if the stateful
rule monitors SYN and FIN packets in both directions for a TCP socket then that rule will
expire successfully. However, if SYNs are seen to pass in one direction but no SYNs pass in
the other direction, the stateful rule will expire and the unit will tag this as a failure.
The following conditions tag a stateful rule as a failure:
• packets have only passed in one direction
• 10 packets have passed in one direction with no return packets (for TCP the packets must
also be re-transmits) All of these features depend upon the stateful inspection capabilities of
the Firewall engine which are explained below.
The
[inspect] field takes the following format:
inspect = [“inspect-state” {“oos” {interface-name¦logical-name} secs {t=secs}
{c=count} {d=count}} {r=“ping”¦“tcp”{,secs{secs}}} {rd=x} {dt=secs}{stat}]