Unable to access hosts at home over VPN | Omnia 3.11.19

I have been unable to “use DNS from VPN” for a while. As a result I cannot remotely access my named hosts on the home network and web access fails. If I disable “use DNS from VPN” web access works.

Config:

Log output from Tunnelblick client:

Your help is much appreciated!

As i do not have any guide or steps for you, i just post my notes…maybe it will direct you further.

notes

From the log it seems you have openvpn config with necessary “list push” directives.
Seems those were applied and route(s) were added correctly.
Later it seems you have tunnelblick accept all the smb/netbios/dns configuration.
So you should check after connection if you can reach the dns server and if the server is responsive.

What is strange there is notice about the domain named ‘openvpn’ or none , with note about used/not used configuration …
Also there is note about topology net30 (you should have “subnet” instead i think)
Aside i’ve notice that there was change in MTU to 1625…which should be normally max 1500 …

Can you post the openvpn config and vpn zone setup?
If you are testing the vpn from same network as server, you should use “float” directive.
If that is win/osx you might want to consider to use ‘mssfix’ or ‘fragment’ directives.

Also maybe check the
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
If you are using some of them on client or/and server side it might cause some issues as well…(comp_lzo vs compress) i had one uses with Osx/Tunnelblick complaing about that three month ago.

1 Like

Thank you for looking into this issue. To clarify, it used to work before. But since maybe a few weeks ago I’m seeing the described issue from clients on Mac and Android. Both are connections from external networks. (I have never been able to use the VPN from my home network, but it would be nice to have the VPN always active from Android.) Note that I have also never edited the VPN configs manually. This is all Turris. (Automatic updates for Omnia are enabled.)

Openvpn client config:

root@turris:/etc/openvpn# cat /etc/config/openvpn

config openvpn 'custom_config'
	option enabled '0'
	option config '/etc/openvpn/my-vpn.conf'

config openvpn 'sample_server'
	option enabled '0'
	option port '1194'
	option proto 'udp'
	option dev 'tun'
	option ca '/etc/openvpn/ca.crt'
	option cert '/etc/openvpn/server.crt'
	option key '/etc/openvpn/server.key'
	option dh '/etc/openvpn/dh1024.pem'
	option server '10.8.0.0 255.255.255.0'
	option ifconfig_pool_persist '/tmp/ipp.txt'
	option keepalive '10 120'
	option compress 'lzo'
	option persist_key '1'
	option persist_tun '1'
	option user 'nobody'
	option status '/tmp/openvpn-status.log'
	option verb '3'

config openvpn 'sample_client'
	option enabled '0'
	option client '1'
	option dev 'tun'
	option proto 'udp'
	list remote 'my_server_1 1194'
	option resolv_retry 'infinite'
	option nobind '1'
	option persist_key '1'
	option persist_tun '1'
	option user 'nobody'
	option ca '/etc/openvpn/ca.crt'
	option cert '/etc/openvpn/client.crt'
	option key '/etc/openvpn/client.key'
	option compress 'lzo'
	option verb '3'

config openvpn 'server_turris'
	option enabled '1'
	option port '1194'
	option dev 'tun_turris'
	option ca '/etc/ssl/ca/openvpn/ca.crt'
	option crl_verify '/etc/ssl/ca/openvpn/ca.crl'
	option cert '/etc/ssl/ca/openvpn/01.crt'
	option key '/etc/ssl/ca/openvpn/01.key'
	option dh '/etc/dhparam/dh-default.pem'
	option server '10.111.111.0 255.255.255.0'
	option ifconfig_pool_persist '/tmp/ipp.txt'
	option duplicate_cn '0'
	option keepalive '10 120'
	option comp_lzo 'yes'
	option persist_key '1'
	option persist_tun '1'
	option status '/tmp/openvpn-status.log'
	option verb '3'
	option mute '20'
	option proto 'udp'
	list push 'route 192.168.2.0 255.255.255.0'
	list push 'redirect-gateway def1'
	list push 'dhcp-option DNS 10.111.111.1'

