Re: [Openvpn-users] How to properly upgrade openvpn server on Ubuntu servers (18.04 and 20.04)?
On Sun, 3 Jul 2022 20:41:47 -0400, Nathan Stratton Treadway wrote: >On Sun, Jul 03, 2022 at 21:55:13 +0200, Bo Berglund wrote: >> I have looked at the directory /etc/apt/sources.list.d and found a file there >> named openvpn-aptrepo.list >> It contains this single line: >> # deb http://build.openvpn.net/debian/openvpn/stable bionic main # disabled >> on >> upgrade to bionic >> > >Yes, for what it's worth it looks like you probably followed the >instructions found at > > > https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos#DebianUbuntu:UsingOpenVPNaptrepositories > >back when you first installed OpenVPN. Yes, now that I found the left-over file I remember that the process was along these lines... Seems like the distro upgrade orphaned openvpn but left it in place as-is. >> Is there a good description on *exactly how* to make openvpn part of apt >> updates >> again on an Ubuntu 18.04 LTS and an Ubuntu 20.04 LTS server? > >This was covered a bit in the other thread, but I think you have two >options at this point: > > * if you want to switch to using the standard openvpn packages >provided by Ubuntu itself (which it seems like would probably be >fine for your purposes), then you just need to manually force the >installation of the current Ubuntu package (with something along the >lines of "apt install openvpn/focal" or "apt install >openvpn=2.4.7-1ubuntu2.20.04.4"). > >Once you switch to a stock-Ubuntu package version, then later >package releases will be assigned higher version nubmers and will be >automatically upgraded-to in the usual way. I think that this is the way I should go since my usage is not advanced in any real way, I just have external access to the local network in both places and also using a second service Internet access via VPN for geo-location switching. And I recently expanded usage so that my two personal LAN:s (home and summer cottage) are connected together via OpenVPN bidirectionally. If I understand it you are saying that by using the apt command to install the current version for focal the existing openvpn would be replaced by the one in the Ubuntu distro repository and the act of installing it that way would also put it in the group of packages that will be automatically upgraded come the next distribution upgrade? > * If you want to keep using the OpenVPN-project provided packages, >then you will want edit that openvpn-aptrepo.list file to re-enable >the line and update the "bionic" name to your current release. With >that re-enabled, you should see a new OpenVPN-project package >version, which apt will upgrade to from your current version. > >(But note that if you take this route, you will need to rememeber to >repeat the process each time you upgrade to a new version of Ubuntu >[since the upgrade process will disable the deb line in the >openvpn-aptrepo.list again].) No, I don't want to force the deviation from Ubuntu standard package handling for the obvious reasons you outline! Better to reset to the built-in handling in Ubuntu. I also have a number of RaspberryPi units with openvpn acting as remote access handler and on those I believe I have only used apt to install. But RPi distribution upgrades are not really available anyway so there is no such issue. I cannot get to a new distro without rebuilding systems from scratch (a new operating system image) Thanks for your valuable advice :-) -- Bo Berglund Developer in Sweden ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to properly upgrade openvpn server on Ubuntu servers (18.04 and 20.04)?
On Sun, Jul 03, 2022 at 21:55:13 +0200, Bo Berglund wrote: > I have looked at the directory /etc/apt/sources.list.d and found a file there > named openvpn-aptrepo.list > It contains this single line: > # deb http://build.openvpn.net/debian/openvpn/stable bionic main # disabled on > upgrade to bionic > Yes, for what it's worth it looks like you probably followed the instructions found at https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos#DebianUbuntu:UsingOpenVPNaptrepositories back when you first installed OpenVPN. > Is there a good description on *exactly how* to make openvpn part of apt > updates > again on an Ubuntu 18.04 LTS and an Ubuntu 20.04 LTS server? (There may be a blog post or something out there from someone else who has faced this situation, but it may not be a scenario covered by either OpenVPN or Ubuntu official documentation...) This was covered a bit in the other thread, but I think you have two options at this point: * if you want to switch to using the standard openvpn packages provided by Ubuntu itself (which it seems like would probably be fine for your purposes), then you just need to manually force the installation of the current Ubuntu package (with something along the lines of "apt install openvpn/focal" or "apt install openvpn=2.4.7-1ubuntu2.20.04.4"). Once you switch to a stock-Ubuntu package version, then later package releases will be assigned higher version nubmers and will be automatically upgraded-to in the usual way. * If you want to keep using the OpenVPN-project provided packages, then you will want edit that openvpn-aptrepo.list file to re-enable the line and update the "bionic" name to your current release. With that re-enabled, you should see a new OpenVPN-project package version, which apt will upgrade to from your current version. (But note that if you take this route, you will need to rememeber to repeat the process each time you upgrade to a new version of Ubuntu [since the upgrade process will disable the deb line in the openvpn-aptrepo.list again].) Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] How to properly upgrade openvpn server on Ubuntu servers (18.04 and 20.04)?
As described in my thread titled: "How to enable timestamps in server logfile?" I have a problem on my home VPN server running on Ubuntu Server 20.04.4 LTS regarding updating the software. It seems stuck at 2.4.7 sice quite some time... The server was release-upgraded to 20.04 about a year ago. Looks like this: $ openvpn --version OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019 And now I had a look at our office server (Ubuntu 18.04 LTS) and it looks the same: $ openvpn --version OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019 This server is running 18.04.6 LTS and was upgraded from Ubuntu 16.04 LTS probably back in 2019. OpenVPN was installed in the 16.04 days and has been stopped at 2.4.7 since quite some time it seems. It too needs an upgrade. I have looked at the directory /etc/apt/sources.list.d and found a file there named openvpn-aptrepo.list It contains this single line: # deb http://build.openvpn.net/debian/openvpn/stable bionic main # disabled on upgrade to bionic I assume this is the cause of the failure to keep openvpn current... Is there a good description on *exactly how* to make openvpn part of apt updates again on an Ubuntu 18.04 LTS and an Ubuntu 20.04 LTS server? -- Bo Berglund Developer in Sweden ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to enable timestamps in server logfile?
On Wed, 22 Jun 2022 18:32:59 -0400, Nathan Stratton Treadway wrote: >So now my guess is that you had an apt sources.list entry pointing to >the build.openvpn.net repo back in your Xenial days, which then probably >got disabled by the Ubuntu release-upgrade process (and thus apt no >longer suggests newer versions of the OpenVPN package from that repo). > I opened the /etc/apt/sources.list file on my server and searched for the word openvpn but it found no hit... But I do not know if that is the correct word to search for to get the entry that might have been a custom entry on 18.04... When I make a release upgrade (as suggested when logging on to the system via ssh) like I did from 18.04 to get to 20.04 does the process make a backup of the apt sources file or does it simply just remove the external locations? I found a file /etc/apt/sources.list.save but that too does not contain any trace of the word openvpn. That file is listing "bionic" in all places where the current file lists "focal" > >Anyway, at this point I think your choices now (when you are back home) >are either to manually switch to the current Ubuntu-provided package (as >discussed in the earlier emails), or to re-enable the build.openvpn.net >repo (switching to their Focal release) and then upgrade to the newer >package currently provided there. But presumably one way or the other >you will want to upgrade away from 2.4.7-xenial0... I will probably need very detailed instructions for that since I am not used to do anything other than: apt update && apt full-upgrade -y on my systems... -- Bo Berglund Developer in Sweden ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] auth-token behaviour change in v2.5.0
Hi, On Sat, Jul 2, 2022 at 6:20 PM Connor Edwards via Openvpn-users < openvpn-users@lists.sourceforge.net> wrote: > Right, I think I'm getting somewhere with this now. It's not the OpenVPN > server version, it seems to be something to do with the management socket > options. > > I mentioned that we have this in the config: > >management /run/openvpn/server/management.sock unix > >management-client-auth > > If I comment those lines out and add a verify script to just let any user > in: > >auth-user-pass-verify /verify.sh via-env > > There's no issues and the client stays connected through TLS reauths. > The above difference in behaviour rings a bell. I had noticed a similar misbehaviour in 2.6 (possibly also present in 2.5) that is very likely a bug. I looked into it again: On reauth, after auth token verification success, the log shows: test/127.0.0.1:35874 TLS: Username/auth-token authentication succeeded for username 'test' test/127.0.0.1:35874 TLS: Username/Password authentication deferred for username 'test' [CN SET] The "authentication deferred" line above results from the use of management-def-auth, but the management interface will not be notified in this case as auth-token bypasses it during reauth. This would lead to TLS keys going out of sync and eventual client-disconnect as the auth will stay deferred forever. Plugin and script based auths are not affected. The auth-token expiry message you see may be an indirect effect of this --- the server first disconnects the client, while the client continues and eventually does a ping-restart with the old token which will have a timestamp out of the reneg interval.. Could you please post a full verb=4 server log using official community releases for the client and server --- tunnelblick as client should be okay. It's not possible for us to reproduce what a viscosity client or server may be doing. Selva > > Logically you might think that the reason the clients are being kicked off > after a minute or so with management-client-auth is because another command > needs to be entered to allow reauth. But in this case the server does not > inform of reauth over the socket. > >client-auth-nt 0 0 > >>CLIENT:ESTABLISHED,0 > ... > >>CLIENT:DISCONNECT,0 > > I'm aware that external-auth can be appended to the auth-gen-token option > to handoff auth so that the server doesn't verify the token internally. > This isn't what we're looking for - we want the server to handle the auth > token generation and verification internally otherwise we'll have to > implement this ourselves. There's nothing in the docs that says this is > mutually exclusive with using the management socket. > >auth-gen-token 43200 external-auth > > Thanks > > > On Sat, Jul 2, 2022 at 5:07 PM Connor Edwards > wrote: > >> Hello David, >> >> Yep, I have had a look at the source and the auth token feature was >> overhauled in v2.5.0. >> >> This issue is reproducible with the Viscosity client for macOS which uses >> v2.5.5 under the hood. But so far in my testing the client version doesn't >> seem to matter, only the server version does. >> >> My colleague and I have pored over the docs/manpage/source code but we >> haven't been able to find why this is happening. We are using a token >> lifetime of 12 hours: >> >auth-gen-token 43200 >> >> Yet upon a client connecting, the server will log that the token is >> expired not even a few minutes later. >> >> Here is a fairly minimal server/client config that can reproduce it. Note >> that reneg-sec is set to 30 for demonstration of this issue only. >> >> server.conf >> >topology subnet >> >server 192.168.254.0 255.255.255.0 >> >port 443 >> >proto tcp >> >dev tun >> >user openvpn >> >group openvpn >> >ca /etc/openvpn/pki/ca.crt >> >cert /etc/openvpn/pki/issued/server.crt >> >key /etc/openvpn/pki/private/server.key >> >tls-server >> >tls-crypt /etc/openvpn/ta.key >> >tls-cert-profile preferred >> >cipher AES-256-GCM >> >remote-cert-tls client >> >verify-client-cert require >> >auth SHA512 >> >dh none >> >ifconfig-pool-persist ipp.txt >> >keepalive 10 120 >> >persist-key >> >persist-tun >> >management /run/openvpn/server/management.sock unix >> >management-client-auth >> >reneg-sec 30 >> >auth-gen-token 43200 >> >> client.conf >> >remote localhost 443 tcp-client >> >nobind >> >dev tun >> >redirect-gateway def1 ipv6 >> >persist-key >> >pull >> >auth-user-pass >> >tls-client >> >ca ca.crt >> >cert cert.crt >> >key key.key >> >remote-cert-tls server >> >tls-crypt tlscrypt.key >> >auth SHA512 >> >push-peer-info >> >cipher AES-256-GCM >> >> Steps to reproduce: >> >>1. Install OpenVPN server 2.5.5 >>2. Connect to the server management socket with nc >>-U /run/openvpn/server/management.sock >>3. Connect the client to the server >>4. Issue the client-auth-nt command in to the socket to allow the >>connection, for example: client-auth-nt 0 0 >>5. Watch the server logs >>6. Observe that the client is disconnected for an expired t
