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

Date:	Tue, 01 Dec 2015 12:02:15 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Radu Rendec <radu.rendec@...dbit.ro>, netdev@...r.kernel.org
Subject: Re: TUN interfaces loopback

Hello,

On Wed, Nov 25, 2015, at 17:58, Radu Rendec wrote:
> Disclaimer: I know this is a *development* list, but I feel the answer
> lies deep down in the ipv4 routing code, so it's more likely that I
> find help here.
> 
> That being said, I have two TUN interfaces that are "cross-connected"
> in user space (i.e. whatever is read on the socket corresponding to
> either interface is written to the socket of the other interface).
> 
> The problem: if I assign IPv4 addresses to both TUN interfaces, local
> traffic to either address flows through the loopback interface. Getting
> packets to be routed through the TUN interfaces is easy. The real
> challenge is to get packets to be accepted/processed as input packets
> when they pop out of the opposite TUN interface.

Why do you require them to be marked as "input" packets?

> I tracked down the problem to ip_route_input_slow() in net/ipv4/route.c
> 
> What I tried so far:
> 
> 1. Remove the implicit routes from the local table. This apparently
> causes packets to be silently dropped by ip_route_input_slow(), since
> it looks for a corresponding route and only delivers packets locally if
> a local route is found.
> 
> 2. Keep implicit routes in the local table, change the priority of the
> "lookup local" ip rule, mark *output* packets with iptables and add a
> higher priority rule to lookup the main table for marked packets.
> 
> By doing that, the main table is looked up on the egress path and
> packets are routed through the TUN interface. When packets pop out of
> the opposite TUN interface, they are no longer marked (because they are
> actually different packets), so ingress routing correctly looks up the
> local table.
> 
> 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.
> 
> This is where I stopped. Any idea or help would be highly appreciated.
> Please CC my private address (I am not subscribed to the list). Thanks
> in advance!

Have you tried ip route add local-ip-addr/32 dev tun0 and handle arp on
the outside interfaces with arp proxying or other means (routing
protocols)?

Thanks,
Hannes

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