Openvpn routing issue
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenVPN |
Unknown
|
Unknown
|
|||
openvpn (Debian) |
Fix Released
|
Unknown
|
|||
openvpn (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
* non-default but still common openvpn setups use callout scripts with
sudo (if the openvpn user was set up to work with sudo). That breaks in
>=Bionic since CAP_AUDIT_WRITE was dropped which makes pam/sudo denying
the call.
* We brought the change upstream and want to backport into Cosmic/Bionic
to avoid Xenial upgrades to hit this.
* Interesting is that the upstream .deb is not affected by still having
Xenial rules:
=>https:/
[Test Case]
* details in https:/
und-ipv6 which the reporter and I followed (warning: non commands are
german)
* there is no need to do any of the IPV6 stuff in the guide nor the
iptables actions
TL;DR would be:
* apt install openvpn (on client and server)
$ sudo apt install openvpn easy-rsa
Use easy-rsa to create 1 server and 1 client certificate
See the link above for commands to do so if you are unfamiliar
* add "openvpn" user and grant him sudo permission for your test script
$ addgroup --system --no-create-home --disabled-login --group openvpn
$ adduser --system --no-create-home --disabled-login --ingroup openvpn openvpn
* add server/client config as outlined in comment #25
the important bit is to have a sudo call to a helper like:
learn-address "/usr/bin/sudo -u root /etc/openvpn/
client.conf
client
dev tun
proto udp
remote 192.168.122.29 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/
cert /etc/openvpn/
key /etc/openvpn/
remote-cert-tls server
cipher AES-256-CBC
tls-version-min 1.2
tls-cipher TLS-ECDHE-
auth SHA512
comp-lzo
verb 6
explicit-
server.conf
port 1194
proto udp
dev tun
ca /etc/openvpn/
cert /etc/openvpn/
key /etc/openvpn/
dh /etc/openvpn/
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-
script-security 2
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
tls-version-min 1.2
tls-cipher TLS-ECDHE-
auth SHA512
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 6
user openvpn
group openvpn
* Create the test script
$ sudo mkdir -p /etc/openvpn/
$ sudo echo "id" >> /etc/openvpn/
$ sudo chmod +x /etc/openvpn/
* Start the server service and run journalctl -f
* Let the client connect (you will see the denies on the server)
[Regression Potential]
* It adds one allowed capability (a rather safe one btw) to the service
of openvpn. There should be no regression risk breaking functional
setups.
If anything security concerns, but since it was this way in Xenial even
that should not apply
[Other Info]
* This was in Xenial, picked by upstream for their own .deb package but
not integrated in their actual repository. Debian by aligning with
upstream dropped it and we followed. This time we made sure it gets
upstream and therefore hopefully should not reoccur again
---
I updated my Server from xenial to bionic today. on xenial I was using the openvpn repo from the openvpn developers (https:/
now that bionic ships a more recent version I removed the ppa and switched to the distro version (2.4.4)
my openvpn server assings a real ipv6 address and does nat for ipv4 forevery client. Also i push a route so a /64 ipv6 net and one ipv4 address is reachable through the tunnel.
(I have firewalled a server so it is only reachable through the tunnels ips)
With openvpn 2.4.4 from bionic repo this does not work anymore, aka the server is not reachable anymore.
I quicky reactivated the xenial repo from https:/
after a restart I was able to reach my server again.
so most likely there is a bug in bionics 2.4.4 version of openvpn
client config:
client
dev tun
proto udp
remote <ipv4-address> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert martin-pc.crt
key martin-pc.key
remote-cert-tls server
tls-crypt ta.key
cipher AES-256-GCM
tls-version-min 1.2
tls-cipher TLS-ECDHE-
auth SHA512
comp-lzo
explicit-
pull-filter ignore "route"
pull-filter ignore "dhcp"
pull-filter ignore "redirect"
route-ipv6 <ipv6-net i want to reach>/64 <ipv6 ip of server> 1
route <server i want to reach ipv4> 255.255.255.255 10.8.0.1 1
server config:
port 1194
proto udp
dev tun
ca /etc/openvpn/
cert /etc/openvpn/
key /etc/openvpn/
dh /etc/openvpn/
topology subnet
server 10.8.0.0 255.255.255.0
server-ipv6 <ipv6 net usable for clients>/112
ifconfig-
push "route-ipv6 2000::/3 <ipv6 server ip> 1"
script-security 2
learn-address "/usr/bin/sudo -u root /etc/openvpn/
push "redirect-gateway def1"
push "redirect-gateway ipv6"
push "dhcp-option DNS 1.1.1.1"
keepalive 10 120
tls-crypt /etc/openvpn/
tls-version-min 1.2
tls-cipher TLS-ECDHE-
auth SHA512
cipher AES-256-GCM
#compress lz4
comp-lzo
persist-key
persist-tun
status openvpn-status.log
#verb 6
user openvpn
group openvpn
Related branches
- Andreas Hasenack: Approve
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 29 lines (+9/-1)2 files modifieddebian/changelog (+8/-0)
debian/openvpn@.service (+1/-1)
Changed in openvpn (Debian): | |
status: | Unknown → Confirmed |
Changed in openvpn (Ubuntu Bionic): | |
status: | New → Triaged |
Changed in openvpn (Ubuntu Cosmic): | |
status: | Confirmed → Triaged |
description: | updated |
Changed in openvpn (Debian): | |
status: | Confirmed → Fix Released |
Status changed to 'Confirmed' because the bug affects multiple users.