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

Date:	Wed, 25 Nov 2015 18:58:13 +0200
From:	Radu Rendec <radu.rendec@...dbit.ro>
To:	netdev@...r.kernel.org
Subject: TUN interfaces loopback

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.

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!

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