On Wed, May 11, 2011 at 4:03 AM, Ed W <li...@wildgooses.com> wrote: > On 11/05/2011 01:32, richardvo...@gmail.com wrote: >>> Note that it's the nf_mark we will be setting. But: >>> get/setsockopt(fd, SOL_SOCKET, SO_MARK, ...) >> That allows you to set a mark for your outgoing packets, and find out >> what mark is in effect on outgoing packets. >> >> There's still a large piece of the puzzle missing, namely finding out >> what mark is carried by incoming requests, since this determines that >> mark that goes on the forwarded query (when it cannot be answered from >> cache). > > > This is where "conntrack" comes in. Please have a look back at my > previous email where I try and show the interaction between iptables and > conntrack?
[snip] You've explained all that several times, and it's nothing not already familiar to iptables users. But those marks are usually read by an iptables kernel module. How does dnsmasq, which uses the Berkeley sockets API (and some OS-specific extensions and ioctls) get the mark information for datagrams it receives? Or are you proposing that dnsmasq use iptables to receive request datagrams instead of the mostly portable socket functions? You did mention that squid is capable of this, although on TCP stream sockets instead of UDP datagram sockets. There's quite a bit of discussion here: http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/34286 I'm just afraid that the CAP_NET_ADMIN (or root) requirement and changing the way packets are received might be more than Simon is willing to pursue.
