udprelay can give you the udp "plug" you need. So, that wouldn't be
a convincing argument for packet filtering per se.
But, a plug does have limitations ... we've written in code to help
the plug do round-robin for fail-over, TIS has the extended it to
pass the original IP address, etc, etc. But the main problem with
plug-gw that makes me wish to replace it (in some cases) is:
- the plug-gw cannot do a range of ports very easily.
I want to pass DCE's portmap-equiv (called epmapper) so I plug
the xxx port. I've restricted DCE to a range of ports (3000-4000)
and I need to place 1000 plug-gw's ???
OK, DCE is a bad example ... but port-ranges are a tough issue.
Performance still is an issue. At work we POUND a couple production
services. I fill up a high powered machine running plug-gw ? Makes no
sense when I can't justify that plug-gw is any more of a benefit than
a simple filtering rule on a filter device that costs 1/2 what my
plug-gw servers (n+1 for fail-over/redundancy) cost.
Actually, I'd like to have a packet filter that would let me
do some "scripting" of what the data payload should look like :-)
But then, in my work environ ... I'm sure we'd be pressured into
just putting the filter rules in and later (read: never) get around
to tightening it up with data description. Oh well, might as well
just plug-gw it.
Peter da Silva wrote:
> > But, having said that ... I am starting to see where having a hybrid
> > firewall would give you more flexibility. I'm a long time "app level
> > firewalls, protected by packet filters for increased protection/layering"
> > ... but some businesses need more flexibility and are willing to accept
> > the risk. Its nice to have a firewall that can meet that need.
> For TCP protocols what does a packet filter let you do that you can't do
> with a plug gateway? I can see why UDP protocols would be hard to plug, but
> they're also things I'd be less happy about letting through in the first
> place... and certainly an application-specific proxy would be best for UDP.
> Yes, plugs are relatively stupid. They *do* take care of all the IP level
> attacks (source routing, IP options, fragmentation, and so on) that can slip
> through a packet filter, whether or not the people who wrote the filter know
> about them or not.