I have a couple of vyos instances, all on 1.2. I brought up a rolling 1.3 release and cannot get OpenVPN to resolve addresses. Dig/host can resolve the hosts just fine and the same config used to work on 1.2 rolling (that said, those servers have name servers hard coded, this 1.3 server is pulling from DHCP). Oh, and it should be noted if I reboot the node, it has worked twice (10% success rate).
Jun 25 03:01:35 ss3 openvpn-vtun1[1653]: RESOLVE: Cannot resolve host address: us-california.privateinternetaccess.com:1198 (Name or service not known)
Jun 25 03:01:35 ss3 openvpn-vtun1[1653]: RESOLVE: Cannot resolve host address: us-california.privateinternetaccess.com:1198 (Name or service not known)
Jun 25 03:01:35 ss3 openvpn-vtun1[1653]: Could not determine IPv4/IPv6 protocol
Jun 25 03:01:35 ss3 openvpn-vtun1[1653]: SIGUSR1[soft,init_instance] received, process restarting
Hi @Silvenga can you disable the firewall? Perhaps a remote host has ipv4 + ipv6 addresses and trying to connect to ipv6? Can you check it, an example with tcpdump? Also, check please cat /etc/hosts
We need a configuration for reproducing it in our lab.
This should be reproducible without needing a correct cert or credentials.
show configuration commands
...
set interfaces openvpn vtun0 authentication password 'blah'
set interfaces openvpn vtun0 authentication username 'blah'
set interfaces openvpn vtun0 description 'us-atlanta'
set interfaces openvpn vtun0 encryption cipher 'aes128'
set interfaces openvpn vtun0 hash 'sha1'
set interfaces openvpn vtun0 mode 'client'
set interfaces openvpn vtun0 openvpn-option 'remote-cert-tls server'
set interfaces openvpn vtun0 openvpn-option 'tls-client'
set interfaces openvpn vtun0 openvpn-option 'resolv-retry infinite'
set interfaces openvpn vtun0 openvpn-option 'reneg-sec 0'
set interfaces openvpn vtun0 openvpn-option 'verb 3'
set interfaces openvpn vtun0 persistent-tunnel
set interfaces openvpn vtun0 remote-host 'us-atlanta.privateinternetaccess.com'
set interfaces openvpn vtun0 remote-port '1198'
set interfaces openvpn vtun0 tls ca-cert-file '/config/auth/pia/ca.crt'
set interfaces openvpn vtun0 use-lzo-compression
...
OpenVPN does allow for IPv4 to be forced, but that option is validated against.
set interfaces openvpn vtun0 protocol
Should allow:
udp
tcp
udp4
udp6
tcp4
tcp6
cat /etc/hosts
### Autogenerated by VyOS ###
### Do not edit, your changes will get overwritten ###
# Local host
127.0.0.1 localhost
127.0.1.1 ss3
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
I had this issue before and fixed it by using a solution provided by @raeven on Slack. Try setting openvpn-option “–proto udp4” on the interface. As soon as I did this, I was no longer getting errors resolving or determining protocol and openvpn began working as expected.
An perfect. That workaround completely mitigates the issue (and explains why it sometimes worked).
Now, I guess I wonder if this is a bug that I should submit to the tracker. While this does seem like a bug in OpenVPN, this same config works on a standard Ubuntu server (both without IPv6, similar OpenVPN versions). This suggests something Vyos is doing is making OpenVPN a little confused.