And here’s all VPN related entries from /etc/config/firewall since I don’t understand this matter nearly enough…

config rule 'vpn_turris_rule'
	option name 'vpn_turris_rule'
	option target 'ACCEPT'
	option proto 'udp'
	option src 'wan'
	option dest_port '1194'
	option enabled '1'

config zone 'vpn_turris'
	option name 'vpn_turris'
	option input 'ACCEPT'
	option forward 'REJECT'
	option output 'ACCEPT'
	option masq '1'
	option enabled '1'
	list network 'vpn_turris'

config forwarding 'vpn_turris_forward_lan_in'
	option src 'vpn_turris'
	option dest 'lan'
	option enabled '1'

config forwarding 'vpn_turris_forward_lan_out'
	option src 'lan'
	option dest 'vpn_turris'
	option enabled '1'

config forwarding 'vpn_turris_forward_wan_out'
	option src 'vpn_turris'
	option dest 'wan'
	option enabled '1'

What is used on client config/profile? “compress” or “comp_lzo”? AS i see you are using compress on disabled “sample_server” and “comp_lzo” on enabled one “server_turris”.
Resp. what version of openvpn client are you using with TunnelBlick? I assume that you have 2.4 server but with 2.3 client.
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-lzo
vs
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--compress

Are you having same issue with Android or Win clients ?

Client config generated by Turris (see Pastebin above) has compress lzo. And it should not be a problem.

Compression is not recommended and is a feature users should avoid using. To signal this clearly, --comp-lzo and --compress are discouraged and considered deprecated features. They will be removed in a future release.

Note the words discouraged and future.

I removed compress lzo from the client config and tested that. No change.

Yes, I’m experiencing the same symptoms on Android using the OpenVPN client. I’m not using a Windows client. I also noticed that it’s not a DNS problem like I suggested earlier. In fact I can’t even ping hosts in the VPN using their IP addresses. The connection goes up, but the home network is not available for use.

Tunnelblick uses OpenVPN 2.4.9 / OpenSSL v1.1.1g. I don’t know what version the Android OpenVPN client is using.

My working configuration …(which is not perfect, but it is working so far and was changed after one Mac users complained …)

  1. server config: option comp_lzo 'yes' v2.4.6 (i use it for backward compatibility with my older vpn clients (but i will change it to compress later on once i have all clients on 2.4 or higher version)
  2. win client: comp-lzo adaptive v2.3alpha2
  3. android client: compress lzo this is generated by Turris/Foris/Openvpn plugin, v2.4.6
  4. mac client: compress lzo (i do not know the version, but i believe it is v2.4.x)

MTU can be changed when there is mismatch of some directives.

compress, mssfix, fragment, cipher

that compress is adding 1 byte per packet (which can increase MTU if not set properly) , aside mssfix should deal with MTU in general and if bigger packet is passing using fragment should internally fragment that packet. And also cipher if used own list of ciphers can cause that link goes down as client and server can not do hanshake properly or link became over set mtu level (and breaks eventually after some time).

I had a lot of issues when i was playing with openvpn (before Foris easy-openvpn-plugin). And when MTU is changed on any side, link became unstable or break instantly. Sometimes you have to explicitly specify something so ‘default’ is not used or vice versa.

ad_deprecated: comp_lzo is deprecated in 2.4 and compress in 2.5 … so maybe it is better to not use it at all (removing, resp setting it to ‘no’, it from server and client’s configs --> but that will need Turris guys to alter openvpn-foris plugin to generate config without that directive).

check compress : https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

notes

there are some notes around compress/comp-lzo … i think you can remove compress (resp. set it to “no” and change all clients to not use compression at all or set “adaptive” on client and change compression based on each client/version using related directive/option. There is also “push” variant.

ad_dns/ping: if you want your openvpn clients to reach each other (and lan clients as well) use option topology 'subnet' in server config.