Charts: [stable/openvpn] Error encountered using generated client key from Ubuntu client.

[jaredbischof]

Is this a request for help?: Yes

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Version of Helm and Kubernetes: Helm version 2.7.0, Kubernetes version 1.8.6-gke.0

Which chart: stable/openvpn

What happened: The chart deploys fine and I can generate a client key. The client key works with Tunnelblick on my Mac but I've tried using it from a few different Linux clients and I'm unable to successfully connect to the VPN. I assume it is unsuccessful because of the error message and the fact that I cannot resolve k8s internal hostnames (I can resolve those hostnames from my Mac after connecting to the VPN). Here is the typical output when connecting:

shell:# openvpn --config kubeVPN.ovpn 
Thu Feb 22 10:17:09 2018 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
Thu Feb 22 10:17:09 2018 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
Thu Feb 22 10:17:09 2018 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Thu Feb 22 10:17:09 2018 Attempting to establish TCP connection with [AF_INET]35.226.143.19:443 [nonblock]
Thu Feb 22 10:17:10 2018 TCP connection established with [AF_INET]35.226.143.19:443
Thu Feb 22 10:17:10 2018 TCPv4_CLIENT link local: [undef]
Thu Feb 22 10:17:10 2018 TCPv4_CLIENT link remote: [AF_INET]35.226.143.19:443
Thu Feb 22 10:17:10 2018 WARNING: 'keydir' is present in remote config but missing in local config, remote='keydir 0'
Thu Feb 22 10:17:10 2018 WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.
Thu Feb 22 10:17:10 2018 WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.
Thu Feb 22 10:17:10 2018 [server] Peer Connection Initiated with [AF_INET]35.226.143.19:443
Thu Feb 22 10:17:13 2018 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: “dhcp-option (2.3.10)
Thu Feb 22 10:17:13 2018 TUN/TAP device tun0 opened
Thu Feb 22 10:17:13 2018 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Feb 22 10:17:13 2018 /sbin/ip link set dev tun0 up mtu 1500
Thu Feb 22 10:17:13 2018 /sbin/ip addr add dev tun0 local 10.240.0.6 peer 10.240.0.5
RTNETLINK answers: Invalid argument
Thu Feb 22 10:17:13 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Thu Feb 22 10:17:13 2018 Initialization Sequence Completed

What you expected to happen:
I expect to connect without the error message and be able to resolve k8s internal hostnames.

How to reproduce it (as minimally and precisely as possible):
Deploy the chart and create a client key as prescribed in the documentation. Attempt to connect to the VPN server from a client running Ubuntu 16.04 LTS.

Anything else we need to know:
I realize there may be an obvious solution to someone who is more familiar with using openvpn but I've tried some things to resolve the issue and failed so I figured others may run into the same problem.

[jfelten]

This sounds like a linux client incompatibility, which I admittedly have never tried. Can you specify any more details of your linux client? Can you provide steps to reproduce using a docker image?

[jaredbischof]

I was able to reproduce the error with this Dockerfile:

FROM ubuntu:16.04

# Install openvpn
RUN apt update
RUN apt-get -y install openvpn

CMD ["openvpn", "--config", "/kubeVPN.ovpn"]

The command to run the container is:
docker run -t -i --cap-add=NET_ADMIN --device /dev/net/tun -v $PWD/kubeVPN.ovpn:/kubeVPN.ovpn openvpn-client:latest

Note: This requires that you have kubeVPN.ovpn in your current directory.

[nitinjain999]

Quick Fix##### to add --dns on docker run

docker run -t -i --cap-add=NET_ADMIN --device /dev/net/tun -v $PWD/kubeVPN.ovpn:/kubeVPN.ovpn
-dns your_dns openvpn-client:latest

[jaredbischof]

@nitinjain999 that does not fix the error.

[jfelten]

I looked at this briefly and was able to replicate. The issue seems to be that the chart openvpn server is configured to push the route 10.0.0.0/8, which conflicts with the openvpn network range. Linux complains about this, but osx doesn't.

