FreeBSD topo subnet self-route not via loopback interface?

[mandree]

Anton Sayetsky reported ​FreeBSD bug #194745 where apparently there is no loopback route added for the hosts' own interface, such that it gets routed through the tunnel. For details, please see the FreeBSD bug report.

[mandree]

possibly related to #55

[Gert Döring]

#55 should be fixed in 2.3.5 (and that was for extra routes via the tun, not the host itself).

I can reproduce the issue on a FreeBSD 10.0 box, and I think I know what's causing it:

tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500

options=80000<LINKSTATE>
inet 10.194.3.1 --> 10.194.3.1 netmask 0xffffff00

and when I ping 10.194.3.1, I can see packets go out on the tun2 if in tcpdump:

09:03:20.622004 IP 10.194.3.1 > 10.194.3.1: ICMP echo request, id 53559, seq 0, length 64
09:03:21.634864 IP 10.194.3.1 > 10.194.3.1: ICMP echo request, id 53559, seq 1, length 64

... which obviously get nowhere (the OpenVPN server process drops them, as it's not an address assigned to a client).

Now, I can see a notable difference in "netstat" between a tun interface in subnet mode and a tap interface in subnet mode:

10.194.3.0/24 10.194.3.1 UGS 0 11366 tun2
10.194.3.1 link#6 UH 0 9 tun2

10.194.4.0/24 link#7 U 0 21977 tap0
10.194.4.1 link#7 UHS 0 0 lo0

and I think the underlying issue is that FreeBSD doesn't really believe in the concept of a "netmask" on a tun interface - so the way we currently configure the tun, i.e. "ifconfig tun2 10.194.3.1 10.194.3.1 netmask 255.255.255.0 up", doesn't actually do what we expect it to do ("install a subnet route here, and our address is .3.1") but confuse the routing code so it won't recognize .3.1 as "myself".

Which, actually, brings back #55, as the fix there will provide us an IP address that can be used as "remote" for the ifconfig ("ifconfig tun2 10.194.3.1 10.194.3.2"), and doing so will make self-pinging the .3.1 address work. Yay.

Slight catch: for certain reasons this won't make 2.3.6, sorry. But I'll see that I can get this issue tested and fixed across all the BSDs, send a patch to the list, and hopefully get it into 2.3.7

[mandree]

Do we have anything that should see testing before a 2.3.7 release?

[Gert Döring]

dragging my feet on this, sorry - but 2.3.7 is not coming tomorrow, so I hope to have something "soonish"

[Gert Döring]

Create arbitrary but-in-self-subnet remote for point-to-point use

[Gert Döring]

So. Took me long enough, but attached you find a patch for git master (that should apply to 2.3.x as well, but I have not tested it) that works for me on FreeBSD 9.3/amd64 and FreeBSD 9.1/sparc64 - so it's endian-safe, even if it looks "endian-sloppy" :-)

It might not be pretty, but since the IPv4 code overloads "remote" and "netmask", and we only have a "netmask" here, we need to make up something - which, in the end, does not matter at all since we're adding a subnet route anyway, as long as it's "not us" and "in the same subnet".

Patch has also been sent to the list.

[Gert Döring]

So, any feedback? Can I put this into 2.3.7?

[Gert Döring]

Patch has been applied to the master and release/2.3 branch.

commit 60fd44e501f2002459a49c6c9bc64370ea26ca87 (master)
commit e1182281f41ccd6c5820a13dad4382841f4832e6 (release/2.3)

Author: Gert Doering
Date: Sun Apr 26 20:03:58 2015 +0200

Fix FreeBSD ifconfig for topology subnet tunnels.

Signed-off-by: Gert Doering <gert@…>

release v2.3.7 has been tagged in git, and will be formally released in the next days (tarballs, windows binaries, etc.)