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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
