ifconfig tun interface support is incomplete

[dovsienko]

> ifconfig tun/0
tun/0	Hardware type: unknown, Address: none
	inet addr: xxx.xxx.xxx.xxx, Mask: 255.255.255.255
	MTU: 1500, Metric: 0, up link
	Receive: 47065 packets, 0 errors, 3952992 bytes, 0 mcasts, 0 dropped
	Transmit: 46995 packets, 0 errors, 3947580 bytes, 0 mcasts, 0 dropped
	Collisions: 0

One cosmetic issue here is "hardware type" (it could say something such as "L3 tunnel"). SIOCGIFADDR returns IFT_TUNNEL for this interface.

Another issue is that L3 tunnels don't have hardware addresses (arguably, outer addresses are the closest equivalent, but in this case both outer addresses ought to be printed as such, similarly to how Linux "ip tunnel" does).

Another issue is that there seems to be nowhere to denote the remote inner address. The tunnel local inner address can be /32 (as is in this case) or a shorter mask (which would be the case in non-broadcast multiple access VPNs), but it can also have a remote inner address. Because ifconfig does not currently support such a "point-to-point peer" address, in OpenVPN it takes to use the following options to bring the tunnel up much enough:

--ifconfig xxx.xxx.xxx.xxx 255.255.255.255 --ifconfig-nowarn

And then the peer address must be configured manually with:

route add tun/0 xxx.xxx.xxx.yyy host

Only after that ping works between the inner addresses. It would be more convenient to run a single command and to have the host route installed and the remote inner address usable as a route gateway:

ifconfig tun/0 xxx.xxx.xxx.xxx 255.255.255.255 peer xxx.xxx.xxx.yyy
route add xxx.nnn.0.0 prefixlen 16 gw xxx.xxx.xxx.yyy

[dovsienko]

To clarify the third point, ifconfig does accept such a command, but afterwards it does not print the peer address and the peer address does not produce a host route, so it looks no-op:

~> ifconfig tun/1 10.100.0.1 prefixlen 24 peer 10.100.0.200
~> ifconfig tun/1
tun/1	Hardware type: unknown, Address: none
	inet addr: 10.100.0.1, Mask: 255.255.255.0
	MTU: 1514, Metric: 0, up promiscuous link
	Receive: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
	Transmit: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
	Collisions: 0

~> route list | grep -F 10.100.0.
     10.100.0.1               -               - --HL-- tun/1
     10.100.0.0   255.255.255.0               - ------ tun/1

[marcoapc]

Missing implementations in the tun driver:

​https://github.com/Swangeon/HCC#whats-left-to-do

https://dev.haiku-os.org/ticket/18673

[waddlesplash]

All those things have since been taken care of. This ticket is about something else.

[dovsienko]

The "unknown hardware type" point is cosmetic. The "point-to-point inner address does not appear in ifconfig output" is a defect: what ifconfig allows to configure it should also display so the user can verify the result. The "missing host route" point is a defect.

Ideally the final implementation should work with OpenVPN (even a patched one) without manual tunnel interface configuration, such that tunnel interfaces have correct point-to-point addresses and the host routes are automatically present. Which in turn would simplify network routes that use the point-to-point address as the gateway.