netdev - Re: TUN interfaces loopback

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1448834174.3668.27.camel@mindbit.ro>
Date:	Sun, 29 Nov 2015 23:56:14 +0200
From:	Radu Rendec <radu.rendec@...dbit.ro>
To:	Lorenzo Colitti <lorenzo@...gle.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: TUN interfaces loopback

On Sun, 2015-11-29 at 17:40 +0900, Lorenzo Colitti wrote:
> On Thu, Nov 26, 2015 at 1:58 AM, Radu Rendec <radu.rendec@...dbit.ro> wrote:
> > I tracked down the problem to ip_route_input_slow() in net/ipv4/route.c
> > [...]
> > The next problem is that packets are seen as "martians" and dropped,
> > most probably because of __fib_validate_source() failing due to the
> > fact that the input interface is not the expected one.
> 
> Have you tried setting this?
> 
> accept_local - BOOLEAN
>         Accept packets with local source addresses. In combination with
>         suitable routing, this can be used to direct packets between two
>         local interfaces over the wire and have them accepted properly.
>         default FALSE

I have tried it, but with no luck. I also tried with rp_filter=0, which
seems to be even more permissive than accept_local.

However, after reading the code more carefully, I finally figured it
out. It turns out that it's enough to have different (and correct)
routes for the outgoing and incoming routing decisions.

So in the following configuration:
tun0 [192.168.1.1 point-to-point 192.168.1.2]
^
|
v
tun1 [192.168.1.2 point-to-point 192.168.1.1]

it's enough to do the following:

 * Remove the automatically added routes from the "local" table.
 * Add two rules (one for each tun interface) *matching the input
   interface* and directing to a custom routing table (i.e. "ip rule
   add iif tunX lookup Y").
 * Add *local* routes for each tun interface to the custom routing
   table.
The trick here is that iif is set to 0 during the outgoing route
lookup, so the outgoing routing decision will not "see" the local
routes in the custom table. It will see the implicitly added routes in
the "main" table (these will route packets through the tun interfaces).

When the packet pops out of the opposite tun interface, the incoming
routing decision has iif set properly and will match the *local* routes
in the custom table. It is essential to match a local route at this
point, or else the packet will not be processed locally (as a packet
addressed to "this host").

With routing configured this way, not only that the martians problem
went away, but it works even with rp_filter=1 and accept_local=0.

--
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