Packet filtering routers suffer from a number of weaknesses, as described in [Chap92]. Packet filtering rules are complex to specify and usually no testing facility exists for verifying the correctness of the rules (other than by exhaustive testing by hand). Some routers do not provide any logging capability, so that if a router's rules still let dangerous packets through, the packets may not be detected until a break-in has occurred.
Often times, exceptions to rules need to be made to allow certain types of access that normally would be blocked. But, exceptions to packet filtering rules sometimes can make the filtering rules so complex as to be unmanageable. For example, it is relatively straightforward to specify a rule to block all inbound connections to port 23 (the TELNET server). If exceptions are made, i.e., if certain site systems need to accept TELNET connections directly, then a rule for each system must be added. Sometimes the addition of certain rules may complicate the entire filtering scheme. As noted previously, testing a complex set of rules for correctness may be so difficult as to be impractical.
Some packet filtering routers do not filter on the TCP/UDP source port,
which can make the filtering ruleset more complex and can open up ``holes'' in
the filtering scheme.
[Chap92] describes such a problem with sites that wish to allow
inbound and outbound SMTP connections.
As described in section 
, TCP connections include a source
and destination port.
In the case of a system initiating an SMTP connection to a server, the
source port would be a randomly chosen port at or above 1024 and the
destination port would be 25, the port that the SMTP server ``listens''
at.
The server would return packets with source port of 25 and destination
port equal to the randomly-chosen port at the client.
If a site permits both inbound and outbound SMTP connections, the router
must allow destination ports and source ports > 1023 in both directions.
If the router can filter on source port, it can block all packets
coming into the site that have a destination port > 1023 and a source
port other than 25.
Without the ability to filter on source port, the router must permit
connections that use source and destination ports > 1024.
Users could conceivably run servers at ports > 1023 and thus get ``around''
the filtering policy (i.e., a site system's telnet server that normally
listens at port 23 could be told to listen at port 9876 instead; users
on the Internet could then telnet to this server even if the router blocks
destination port 23).
Another problem is that a number of RPC (Remote Procedure Call) services are very difficult to filter effectively because the associated servers listen at ports that are assigned randomly at system startup. A service known as portmapper maps initial calls to RPC services to the assigned service numbers, but there is no such equivalent for a packet filtering router. Since the router cannot be told which ports the services reside at, it isn't possible to block completely these services unless one blocks all UDP packets (RPC services mostly use UDP). Blocking all UDP would block potentially necessary services such as DNS. Thus, blocking RPC results in a dilemma.
Packet filtering routers with more than two interfaces sometimes do not have the capability to filter packets according to which interface the packets arrived at and which interface the packet is bound for. Filtering inbound and outbound packets simplifies the packet filtering rules and permits the router to more easily determine whether an IP address is valid or being spoofed. Routers without this capability offer more impediments to implementing filtering strategies.
Related to this, packet filtering routers can implement both of the design
policies discussed in section .
A ruleset that is less flexible, i.e., that does not filter on source port
or on inbound and outbound interfaces, reduces the ability of the
router to implement the second and more stringent policy, deny all services
except those expressly permitted, without having to curtail the types
of services permitted through the router.
For example, problematic services such as those that are RPC-based become
even more
difficult to filter with a less-flexible ruleset; no filtering on source
port forces one to permit connections between ports > 1023.
With a less-flexible ruleset, the router is less able to express a
stringent policy, and the first policy, permit all services except those
expressly permitted, is usually followed.
Readers are advised to consult [Chap92], which provides a concise overview of packet filtering and associated problems. While packet filtering is a vital and important tool, it is very important to understand the problems and how they can be addressed.