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]
Message-Id: <1448967735.3317024.454539225.4F16ACA3@webmail.messagingengine.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