Disadvantages of Packet Filtering

You must specify the destination IP address and the protocol type for each filtered connection. You can filter for a specific host or network ID, or you can block all traffic of a particular type. If you want to perform any level of granular control over a group of sites you wish to block, it can become a very complex and time-consuming affair. It is better to use Proxy Server if you require this type of functionality.
Routing and Remote Access IP filters provide similar security to firewall filters, which can protect your network from incoming packets. Again, the level of complexity required in such a filtering scheme might be overwhelming to an inexperienced administrator or a SOHO (small office/home office) user.
Packet filtering firewalls are part of a router which work at the network level of the OSI model or the IP layer of TCP/IP. In this firewall every packet is compared to a set of criteria prior to forwarding it. The firewall can drop the packet; forward the packet to originator depending on the packet and the criteria. The advantage of packet filter firewall is "low cost and low impact on network performance".

Despite the widespread availability of packet filtering in various hardware and software packages, packet filtering is still not a perfect tool. The packet filtering capabilities of many of these products share, to a greater or lesser degree, common limitations:

1. The packet filtering rules tend to be hard to configure. Although there is a range of difficulty, it mostly runs from slightly mind-twisting to brain-numbingly impossible.
2. Once configured, the packet filtering rules tend to be hard to test.
3. The packet filtering capabilities of many of the products are incomplete, making implementation of certain types of highly desirable filters difficult or impossible.
4. Like anything else, packet filtering packages may have bugs in them; these bugs are more likely than proxying bugs to result in security problems. Usually, a proxy that fails simply stops passing data, while a failed packet filtering implementation may allow packets it should have denied.

Even with perfect packet filtering implementations, you will find that some protocols just are not well suited to security via packet filtering, for reasons we'll discuss later in this book. Such protocols include the Berkeley "r" commands (rcp, rlogin, rdist, rsh, etc.) and RPC-based protocols such as NFS and NIS/YP. (The problems of using packet filtering to deal with these protocols are discussed in Configuring Internet Services.)

The information that a packet filtering router has available to it does not allow you to specify some rules you might like to have. For example, packets say what host they come from, but generally not what user. Therefore, you cannot enforce restrictions on particular users. Similarly, packets say what port they are going to, but not what application; when you enforce restrictions on higher-level protocols, you do it by port number, hoping that nothing else is running on the port assigned to that protocol. Malicious insiders can easily subvert this kind of control.