Detect default route fails on smartos, leading openvpn to not define full routing table.

[baetheus]

GuestOS: SmartOS minimal-64 15.2.0 and SmartOS minimal-64 16.1.0
HostOS: SmartOS Live Image v0.147+ build: 20160527T033529Z

Openvpn build:
[root@transmission ~]# openvpn --version
OpenVPN 2.3.6 x86_64-sun-solaris2.11 [SSL (OpenSSL)] [LZO] [IPv6] built on Aug 30 2015
library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@…>
Compile time defines: enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=no enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_http_proxy=yes enable_iproute2=no enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=no with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no

Routing table: ​https://gist.github.com/anonymous/4259fd6dbf2b492b8a5805c1d3ba4f41
Openvpn config: ​https://gist.github.com/anonymous/543c6fc8b3aff6c4a98603058ede6ecd
Logs: ​https://gist.github.com/anonymous/00c3a70f3850e63c80371adadc50d9bb

The vpn provider is, as can be seen in the config and logs, Private Internet Access.

Steps to reproduce on a fresh install:

1. Install openvpn: # pkgin in openvpn
2. Copy config, certs, and auth to /opt/local/etc/openvpn/
3. Enable openvpn service: # svcadm enable -r openvpn
4. Reboot
5. Optional: access logs with: # tail -F $(svcs -L openvpn)

Temporary solution:

1. Manually add routes

route add default <tun1 internal address> 128.0.0.0
route add <vpn public address> <internal gateway> 255.255.255.255
route add 128.0.0.0 <tun1 internal address> 128.0.0.0

2. Check that traffic is forwarding properly

[root@test ~]# curl portquiz.net:666
Port 666 test successful!
Your IP: <vpn public address>

It seems, in my decidedly uninformed opinion, that a smartos ifdef in route.h or route.c could resolve the issue, if it hasn't already done so in 2.3.11. Anyway, thanks for looking into it!

[Gert Döring]

Please re-test with 2.3.11 - 2.3.6 is so old that I'm not going to bother installing a SmartOS system somewhere just to find out if something was fixed between 2.3.6 and 2.3.11.

What happens if you run "openvpn --show-gateway"? This nicely does the right thing for me on an OpenSolaris? 10 box, which isn't SmartOS, but "close".

(There is a commit in the release/2.3 branch that went into 2.3.10 which says "Default gateway can't be determined on illumos/Solaris platforms" - so, please try 2.3.11, it might just have the fix)

[Gert Döring]

PS: of course you want git master (2.4-to-be) anyway, because it can also properly detect the IPv6 gateway if present...

[Gert Döring]

closing this. It works on my OpenSolaris? system today, git log indicates the fix went into 2.3.10, so I'm only interested if it still happens in 2.3.11 (and then I need to see "openvpn --show-gateway").

Side rant: Tickets like this steal precious developer time. Just dump your stuff at us, never reply, and never bother to test whether it's actually been fixed.

[baetheus]

I apologize for not updating this ticket. I tried manually building 2.3.11 but ran into some issues finding tap headers for smartos. I relayed that information to the pkgsrc maintainer for smartos and he pushed an update to smartos 16.2.0 zones. Unfortunately, that zones version release didn't happen until a week ago.

Anyway, I've pulled the new 16.2.0 zone dataset and installed/configured openvpn 2.3.11 on it and the issue is resolved. Again, sorry for the lack of communication.

[Gert Döring]

Replying to baetheus:

Anyway, I've pulled the new 16.2.0 zone dataset and installed/configured openvpn 2.3.11 on it and the issue is resolved. Again, sorry for the lack of communication.

Thanks a lot for following up in spite of my grumbling :-) - and indeed, this is good news (not totally unexpected, but confirmation is always welcome).