netdev - [RFC]: not possible to do policy routing for next hop on tunnels.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1283343685.14066.24.camel@seasc7941.dyn.rnd.as.sw.ericsson.se>
Date:	Wed, 01 Sep 2010 14:21:25 +0200
From:	Anders Franzen <Anders.Franzen@...csson.com>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: [RFC]: not possible to do policy routing for next hop on tunnels.

If I have multiple routing choices to reach a tunnel end point,
I would like to mark different flows with iptables, after the
postrouting of the primary route look up, this would put an fwmark on
the skb. The route would in my case resolve to an ip6_tunnel.

In the tunnel a secondary route lookup is done to select next hop for
the tunnel end point.

I would like to apply policy routing to the secondary lookup. 

This will not work, for two reasons:

1. None of the tunnels (ipip, gre, ip6_tunnel) I looked at regards the
fwmark at the skb, when performing the route lookup.

2. ip6_tunnel is keeping a local dst cache, so it will never reroute as
long as the current cache is valid.

I wonder if there is a reason for not giving the fwmark at the tunnel
route for tunnels in general?

And the local dst cache for ip6_tunnel, is it needed, is not the routing
subsystem keeping some form of internal cache (ip route ls cache).

Best Regards
  /Anders

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html