Why interface (tap) configuration is delayed by route-delay?

[Konstantin Kabassanov]

Hello,

Strangely, tap interface remains not operational until route-delay expires. It is a little bit strange, because, this way, neither the dhcp request is sent, nor the link-local ipv6 address is assigned (nor the connected v6 net).

In addition, when the timer is fired,  "2000::/4", "3000::/4" routes are not set, because gateway on the remote side of the vpn tunnel is still unreachable (probably related to the delayed interface setup).

Any idea?

PS: This is a setup where no "ifconfig options" are used in its vpn configuration.

[Tunnelblick Developer]

This is apparently the way that OpenVPN does things. For more info, please consult OpenVPN documentation/support.

[Konstantin Kabassanov]

Well, 

client.up.tunnelblick.sh script seems to "ipconfig set tap0 DHCP" and "ipconfig set $1 AUTOMATIC-V6".  So I copied the same thing in --up script and it works better.

But, one must be aware that recent openvpn versions  (ie 2.6.14) filter router options from dhcp offer/ack packet sent to the client. Thus, client.up.tunnelblick.sh could never get it.

The ipv6 part of the problem is that BSD like systems need to suffix the ipv6 link-local gateway address by the interface name "%tap0". Something exists in openvpn code, but is not enough. As you said, it is an openvpn problem and I must continue to look inside how to fill correctly r6->iface before calling add_route_ipv6.