Firewall

[Richard W.M. Jones]

On Tue, Dec 07, 2010 at 09:50:22AM +0000, Tim Waugh wrote:
> On Mon, 2010-12-06 at 21:50 +0000, Richard W.M. Jones wrote:
> > Still not seeing how /etc/iptables.d wouldn't work ...
> 
> Here is how:
> 
> When I ask CUPS for a list of network printers, it runs the backends
> in /usr/lib/cups/backend.  One of those is /usr/lib/cups/backend/snmp,
> which:
> 
> a) binds to a local unprivileged UDP port
> b) sends a broadcast SNMP request
> c) listens for (unicast) responses to that request
> 
> We don't hear any of those responses because they are not recognised as
> "related" by the kernel.  The iptables rules drop them.
> 
> If the CUPS snmp backend could say to "the firewall", "hey, please allow
> responses on this port I've got for the next few seconds" -- which can
> be controlled using PolicyKit -- then this network discovery would
> finally work.
> 
> There's no way to know the local UDP port in advance
> so /etc/iptables.d-like systems all fail here.

Does firewalld solve this?  Surely a solution to this is going to have
to live in a stateful extension to iptables in the kernel, or a fix to
the 'related' packets function?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top