A possible solution is to simply remove this route by commenting out in values.yaml
# Kubernetes pod network (optional).
#OVPN_K8S_POD_NETWORK: "10.0.0.0"
# Kubernetes pod network subnet (optional).
#OVPN_K8S_POD_SUBNET: "255.0.0.0"

or change to a smaller range that doesn't conflict with the openvpn network. I have not had time to verify this yet, and will do so this afternoon.

[jfelten]

The error can be resolved by commenting out the following in templates/config-openvpn.yaml:

push "route NETWORK 255.255.240.0"

The reason is that this route is pushed by default by openvpn (I think), and linux doesn't like duplicate routes. Further testing is required to make sure this does not break anything else. Please let me know if this works for you. If it looks good I will issue a PR.

[jaredbischof]

Unfortunately, I tried both those changes alone and together but I'm still getting the same error. Did it work for you?

[jfelten]

yes it did work for me. Can I give you a kubeVPN.ovpn file to try?

[jfelten]

actually please paste your templates/config-openvpn.yaml

[jaredbischof]

Here it is.
config-openvpn.yaml.txt

[jfelten]

trying this on my server - what kind of cluster are you using?

[jaredbischof]

Can you paste your config and I will use exactly what you have?

[jfelten]

I just ran with yours and it worked:

docker run -t -i --cap-add=NET_ADMIN --device /dev/net/tun -v $(pwd)/kubeVPN.ovpn:/kubeVPN.ovpn openvpntest
Tue Feb 27 21:55:33 2018 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
Tue Feb 27 21:55:33 2018 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Tue Feb 27 21:55:33 2018 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Tue Feb 27 21:55:33 2018 Attempting to establish TCP connection with [AF_INET]104.154.158.63:443 [nonblock]
Tue Feb 27 21:55:34 2018 TCP connection established with [AF_INET]104.154.158.63:443
Tue Feb 27 21:55:34 2018 TCPv4_CLIENT link local: [undef]
Tue Feb 27 21:55:34 2018 TCPv4_CLIENT link remote: [AF_INET]104.154.158.63:443
Tue Feb 27 21:55:35 2018 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1543', remote='link-mtu 1443'
Tue Feb 27 21:55:35 2018 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1400'
Tue Feb 27 21:55:35 2018 WARNING: 'keydir' is present in remote config but missing in local config, remote='keydir 0'
Tue Feb 27 21:55:35 2018 WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.
Tue Feb 27 21:55:35 2018 WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.
Tue Feb 27 21:55:35 2018 [server] Peer Connection Initiated with [AF_INET]104.154.158.63:443
Tue Feb 27 21:55:37 2018 TUN/TAP device tun0 opened
Tue Feb 27 21:55:37 2018 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Feb 27 21:55:37 2018 /sbin/ip link set dev tun0 up mtu 1500
Tue Feb 27 21:55:37 2018 /sbin/ip addr add dev tun0 local 10.240.0.6 peer 10.240.0.5
Tue Feb 27 21:55:37 2018 Initialization Sequence Completed

I had to change the template name back to what it was, but nothing else. Have you modified anything else?

[jfelten]

does your chart have any errors when running helm lint?

[jfelten]

Did this ever get resolved for you?

[jaredbischof]

Sorry for the delay in getting back. Yes, this does work when removing:

push "route NETWORK 255.255.240.0"

I'm not sure why it didn't work for me the first time I tried it. Perhaps I used the wrong file. I went back and tested with and without that change and removing that line does seem to solve the issue.

[jfelten]

Thanks! - Does the vpn work properly when that route is removed?

[jaredbischof]

yes it does!

[josdotso]

Same here @jfelten

[khawaga]

I can confirm that removing push "route NETWORK 255.255.240.0" solves the connection issue, can we update the chart to modify the config?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[stale[bot]]

This issue is being automatically closed due to inactivity.

[belminf]

I'm not clear on why push "route NETWORK 255.255.240.0" is hard-coded in openvpn.conf via the ConfigMap template:

https://github.com/helm/charts/blob/8af9ba35e01d57ee687b1acca9cbddead173ba1e/stable/openvpn/templates/config-openvpn.yaml#L104

Can someone help me understand?