[Firewall] Netfilter marks and policy routing blues

Gustin Johnson gustin at meganerd.ca
Wed Feb 11 22:39:10 CET 2015

Are you using the native rsync network protocol or leveraging ssh (which is
what most of us do these days)?  If the later then that layer 7 filter will
have no idea that the ssh session contains an rsync stream, and at best you
could try to perform a statistical analysis of that ssh session to
determine the presence of a particular tunneled protocol (hint packet sizes
might be different between an a tunneled rsync session and an interactive

If you specify the rsync destination in your ssh config file, you can set
the IPQoS option which will manipulate the DSCP field for connections to
that server.  You can then filter or shape based on this header, even on a
different machine.

You could also use iptables mangle in your rsync script to set the DSCP TCP
flag by matching the PID of the ssh session used by rsync.  Kind of ugly
but this also works.  This is not the same as marking since a mark does not
persist out on the wire (IIRC it is only valid in the mangle table).

Personally I do not bother with layer 7 filtering.  Pretty much everything
will be encrypted soon and almost everything I care about already is.  This
makes so-called "deep packet inspection" of limited utility for me.
Looking at source and destination ports, traffic patterns, other header
values is *not* deep packet inspection.
YMMV, but I would manage your expectations with respect to layer 7
filtering and shaping techniques.


On Wed, Feb 11, 2015 at 12:51 PM, Lists <lists at aewne.net> wrote:

> Hello everyone,
> Does anyone here have any experience with having netfilter mark packets to
> determine which route they should take?
> A while back I was trying my hand at throwing together a script to use
> with OpenVPN in order to mark some packets that should be routed over the
> VPN interface of my gateway instead of the internet facing one. This was
> done with a combination of marking traffic to certain hosts as well as
> using some xtables modules to do some layer 7 filtering. Some other
> pressing matters came up and I didn't have time to continue work on it
> until now. It's somewhat working, but I've run into an issue I can't quite
> wrap my head around.
> Below are the relevant portions of it.
> sysctl -w net.ipv4.conf.${VPN_IF}.rp_filter=2
> First, restore any and all marks on the connection:
> iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
> The script loops a bunch of times to resolve DNS A records to to IPs, and
> then applies a rule like this:
> iptables -t mangle -A PREROUTING -d ${HOST} -j MARK --set-mark ${MARK}
> Then as a test I've been experimenting with the ndpi-netfilter package to
> do application layer filtering like:
> iptables -t mangle -A PREROUTING -m ndpi --rsync -j MARK --set-mark ${MARK}
> Then connmarking the whole connection:
> iptables -t mangle -A PREROUTING -m mark --mark ${MARK} -j CONNMARK
> --save-mark
> Set up the routing table:
> ip route add default via ${VPN_GW} dev ${VPN_IF} table vpn
> ip route add ${LAN_SUBNET} via ${LAN_GATEWAY} dev ${LAN_IF} table vpn
> ip rule add fwmark ${MARK} table vpn
> ip route flush cache
> For individual hosts, this piece of iptables magic works, but the layer 7
> filtering is where it gets tricky. The packets are marked, seeing as the
> counters in the ruleset increase whenever I initiate an rsync process on
> another box on the LAN. However, regardless of the marking, the packets are
> not routed out on the VPN interface.
> Anyone have any ideas on what's going on here? What did I miss?
> For the record I am running a 3.17.7 kernel and Arno's Iptables Firewall
> Script v2.0.1e.
> Regards,
> Alex
> _______________________________________________
> Firewall mailing list
> Firewall at rocky.eld.leidenuniv.nl
> http://rocky.eld.leidenuniv.nl/mailman/listinfo/firewall
> Arno's (Linux IPTABLES Firewall) Homepage:
> http://rocky.eld.leidenuniv.nl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rocky.eld.leidenuniv.nl/pipermail/firewall/attachments/20150211/9a7a2f24/attachment.html>

More information about the Firewall mailing list