[Contents] [Prev] [Next] [Index] [Report an Error]

How Firewall Filters Test a Packet’s Protocol

If you specify a port match condition or a match of the ICMP type or TCP flags field, there is no implied protocol match. If you use one of the following match conditions in a term, you should explicitly specify the protocol in the same term:

When examining match conditions, the policy framework software tests only the specified field itself. The software does not also test the IP header to determine that the packet is indeed an IP packet.

If you do not explicitly specify the protocol, when using the fields listed previously, design your filters carefully to ensure that they are performing the expected matches. If you specify a match of destination-port ssh, the policy framework software deterministically matches any packets that have a value of 22 in the 2-byte field that is 2 bytes beyond the end of the IP header, without ever checking the IP protocol field.

Example: Do Not Test Packet Protocol

The first term matches all packets except for TCP and UDP packets, so only TCP and UDP packets are evaluated by the third term (term test-a-port):

[edit]
firewall {
family inet {
filter test-filter {
term all-but-tcp-and-udp {
from {
protocol-except [tcp udp];
}
then accept;
}
term test-an-address {
from {
address 192.168/16;
}
then reject;
}
term test-a-port {
from {
destination-port [ssh dns];
}
then accept;
}
term dump-anything-else {
then reject;
}
}
}
}

[Contents] [Prev] [Next] [Index] [Report an Error]