Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only one dhcp-option is persisted in config through reboot #213

Open
maurin-at-homiwoo opened this issue Nov 13, 2023 · 5 comments
Open
Assignees
Labels

Comments

@maurin-at-homiwoo
Copy link

Hi,

I'm trying to use persistent config import to manage my connection to the VPN

However it seems that only one dhcp option is persisted through a reboot.

When I import my config, I have the following with a openvpn3 config-dump --config my-config :

client
proto udp
dev hwvpn
dev-type tun
remote a.b.c.d ppp
resolv-retry infinite
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name vps-aa1b6d08_f58152a2-eb4f-479e-a564-64925dba157b name
cipher AES-256-CBC
auth SHA256
auth-nocache
push-peer-info
verb 3
dhcp-option DNS x.y.z.x
dhcp-option DOMAIN hw
dhcp-option DOMAIN-SEARCH hw
up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved
<ca>
...
</ca>

<cert>
...
</cert>

<key>
...
</key>

<tls-crypt>
...
</tls-crypt>

If I connect to it everything works fine, but if I reboot and I do a config dump after the reboot I get :

auth SHA256
auth-nocache
<ca>
...
</ca>

<cert>
...
</cert>

cipher AES-256-CBC
client
dev hwvpn
dev-type tun
dhcp-option DOMAIN-SEARCH hw
down /etc/openvpn/update-systemd-resolved
<key>
...
</key>

nobind
proto udp
push-peer-info
remote a.b.c.d ppp
remote-cert-tls server
resolv-retry infinite
<tls-crypt>
...
</tls-crypt>

tls-version-min 1.2
up /etc/openvpn/update-systemd-resolved
verb 3
verify-x509-name xxxxxx name

Only the last dhcp-option is kept, which disable the dns query.

@dsommers
Copy link
Member

dsommers commented Nov 13, 2023

Can you provide the output of openvpn3-admin version --services and openvpn3 version ?

That said, using dhcp-option in local configurations may not always behave as expected; it's expected to be pushed. It might be that the new dns option is a better alternative. Search for --dns in the OpenVPN 2.6 man-page for details.

@maurin-at-homiwoo
Copy link
Author

maurin-at-homiwoo commented Nov 13, 2023

Sure, here is the openvpn3-admin version --services :

OpenVPN 3 D-Bus services:

  - Client backend starter service
     openvpn3-service-backendstart: v21

  - Configuration Service
     openvpn3-service-configmgr:    v21

  - Log Service
     openvpn3-service-logger:       v21

  - Network Configuration Service
     openvpn3-service-netcfg:       v21

  - Session Manager Service
     openvpn3-service-sessionmgr:   v21

And the openvpn3 version :

OpenVPN3/Linux v21 (openvpn3)
OpenVPN core v3.8.2 linux x86_64 64-bit
Copyright (C) 2012-2022 OpenVPN Inc. All rights reserved.

Thanks for the dns option, I'll check that and I'll add a comment here if I can use it as a workaround (and yeah, pushing the dns option might also be a solution).

@dsommers
Copy link
Member

The v21 should definitely work fine with --dns. I'll double check anyhow if there are some misbehaviours in the dhcp-option parsing in the Configuration Manager.

@maurin-at-homiwoo
Copy link
Author

I'm actually having the exact same issue with the --dns options. Only one is kept in the config through reboot (also the order of items in the config are sorted alphabetically in openvpn3 config-dump which is not the case before the reboot).

Here is the config I'm getting before the reboot with a config-dump :

client
proto udp
dev hwvpn
dev-type tun
remote a.b.c.d ppp
resolv-retry infinite
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name ... name
cipher AES-256-CBC
auth SHA256
auth-nocache
push-peer-info
verb 3
dns search-domains hw
dns server 1 address a.b.c.d
dns server 1 resolve-domains hw
up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved

And here is the one I'm getting after a reboot :

auth SHA256
auth-nocache
<ca>
...
</ca>

<cert>
...
</cert>

cipher AES-256-CBC
client
dev hwvpn
dev-type tun
dns server 1 resolve-domains hw
down /etc/openvpn/update-systemd-resolved
<key>
...
</key>

nobind
proto udp
push-peer-info
remote a.b.c.d ppp
remote-cert-tls server
resolv-retry infinite
<tls-crypt>
...
</tls-crypt>

tls-version-min 1.2
up /etc/openvpn/update-systemd-resolved
verb 3
verify-x509-name xxxxx name

But actually I cannot even get it to work before rebooting, my resolvectl shows no dns configuration at all for the vpn interface :

Link 19 (tun0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Is that the expected configuration to have for dns ? :

dns search-domains hw
dns server 1 address a.b.c.d
dns server 1 resolve-domains hw

Also is there a way to set the dns-scope to tunnel without using the config-manage tool ? It was the default in openvpn but now it seems to be global by default and we have to do

openvpn3 config-manage --show --config ovhw-vpn --dns-scope tunnel

to set the dns provided only for the vpn resources.

However I got it to work by pushing from the server the options with the dchp-option mode. But I can still do some testing to dig a little bit more in that if you can't reproduce it on your side.

@dsommers
Copy link
Member

Thx! I had a quick look at the code, and I believe I see a potential bug in the handling of dhcp-option and dns options now. I'll dig into this a bit more.

That said, the dns option is being planned to be a replacement of dhcp-option in the long run for DNS configuration. The dhcp-option behaves quite differently between various OpenVPN implementations (OpenVPN 2.x command line, OpenVPN 2 (Windows) GUI, OpenVPN Connect, Tunnelblick, etc, etc) The dns option tries to avoid that trap, as it should be fairly well documented now what it is expected to do and the limitations it has on various platforms. Such details has been mostly lacking for dhcp-option for a long while; it might be slightly better nowadays - but the damage has already been done to be able to unify it.

I strongly recommend moving over to using dns and for the time being (as a workaround), pushing it from the server.

@dsommers dsommers self-assigned this Nov 13, 2023
@dsommers dsommers added the bug label Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants