[Openvpn-users] OpenVPN 3 Linux v24 released
time, but it seems to have improved since the v22_dev with GDBus++. We still see this occasionally on a few Linux distributions with systemd-resolved. But since we also see the systemd-resolved accepting the DNS updates and removals, we believe this is might be more an issue in systemd-resolved at this point. This issue appears now only with systemd-resolved and is not reproducible in all environments. * Bugfix: Duplicated name servers or search domains to /etc/resolv.conf In prior releases, when the Network Configuration service was configured to use /etc/resolv.conf for DNS resolving it could append duplicated DNS name servers and search domains if duplicates where pushed or added by other VPN connections or present prior to starting the VPN session. In v24 duplicated name servers and search domains are filtered out to only have a single presence of them in /etc/resolv.conf. * Bugfix: openvpn3 sessions-list does not reflect the correct DCO status When running the openvpn3 sessions-list and openvpn3-admin sessionmgr-service --list-sessions commands, the DCO status was not necessarily reflecting the reality. Typically, if the VPN client process failed to activate and use the DCO kernel module, it would still be listed as DCO enabled while in reality being a normal tun interface. This has been resolved in v24 where it will now query the VPN client process for the actual DCO status - not just the configured and requested DCO mode. * Bugfix: Stray VPN sessions not cleaned up In cases where a VPN session have had a log forwarder enabled (like via the openvpn3 log command) and that log forwarder has been stopped, the VPN session would be lingering in the Session Manager as a stray session with no available session details. This is also seen via openvpn3 sessions-list. Attempting to remove the session using openvpn3 session-manage would fail with an error. This has been resolved in v24, where the error situations which might appear if a previous log forwarder could not be identified are now properly handled and will not block the internal session clean-up in the Session Manager. * Bugfix: Spurious CreateVirtualInterface() errors when re-starting failing sessions In some special situations where a running VPN session stopped and attempted restarted after a openvpn3 session-manage --cleanup, the tunnel would fail with various CreateVirtualInterface() and TUN_SETUP_FAILED errors. The session management code has been gradually improved since v22_dev, v23 and now v24 - where stopped and failing sessions are handled better and removed correctly in the Session Manager. * Bugfix: openvpn3 log with --session-path does not work In some scenarios, using openvpn3 log --session-path did not work and did not report any log events. This has been under investigation for a long time and this issue has not been seen since the release with v22_dev and GDBus++. We consider this issue resolved with the updated openvpn3-service-log service in the v22_dev release. * Bugfix: openvpn3 session-start fails with only 2FA authentication The openvpn3 session-start would fail to start a session if the configuration profile would only require 2FA authentication. This has also been fixed since the v22_dev with GDBus++ release which included a refactoring of how VPN sessions were established. * Bugfix: Spurious GLib error messages The shell completion (with bash-completion installed) could often appear with disturbing and confusing GLib-GObject-CRITICAL errors in the output. This has most likely been fixed since v22_dev and the migration to the GDBus++ library. Since this did not happen each time and it varied a bit which Linux distributions it happened on we've kept this on our radar for some time. We now feel more confident this type of errors is being handled properly and should not disturb the user any more. Known issues: - openvpn3-admin journal --since has a time zone related issue and may not list all log events within the closest hours. Credits --- Thanks goes to those continuing testing and reporting issues. Razvan Cojocaru has continued to improve aspects of OpenVPN 3 Linux and Petr Portnov has provided fixes enabling OpenVPN 3 Linux to become available in NixOS. Supported Linux distributions - - Debian: 12 - Fedora: 40, 41, Rawhide - Red Hat Enterprise Linux 8, 9 - Ubuntu: 20.04, 22.04, 24.04 Red Hat Enterprise Linux 10 Beta is in also tech preview. Fedora 39 has reached EOL and is no longer supported. Installation and getting started instructions can be found here: <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> -- kind regards, David Sommerseth OpenVPN Inc Source tarballs --- * Open
[Openvpn-users] OpenVPN 3 Linux v23 released
se Linux 7 and Ubuntu 23.10 are EOL and is no longer supported. -- kind regards, David Sommerseth OpenVPN Inc Source tarballs --- * OpenVPN 3 Linux v23 <https://swupdate.openvpn.net/community/releases/openvpn3-linux-23.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-23.tar.xz.asc> * GDBus++ v2 <https://swupdate.openvpn.net/community/releases/gdbuspp-2.tar.xz> <https://swupdate.openvpn.net/community/releases/gdbuspp-2.tar.xz.asc> SHA256 Checksums -- 3c5a4e27e0618f395c1688b50b62b887543ff203d4c99af7f7bfe1d61d0e753b openvpn3-linux-23.tar.xz cc801911df93072101e6218ac62c45e8f524cb42c0536e692d8da5fe8b1253d8 openvpn3-linux-23.tar.xz.asc 0a3eab5c7f1f5ba803bec0902bb008b8c7a7040fdaf0e0e94b4ac77ffebf0bfd gdbuspp-2.tar.xz 361fe7f8ced70d49a2899ad4e790d6e9e1832f419ef3d7875226d44d997b7397 gdbuspp-2.tar.xz.asc git references git repositories: - OpenVPN 3 Linux <https://codeberg.org/OpenVPN/openvpn3-linux> (PRIMARY) <https://gitlab.com/openvpn/openvpn3-linux> (code-only mirror) <https://github.com/OpenVPN/openvpn3-linux> (code-only mirror) git tag: v23 git commit: d8239ede97fc91919f35a59a14a116769defcc49 - GDBus++ <https://codeberg.org/OpenVPN/gdbuspp/> (PRIMARY) <https://gitlab.com/openvpn/gdbuspp/> (code-only mirror) <https://github.com/openvpn/gdbuspp/> (code-only mirror) git tag: v2 git commit: 94f29d20accb755a08a9890efe5242d89d5b51bc Changes from v22_dev to v23 --- David Sommerseth (24): configmgr: Load configuration profiles before starting the D-Bus service netcfg: Make NetCfgNotifSubscriptions use uint32_t as filter bit mask codestyle: Fix minor code style deviations build: Enable overriding OpenVPN 3 Core Library version string scripts: Modify the output of the --gui-version addons/devposture: Fix compilation error with older JsonCpp libraries addons/devposture: Make devposture-proxy test program more generic addons/devposture: Document the Enterprise Profile file format build: Install some additional documentation by default docs: Clarify a GDBus++ and mbed TLS build dependencies better build: Set PACKAGE_NAME to 'OpenVPN3/Linux' Some minor #include clean-ups configmgr: Cleaning up #include files configmgr: Use CoreLog for logging events from the Core library. client: Don't stop if devposture service is unavailable devposture/test: Improve argument parsing in devposture-proxy addon/devposture/proxy: Properly re-throw DevPosture::Proxy::Handler exceptions netcfg/resolved: Factor out resolved::Exception to a separate file tests/resolved: Extend systemd-resolved proxy test client with IPv6 support netcfg/resolved: Add new D-Bus IP Address parser class netcfg/resolved: Use GDBus++ glib2 helpers extracting data in SearchDomains::GetGVariant netcfg/resolved: Plug-in resolved::IPAddress into ResolverRecord netcfg/resolved: Refactor out resolved::ResolverRecord core: Update to OpenVPN 3 Core Library v3.10.1 Grzegorz Gutowski (1): python: Pass through --connect-retry and --connect-retry-max Lev Stipakov (5): netcfg: use proper C++ base type for NetCfgChangeType netcfg/proxy: Check non-response call for nullptr before freeing configmgr: remove unused class members addons/aws: Switch to GDBus++ addons/aws: adapt to core RandomAPI changes Razvan Cojocaru (10): core: Update to OpenVPN 3 Core Library releaseprep/3.10 addons/devposture: Add openvpn3-linux-devposture configmgr: Add the enterprise-profile override ovpn3cli/config: Add openvpn3 config-manage --enterprise-profile client: Plug in Device Posture support configmgr: Use a regular expression to determine version number configmgr: Accumulate proxy feature flags instead of overwriting netcfg: Check stub-resolv.conf before giving up on systemd-resolved common: give SingleCommand a virtual destructor addons/devposture: Add core_ver and extra_ver to client_info -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to continue operation with comp-lzo and/or migrate from it?
On 01/07/2024 09:13, Eike Lohmann wrote: Dear Devs, what is the state of --compress migrate? As Gert stated in the mail you replied to now: > "compress migrate"? That is brand new and has only been > introduced into 2.6 😄 - so this will stay for a long time. This is an option only needed to be used on the server side. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN 3 Linux v22_dev released
OpenVPN 3 Linux v22_dev (Limited Release) This is a limited release primarily targeting Fedora 39 and newer plus Ubuntu 24.04. Other Linux distributions shipping glib2 version 2.76 or newer will also benefit from this release. This release contains a massive re-factoring of the D-Bus integration layer with glib2. The glib2 2.76 and newer releases contains several internal changes which broke the D-Bus implementation layer in OpenVPN 3 Linux v21 and older releases [1]. To fix this, it was decided to split out the base D-Bus integration into a new standalone library which OpenVPN 3 Linux will depend on. This new project is called GDBus++. [1] <https://github.com/OpenVPN/openvpn3-linux/issues/171> The GDBus++ library makes extended use of multi-threading when processing D-Bus method calls and implements modern C++17 approaches when handling requests to registered D-Bus objects. It has also been a strong focus on getting rid of as much of various glib2 warnings which could occasionally appear in prior OpenVPN 3 Linux releases. There are most likely a still a lot more room for improvements to both the new GDBus++ and the upgraded OpenVPN 3 Linux code, which is why this release targets a more limited release scope. This release has only been through the full QA validation on Fedora 39, Fedora 40 and Ubuntu 24.04. That said, this new code can be made available for all the officially supported RPM distributions by enabling a "development snapshots" repository. But this repository will also not have the same QA guarantees as the official stable repositories. On a development note, this project has now migrated to use Meson [2] as the build system. The autoconf/automake build system is now completely removed. The Meson build system has turned out to be way simpler to use and configure than autotools ever was, especially from a developers point of view. [2] <https://mesonbuild.com/> There are unfortunately a few known issues which is targeted for the coming v23 release: - AWS VPC integration is not yet ready, so this add-on is currently not available in this v22_dev release. This is targeted for v23. - Shell completion may list duplicated options in some cases - openvpn3-admin journal --since has a time zone related issue and may not list all log events within the closest hours. Other changes worth mentioning with this release: * Improvement: Upgrade to OpenVPN 3 Core library v3.8.5 This upgrade contains several bug fixes related to the option parser, mostly issues reported by a wide range of users. In addition to incorrect behaviour with the stub compression when the --compress option was used. * Improvement: openvpn3-admin journal --since argument The --since argument can now use the keywords 'today' and 'yesterday'. * Bug fix: openvpn3-admin log-service would not change some settings On some distributions, the --dbus-details and other boolean flags was not properly changed when requested. This has been improved. Credits --- Finally, it is needed to give a HUGE THANK YOU to all the community testers which installed and tested rolling development snapshots during the development of this release. Without all this testing, we would not have the same confidence in this release as we have now. All your help and feedback has been really valuable and helpful during this the development phase. Supported Linux distributions - - Fedora: 39, 40, Rawhide - Ubuntu: 24.04, (amd64, arm64) - Red Hat Enterprise Linux 8, 9 (no QA, development snapshot only [3]) Installation and getting started instructions can be found here: <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> The v23 release will also include support for all distributions again, including Debian 12. Debian 11, Red Hat Enterprise Linux 7 and Ubuntu 23.10 will go EOL in just a few days or weeks and will no longer be supported. [3] Fedora Copr development snapshots: <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3-devsnapshots/> -- kind regards, David Sommerseth OpenVPN Inc Source tarballs --- * OpenVPN 3 Linux v22_dev <https://swupdate.openvpn.net/community/releases/openvpn3-linux-22_dev.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-22_dev.tar.xz.asc> * GDBus++ v1 <https://swupdate.openvpn.net/community/releases/gdbuspp-1.tar.xz> <https://swupdate.openvpn.net/community/releases/gdbuspp-1.tar.xz.asc> SHA256 Checksums -- ad8f373814bfbefd12f9824d57badef4535f6c1fde68d2c73d7ee14863547cb6 openvpn3-linux-22_dev.tar.xz 32af8668130966959319ccd2769146090de5eab73a98612add6a5f9a99ff6921 openvpn3-linux-22_dev.tar.xz.asc e53e47f8529109e138d59ff38374818692b6fe26f2fee2d00642bba272e117a3 gdbuspp-1.tar.xz eff710210
Re: [Openvpn-users] Failed to reload openvpn.service: Job type reload is not applicable for unit openvpn.service.
On 26/02/2024 10:59, Peter Davis via Openvpn-users wrote: Hello, Why can't I reload the OpenVPN service? # systemctl reload openvpn Failed to reload openvpn.service: Job type reload is not applicable for unit openvpn.service. # # systemctl reload openvpn@Server Failed to reload openvpn@Server.service: Job type reload is not applicable for unit openvpn@Server.service. Please read this: <https://github.com/OpenVPN/openvpn/blob/master/distro/systemd/README.systemd> The openvpn.service unit file is a Debian specialty; not supported by the OpenVPN community. And the openvpn@CONFIG.service approach is also deprecated by the community - as it does not behave identical across Linux distributions. Please migrate to use the openvpn-server@CONFIG.service and openvpn-client@CONFIG.service unit files. They will in most cases behave better. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Request for feedback: Unbundling easy-rsa on Windows
On 19/02/2024 15:33, mich...@fritscher.net wrote: Good day, actually I use Easy-RSA on Windows on a regular base. Sometimes even for OpenVPN servers on Windows, but most times for provisioning customer configurations (1 server and 2-3 clients, fairly static) with an unique key+cert set. In one product we have even automated the usage of Easy-RSA in the build process which needs to be run unter Windows because of the product. Would it be a too big obstacle for you to run and use easy-rsa via WSL? Where you have the easy-rsa package just an `apt install easy-rsa` away? Or would it be fine to install it separately, but not part of the OpenVPN install? -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Can a configuration item be cleared in the server.conf file
On 05/02/2024 13:38, Mathias Jeschke wrote: Bo Berglund wrote: I mean the logs being produced from these server.conf lines: status /etc(openvpn/log/openvpn-status.log log /etc(openvpn/log/openvpn.log verb 4 Why do you insist on using legacy file based logs? Systemd's journal has much better options to filter/display log messages. And the best - it's enabled by default on systemd based systems. On top of that, using the --log option writing to file may impact OpenVPN's tunnel performance if there are issues writing log events to disk - because OpenVPN 2.x is single-threaded, so that happens in between parsing all the tunnel traffic, authentication and everything else it does. When OpenVPN calls the syslog() call, the kernel ensures the log event is sent to the proper logging service (systemd-journald, rsyslog, syslog, etc) without delaying too much. You can omit some of these performance issues by enabling DCO (kernel based OpenVPN Data Channel Offload) but then you need OpenVPn 2.6+. And just a few examples using journalctl ... - Get the logs for the OpenVPN server config tun0.conf, just the last 4 hours of log data # journalctl -u openvpn-server@tun0 --since -4h - Similar to above, but "grep" for a specific IP address # journalctl -u openvpn-server@tun0 --since -4h -g 192.168.0.1 - Retrieve log events between 8 and 4 hours back in time # journalctl -u openvpn-server@tun0 --since -8h --until -4h - Retrieve the first 100 log events happening yesterday # journalctl -u openvpn-server@tun0 --since yesterday -n 100 - Retrieve the log events for a specific PID # journalctl _PID=12345 - Retrieve log events sent from any "openvpn" process since the last boot # journalctl -b-1 SYSLOG_IDENTIFIER=openvpn - Similar to the above, but only list log events from a specific PID in addition # journalctl -b-1 SYSLOG_IDENTIFIER=openvpn + _PID=12345 All of these examples can be combined. And even more possibilities exists. And of you add -o json-pretty ... you get to see all the additional meta data information you can match on. If it's important for you to preserve log events for a longer time, ensure /etc/systemd/journald.conf has enabled Storage=persistent ... that will store all log events to disk, in the binary journal format. Otherwise it's memory-only logging. And the systemd-journald has built-in log rotation, where you can define how much disk space the logs can consume. Once it reaches that limit, it starts removing the oldest log data. You may also want to consider ensuring log compression is enabled too. That's why the --log option in OpenVPN should be avoided. It has poorer performance, you need to do log rotation manually (requiring the openvpn to get reloaded, which interrupts tunnel) and without a quite powerful log query tool. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Can a configuration item be cleared in the server.conf file
On 05/02/2024 15:12, Bo Berglund wrote: On Mon, 5 Feb 2024 14:04:38 +0100, Gert Doering wrote: Hi, On Mon, Feb 05, 2024 at 12:25:51PM +0100, Bo Berglund wrote: How old is your OpenVPN? This is on the Ubuntu 20.04 LTS server: Aug 21 2023: $ openvpn --version OpenVPN 2.4.12 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] Ah, yes. So that's a bit of an antique :-) $ apt policy openvpn openvpn: Installed: 2.4.12-0ubuntu0.20.04.1 Candidate: 2.4.12-0ubuntu0.20.04.1 Cannot get anything newer... You can get newer ones via the OpenVPN community based repositories: <https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos#DebianUbuntu:UsingOpenVPNaptrepositories> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Two questions about key generation for clients
On 21/01/2024 17:34, tincantech via Openvpn-users wrote: Can I edit this file and remove the item --suppress-timestamps to possibly enable the timestamps? And remove the machine-readable-output item in the actual service conf file? Will that result in human-readable timestamps? The recommended method is to copy the file to /etc/systemd/system. Actually, the preferred way is to use # systemctl edit openvpn-server@CONFIG_NAME You now get an new file where you just add the "ini sections" and settings you want to modify. In this case, you would add the "[Service]" section and add the modified ExecStart= line to your liking. These changes are saved separately and will always be merged into service setup, even when the unit file from the upstream OpenVPN package gets updated. If you do the "copy to /etc/systemd/system" trick, that will completely override the unit file shipped with the OpenVPN package. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Are my configurations secure enough?
On 27/12/2023 12:43, Jason Long via Openvpn-users wrote: [...snipp...] Server config is: port 2023 proto udp dev tun1 ca /etc/openvpn/server/ca.crt cert /etc/openvpn/server/H_Server.crt key /etc/openvpn/server/H_Server.key dh /etc/openvpn/server/dh.pem server 20.20.0.0 255.255.255.0 20.20.0.0/24 is not a private RFC1918 IP address range. This may hit you by surprise. The VPN IP address range should be a private IP address range only. push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 172.20.1.2" push "dhcp-option DNS 172.20.1.7" ​ push "route 172.20.0.0 255.255.255.0" topology subnet ​ keepalive 10 120 tls-crypt /etc/openvpn/server/ta.key 0 Wrong usage of tls-crypt. Read the man page, please. ​ cipher AES-256-GCM data-ciphers AES-256-GCM These two lines are not needed with OpenVPN 2.6. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] I have a question about Easy-RSA
On 07/01/2024 21:20, Bo Berglund wrote: [...snip...] If you have a couple of OpenVPN servers operating off of certs and keys generated back in 2014 (like I have), then these are probably set to expire this year 2024 because I think that the easyrsa I used back then sets a 10 year life of these. What is the proper procedure to refresh these so the servers will continue to operate into the future? The CA certificate can be renewed. That means the CA certificate will be updated, but keys already signed with that CA will still validate against it (because the public/private keys remains the same). A certificate is basically just some meta data (Subject, Issuer, date ranges of validity, etc) attached to a public key and a signature. A CA certificate is no different, except root CAs are self-signed. So renewing an existing certificate just updates the expiry date fields in the meta data section of the certificate and attaches a new signature to it. I assume there are things that needs to be done on the server side, right? That is correct. But also the client side need to be updated. "Everyone" need a new CA certificate to be able to properly validate the remote end. Also beware that client and server certificates typically are not valid longer than the CA. And that's why it's not uncommon to just start fresh with a completely new and fresh EasyRSA PKI setup. As there will be lots of work anyhow when the CA expires. As general recommendations with EasyRSA based setups, I would suggest: * Use an EasyRSA CA for one specific use case; like a single or a pool of collaborating OpenVPN servers intended. If you have a different use case in addition, use a separate EasyRSA setup for that. * Make the CA expire after the total expected lifetime of your servers. At some point you will upgrade the servers with a fresher setup, so plan the EasyRSA to have approximately the same lifetime (or slightly longer). Or chose 20 years (or your expected retirement date) as the CA lifetime ;-) * If you deploy OpenVPN in a more enterprise oriented environment, look at what kind of CA management that environment provides you and use that instead of EasyRSA. For example, FreeIPA provides infrastructure to be a CA with even automatically renewing server certificates for OpenVPN. Such environments will most likely have everything setup to ensure certificates are up-to-date and valid for the lifetime of that setup. With such a setup, the most painful part will be to distribute only new client configurations with new CA certificates for hosts/users not enrolled into the centralized CA infrastructure. Clients and servers enrolled into such a centralized CA infrastructure will get the CA certificates updated automatically as well. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Remote DNS server
On 11/12/2023 11:09, Jason Long wrote: On 06/12/2023 11:09, Jason Long via Openvpn-users wrote: Hello, Suppose the OpenVPN server is located in another country, but the DNS server is inside the company. What options should be included in the server and client configuration >file? Thank you. For OpenVPN 2.6 and newer, the new --dns option is preferred. For OpenVPN 2.5 and older, use --dhcp-option. If you operate in a mixed environment with clients running both 2.5 and 2.6, you can push both --dns and --dhcp-option from the server to clients (via --push). And once all your client is updated to 2.6, remove the --dhcp-option. The reason for preferring --dns is that it should have a consistent behavior across platforms. The --dhcp-option has several corner cases where it does slightly different things depending on if you're on Windows, macOS or Linux. *BSD and some Linux setups will not do the DNS setup out-of-the-box and will require additional script hooks to be enabled (the exception is when starting VPN sessions via NetworkManager). Hosts running OpenVPN 3 Linux will get DNS setup out-of-the-box, and that should support the --dns option as well. -- kind regards, David Sommerseth OpenVPN Inc Hello, Thank you so much. Do you mean the below lines for "server.conf": OpenVPN 2.5  ==> push "dhcp-option DNS IP" OpenVPN 2.6  ==> dns IP ? I'm pretty sure I said: >> you can push both --dns and --dhcp-option from the server to >> clients (via --push) Do clients need special settings? What makes you think so? Wouldn't that defeat the purpose of --push? Now, as I said ... If you have both OpenVPN 2.5 and OpenVPN 2.6 clients connecting, you should push *both* dhcp-option and dns option(s) until all your clients are running OpenVPn 2.6. OpenVPN 2.5 does only support dhcp-options. OpenVPN 2.6 supports both, but will prefer --dns options over dhcp-options for DNS configurations. Is "dns search-domains domain [domain ...]" necessary? For example, your local network has a domain like "example.xyz". Depends on your own requirements for your DNS setup. The man page explains what it does. On *nix systems, this maps to the "search" line in /etc/resolv.conf. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Remote DNS server
On 06/12/2023 11:09, Jason Long via Openvpn-users wrote: Hello, Suppose the OpenVPN server is located in another country, but the DNS server is inside the company. What options should be included in the server and client configuration file? Thank you. For OpenVPN 2.6 and newer, the new --dns option is preferred. For OpenVPN 2.5 and older, use --dhcp-option. If you operate in a mixed environment with clients running both 2.5 and 2.6, you can push both --dns and --dhcp-option from the server to clients (via --push). And once all your client is updated to 2.6, remove the --dhcp-option. The reason for preferring --dns is that it should have a consistent behavior across platforms. The --dhcp-option has several corner cases where it does slightly different things depending on if you're on Windows, macOS or Linux. *BSD and some Linux setups will not do the DNS setup out-of-the-box and will require additional script hooks to be enabled (the exception is when starting VPN sessions via NetworkManager). Hosts running OpenVPN 3 Linux will get DNS setup out-of-the-box, and that should support the --dns option as well. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN Plugins and Systemd
On 29/11/2023 19:50, Colin Ryan wrote: Folks, Trying to move my openvpn configuration to fully systemd modified. I've compiled openvpn with systemd support and fundamentally it works with the most recent systemd recipe's in the style of openvpn@.service Systemd until has this: [Service] Type=notify PrivateTmp=true WorkingDirectory=/opt/aa/config/aalan ExecStart=/opt/aa/sbin/openvpn --suppress-timestamps --config /opt/aa/config/aalan/%i.conf CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE CAP_AUD> LimitNPROC=20 DeviceAllow=/dev/null rw DeviceAllow=/dev/net/tun rw ProtectSystem=true ProtectHome=true KillMode=control-group RestartSec=30s Restart=always However it appears this is not allowing plug-ins to fork properly. -PLUGIN: Thread creation failed. If I use a much more primitive unit file from the early days of systemd usage where the Type=forking was used to essentially just run the daemon the exact same configuration file works. As well instance without plugin also works. I'm assuming it's some CapabilityBoundingSet issue. The daemon starts, management console is available, accepts connections attempts etc but when the fork to the plug-in goes it fails. Thoughts Colin Which distribution do you see this on? The openvpn@.service unit files has generally been deprecated in the upstream OpenVPN project for quite some time; due to inconsistent behaviors across distributions. Many distributions still continue to ship these, but it is being supported by the distribution only. The OpenVPN project ships openvpn-server@.service and openvpn-client@.service, which is considered to be a better alternative. This was introduced with OpenVPN 2.4, which added better systemd integration so systemd could better understand in which runtime status the OpenVPN process has. And it adds a lot of hardening, depending on the use case (client or server config). Can you please try and see if that works better? -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] --user specified but lacking CAP_SETPCAP
On 27/10/2023 15:25, Gert Doering wrote:
Systemd doesn't "mess with OpenVPN".
If it takes away capabilities OpenVPN needs, how would you call it, then?
"Sabotage"?
Incorrect setup actually. Or a bug. Depending on if the missing
capabilities is due to a local user's change in the openvpn-{client,
server}@.service unit files provided by the OpenVPN project or
distribution packaging, or using some other unit files from elsewhere.
The 2.6 release should contain this for the -client variant:
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW \
CAP_SETGID CAP_SETUID CAP_SETPCAP \
CAP_SYS_CHROOT CAP_DAC_OVERRIDE
The -server variant is a bit more comprehensive:
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN\
CAP_NET_BIND_SERVICE CAP_NET_RAW \
CAP_SETGID CAP_SETUID CAP_SETPCAP \
CAP_SYS_CHROOT CAP_DAC_OVERRIDE \
CAP_AUDIT_WRITE
If the list of capabilities here is not what a user having issues have,
it would be a configuration error on the same level as using --user
foobar in the config and not having created this user account in
advance. It would fail starting up.
Since this was related to the error message below:
--user specified but lacking CAP_SETPCAP. Cannot retain CAP_NET_ADMIN.
Disabling data channel offload
This indicates that either the unit file in use is incorrect. Or that
there is a bug in the OpenVPN code dropping privileges. Since I have a
2.6 server running with DCO on RHEL-8.8, I have a feeling it's an
incorrect unit file. How that unit file ended up being wrong is hard
for me to say.
Runing this command should provide a reasonably readable list of
capabilities in use in the -server unit file:
# systemctl cat openvpn-server@.service \
| grep CapabilityBoundingSet= | tr ' ' '\n'
This can be specified further adding the config file in use in the line
above; or change -server with -client if it's a client config in play.
--
kind regards,
David Sommerseth
OpenVPN Inc
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] --user specified but lacking CAP_SETPCAP
On 26/10/2023 18:22, Gert Doering wrote:
Hi,
On Thu, Oct 26, 2023 at 10:04:18AM +0200, David Sommerseth wrote:
When starting OpenVPN via the openvpn-client@.service or
openvpn-server@.service systemd unit files, some capabilities are granted to
the the OpenVPN process may transition to, like the "openvpn" user.
CAP_SETPCAP and CAP_NET_ADMIN are two of those. The first one is actually
used to allow the OpenVPN process to keep setup certain capabilities as it
transitions to the user provided via the --user option. The CAP_NET_ADMIN
is, not surprisingly, used to setup the virtual network adapter (both tun
and ovpn-dco) and get network routes set up properly.
My guess in this thread here is that the systemd unit files used by
the original poster are not granting these two capabilities. Otherwise,
I fail to come up with a reason why OpenVPN would be able to change
user, but not retain CAP_NET_ADMIN.
Depends on how the distribution packaging has done anything additional
to the the OpenVPN upstream unit files. I know it works smooth in the
RHEL packaging.
Some distros still ship the "openvpn.service" havoc, which may be used -
this may also mess up things badly. Or users have their own variant
of a .service file which also doesn't account properly enough for
capabilities.
My point is: Ensure the proper OpenVPN package provided unit file is
used and use the openvpn-{client,server}@.service unit files. That's
the first step to make OpenVPN run properly. Unit files not provided by
the OpenVPN project may indeed be as bad as a home grown sys-v init
script which doesn't do all the needed things OpenVPN or the system
itself expects.
(But then, as you know I'm not a big fan of Systemd's overarching
"WE MUST DO THINGS NO MATTER THE COST" tendencies, with private /home,
private /tmp, getting in the way of getting work done in big ways)
That's an entirely different discussion. But if you actually started
using a modern Linux distribution which has fully embraced systemd
(RHEL, Fedora, Debian, Ubuntu, and their clones), there are seldom any
issues these days holding me back. Those times I'm "held back" is when
I do something which I then realise was stupid to do as a starter. One
of these "stupid things" is to cling to the "sys-v init script era way
of doing things". That approach will definitely cause pain.
The approaches used back in the days was suitable back then. Today's
environments have different requirements, as they are running in faster
changing, dynamic environments, with a completely different set of
security challenges.
This "systemd is bad by design" argument is more of an attitude problem
than an implementation issue. Okay, it's not perfect, but it's usually
far better than the alternatives for most use cases - for today's
challenges. And yes, there are some use cases, where systemd doesn't
fully work as well as it could and should. But for the vast majority of
Linux users, it's more than enough today.
The more I use it and the more I integrate code to work with it, the
easier my work ends up being - and my code can run with lesser
privileges out-of-the-box. I have also written code which enables
unprivileged users to turn on/off OpenVPN sessions at boot time in a
controlled manner. And that's by just using features which is available
today in systemd's toolbox; all it took was to add a policy
configuration and use the proper systemd APIs and that's it.
Systemd does have a broad reach on the system - because it is a *system
management service*, to ensure all the pieces and cogwheels in the
system is running correctly. For example, allowing selected users (or
groups of users) to manipulate the system in a controlled manner without
giving them full root access, and giving them access to only change what
they're supposed to change - that's a huge step forward in system
security and ensuring runtime stability. And it's available
out-of-the-box on a modern Linux distribution today.
But systemd is still not perfect, I agree. But the missing features and
lack of capabilities to give even more finer grained access are
improving the whole time. And my experience is, despite not being
perfect, that it still is far better than the alternatives.
In the end ... securing, hardening and ensuring a system runs stable,
that does have some user experience costs - just like it's been a huge
change in the Windows world too, going from the Win95 "you're all admins
by default" to all the limitations you'll face out-of-the-box in Win11.
I strongly encourage everyone to start OpenVPN, especially server
configurations, via the systemd unit files provided by the OpenVPN project.
This will attempt to reduce the privileges the OpenVPN process need
Re: [Openvpn-users] --user specified but lacking CAP_SETPCAP
On 24/10/2023 07:46, Peter Davis via Openvpn-users wrote: Hi, I see the same message. Linux capabilities? Should I install any package or...? Linux capabilities is a security feature provided by the kernel. For OpenVPN (or any other tunneling software, in fact), certain capabilities (such as CAP_NET_ADMIN) are required to modify network settings, changing network routes or creating and removing virtual network interfaces. Other capabilities gives other privileges on the system. The root user, by default, is granted all capabilities. Ordinary users on the system does not have any capabilities enabled by default. When starting OpenVPN via the openvpn-client@.service or openvpn-server@.service systemd unit files, some capabilities are granted to the the OpenVPN process may transition to, like the "openvpn" user. CAP_SETPCAP and CAP_NET_ADMIN are two of those. The first one is actually used to allow the OpenVPN process to keep setup certain capabilities as it transitions to the user provided via the --user option. The CAP_NET_ADMIN is, not surprisingly, used to setup the virtual network adapter (both tun and ovpn-dco) and get network routes set up properly. I strongly encourage everyone to start OpenVPN, especially server configurations, via the systemd unit files provided by the OpenVPN project. This will attempt to reduce the privileges the OpenVPN process needs to do its job. If you want an OpenVPN client setup running with the least privileges possible, you could have a look at the OpenVPN 3 Linux project [0]. This project attempts to go even further by splitting up the responsibility of the client connection (keeping the link to the server, encrypting/decrypting traffic) and the network configuration (creating the virtual interface, configuring VPN IP addresses, network routes and DNS) into separate components. The client connection component runs completely unprivileged while the network configuration component runs as a separate process without any root privileges, just CAP_NET_ADMIN and a few other selected ones (depending on the host configuration). This ensures the privileged network configuration process can only do a set of limited operations on the host, while the unprivileged client process can only pass traffic to and from the server, do the needed crypto operations on that traffic and send that traffic to/from the local virtual interface. [0] <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN 3 Linux v21 released
more easily in the logs. * Improvements: OpenVPN 3 Configuration Manager feature support tracking When upgrading OpenVPN 3 Linux versions, there might be situations where an older OpenVPN 3 Configuration Manager will be running but the openvpn3 command line tool is newer. When the command line tool attempts to access features in the Configuration Manager backed not available, it would result in an error and a poorer user experience. The code providing the glue interface for the calling side (openvpn3) has been extended with a feature/version mapping, so it can filter out operations not supported if the backend version is lacking certain functions. In most cases, the openvpn3 config commands will then continue to work as before, just not providing access to features available in newer back-ends. A similar functionality is planned for the Session Manager and is being considered for the OpenVPN 3 Python module. * Improvements: OpenVPN 3 Python module Configuration profiles from OpenVPN Access Server and some times OpenVPN Cloud Connexa will often contain "meta options", typically prefixed with "# OVPN_". The Python parser would not accept several of the deprecated meta options. The parser has now been extended to filter out those options not needed, used or supported by the OpenVPN 3 Core Library. * Improvements: Adjustments needed to satisfy Debian packaging Several minor issues has been done to satisfy the Debian package linter utility. There are still some issues left, some will not be possible to improve before Debian ships with a newer dbus-daemon - as we need functionality present in a newer release. The dbus-broker is also lacking a similar functionality currently. See the _credits_ section below for a bit more details on this. * Feature: Label/tag support for imported OpenVPN configuration profiles The OpenVPN 3 Configuration Manager and the openvpn3 config-manage and configs-list commands has been extended to with the ability to add one or more text labels to configuration profiles. At import time, the openvpn3 config-import command can also assign tags immediately. Users with many imported configuration profiles can more easily filter which configurations shown with the openvpn3 configs-list command. Other tools (openvpn3-as, openvpn-connector-setup) will also make use of this feature as they are being updated, to more easily understand where a configuration profile arrived from. * Feature: JSON formatted output with openvpn3 configs-list and config-dump The list of configurations can now be retrieved as a JSON formatted list via the openvpn3 configs-lists. The openvpn3 config-dump will normally dump the normal configuration using the standard OpenVPN configuration file format. The JSON format will contain all the additional meta options, overrides and access control lists not expressed in the standard file format. This format is the same format used internally for persistent configuration profiles. * Feature: Filtering options when retrieving available configurations The openvpn3 configs-list command has been extended with several filter arguments to only extract filters with a specific tag or owner as well as a simple prefix filter on the configuration name. The OpenVPN 3 Configuration Manager also exposes two new D-Bus methods to retrieve available configuration profiles based on a tag or owner. * Feature: Simple and verbose list formats in openvpn3 configs-list The default listing in openvpn3 configs-list has been simplified and will only list one configuration profile per line now. The more comprehensive list can be retrieved using the --verbose argument. The verbose list will also include configuration tags. Supported Linux distributions - - Debian 10, 11, 12 (amd64, arm64) - Red Hat Enterprise Linux 7 (x86_64) - Red Hat Enterprise Linux 8 and 9 (x86_64, aarch64) - Ubuntu 20.04 and 22.04, (amd64, arm64) The arm64 support on selected Debian and Ubuntu releases are considered tech-preview. We would like to get feedback from arm64 users how OpenVPN 3 Linux works here, then we can remove the tech-preview label for arm64. Installation and getting started instructions can be found here: <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> Credits --- This release has also received help from other contributors. Thank you to all of you! Antonio Quartulli Frank Lichtenheld Jeremy Fleischman mattjbyrd In addition, a "thanks in advance" goes to the work Marc Leeman is currently doing to provide a native Debian repository package for OpenVPN 3 Linux. Thanks a lot, Marc! That work can be followed here: <https://github.com/OpenVPN/openvpn3-linux/issues/193> --
Re: [Openvpn-users] How to set a fixed IP to a client?
On 03/09/2023 15:23, Jason Long via Openvpn-users wrote: Hello, As I said, I have some scenario and I want to learn more. Have you ordered any of the books you've been recommended? Have you read any of them? I would say you are pretty closed to getting banned from this mailing list by now. You ask so many questions WITHOUT doing your own homework, not reading documentation you've been pointed at. This has to stop now. This mailing list is NOT an OpenVPN focused Wikipedia search engine. If you REALLY want to learn more. START READING the documentation sources you've been pointed at numerous times over the last weeks. Have some respect to all of those who replies to you, commonly in their own spare time. Nobody here is obliged to reply. But they do so out of generosity. If you continue this nonsense much longer, you will just be ignored completely - or being taken off the mailing list. Your questions are not really that unique to your needs. Many of us responding here has been active in the OpenVPN community for over a decade; I doubt any of us has experienced anyone so insistent on ignoring documentation pointers as you have so far. Take this as strong warning. Enough is enough. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Using username/password authentication
On 01/09/2023 10:50, Jason Long wrote: On Wed, Aug 30, 2023 at 5:36 PM, Gert Doering [...snip...] I will. Good! (Since you yet again snip things out of context, I do sincerely hope this is about getting copies of the OpenVPN books). In the end, I want to know if it is possible to connect the server and the client without any key? Again, you seem to overlook very important details and think carefully before you ask. If you remove all keys, there will be no encryption. OpenVPN does not support that (any more). That would remove the P from VPN (P = Private). Instead of a Virtual Private Network, you would just end up with a Virtual Network where no data is protected. If this is what you want, then there are other alternatives (IP-IP tunnels, GRE tunnels, etc). The OpenVPN SERVER side MUST have a server.key (the private decryption key), server.crt (certificate, providing the identity and a public encryption key for the connecting clients) and the ca.crt (Certificate authority's certificate, used to verify the identity of issued certificates). The server also needs the dh.pem file, as that is crucial for the the Diffie-Hellman algorithm to be able to generate ephemeral session keys - which protects you from replay attacks; this is part of the PFS aspect (Perfect Forward Secrecy). The CLIENT side MUST have the ca.crt file, to verify the identity of the server. It MAY have client.crt (client identity and public encryption key) and client.key (private decryption key). If there are no client.key/crt configured; the server will not have an identity of the client when it connects -> thus username/password authentication is used so the server side can have an identity of the connecting client. Before you ask more questions. Please do your homework and do some googling and reading first. The terminologies used here are industry standard. -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Revoke a certificate and reuse it
On 26/08/2023 08:58, Bo Berglund wrote: I tried to use revocation on our company VPN when a few employees left and it seemed to work fine until a week later when it did not work anymore! At that point the VPN stopped working for*everyone*, noone was allowed in at all!!! What is important to beware of, the Certificate Revocation List (CRL, which tracks which certificates are revoked) contains an EXPIRY DATE. When OpenVPN is configured with CRL and the CRL expires - everyone connecting to the VPN server will be rejected - regardless. So when you configure CRL, ensure your CRL list gets renewed before its expiry date. Or set an expiry date far enough down the road where it is more likely you will have revoked other users before the next expiry. For smaller deployments, combining --client-config-dir with --ccd-exclusive might provide a good enough protection *IF* the CN (Common Name) field in each connecting client certificate is unique per client. -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Using username/password authentication
On 30/08/2023 07:45, Jason Long via Openvpn-users wrote: Hello, I configured OpenVPN to use the username and password for authentication, but I need to have the "ca.crt", "cert server.crt", "server.key" and "dh.pem" certificates. There are 2 sets of certificates and keys. * Server side: Uses ca.crt, server.crt, server.key and dh.pem * Client side: Uses ca.crt, client.crt and client.key The difference between these certificates and keys are very important to have a clear understanding of. Each certificate provides an identity of the server or client and should be unique per host and user. So, what's the advantage of using this authentication method when I still need to use these keys? Certificate based authentication is quite strong. And in many cases, that is more than enough. OpenVPN can also be configured to not use client certificates, in this case username/password authentication is mandatory. For such setups, the client side only needs the ca.crt (to verify the identity of the VPN server). Or you can combine certificate with username/password authentication. This can be used if you want to grant different access to the network(s) behind the VPN server depending on which device a user is connecting from. And there is another aspect as well. Some deployments let both gateway/routers connect to a VPN server as well as individual users. In this case, those gateway/router hosts will NOT use username/password - only certificates. While the individual end-users might do only username/password authentication. Which approach to use, depends entirely on your own networks need and the threat model you operate under. There is no "X is better than Y" scenario in this case; it depends entirely on your own security needs. -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Protocol options: explicit-exit-notify 1, protocol-flags cc-exit tls-ekm dyn-tls-crypt
On 29/08/2023 10:00, Bruno Tréguier via Openvpn-users wrote: Le 29/08/2023 à 09:02, Jason Long via Openvpn-users a écrit : Hello, Why in the OpenVPN log, I see the following line: Protocol options: explicit-exit-notify 1, protocol-flags cc-exit tls-ekm dyn-tls-crypt Thank you. Hello Jason, Sorry to interfere, and sorry also if I look a bit harsh, but this is getting a bit ridiculous, imho. +1 (from my point of view, this isn't harsh at all) Are you just going to browse through each and every line in your logs, or every unlikely situation you might encounter (like having to "unrevoke" a cert, a few days ago), and for each of them, ask someone on this list to take you by the hand? There's plenty of documentation out there, and you can also "use the source, Luke"... Help yourself, in every sense of the expression. Just to follow up on this ... documentation is found here: OpenVPN 2.5: <https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html> OpenVPN 2.6: <https://build.openvpn.net/man/openvpn-2.6/openvpn.8.html> In regards to the "protocol flags", you don't need to know anything about that. That is primarily useful for developers when debugging. If something is not found in the man page, just presume this is for developer debugging. If you want to know more about OpenVPN and how it works, start by getting a copy of these books: <https://www.packtpub.com/product/openvpn-cookbook-second-edition/9781786463128> <https://www.packtpub.com/product/mastering-openvpn/9781783553136> <https://www.packtpub.com/product/troubleshooting-openvpn/9781786461964> Those books are written by trusted OpenVPN community members, so buying these books supports them. -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to use ccd-exclusive statement?
On 16/08/2023 15:05, Jason Long via Openvpn-users wrote: On 16.08.23 12:23, Jason Long via Openvpn-users wrote: On Wed, Aug 16, 2023 at 06:35:01AM +, Jason Long wrote: [...snip...] Hello, I used "https://www.howtoforge.com/how-to-install-and-configure-openvpn-server-on-debian-10/"; tutorial to create my OpenVPN server. *sigh* Never use a random blog post on "how to do XYZ" when the project itself has its own set of documentation. No matter which project it is. I've read enough of those random "OpenVPN how-tos" over the last 15+ years and the vast majority of them are not up-to-date, tricks you into using insecure settings, being overly complicated or simply leads you to misery. Doing networking isn't really suitable as a "click-this-type-that" type of how-to, because you *really* need to understand how these things works and impacts your configuration and setup. This guides you through the most important steps and should be reasonably up-to-date (I spot a few things which could be improved, but shouldn't stop you from getting a functional tun based OpenVPN tunnel running). This documentation is provided by the official OpenVPN project and this project is responsible for keeping the documentation in reasonable shape. <https://community.openvpn.net/openvpn/wiki/GettingStartedwithOVPN> Read this, read the man page entries for options used and try to understand it. Read the pointers to the related documentation in that wiki page. Try to understand all the information provided there. Then you can ask questions and get sensible replies back. If you need more documentation, buy your own copy of the OpenVPN Cookbook by Jan Just Keijser. He is a well-trusted OpenVPN community member and knows this stuff very well. <https://www.packtpub.com/product/openvpn-cookbook-second-edition/9781786463128> > Gert tole me about the multihome statement and I added it. When Gert tells you to look at multihome, he has very good reasons for doing that (I know him too, he is also really trustworthy - in particular with networking and OpenVPN). But it ALSO means you should read the documentation for suggested options too. [...snip...] # cat /var/log/openvpn/virt1.log 2023-08-16 06:23:18 WARNING: --topology net30 support for server configs with IPv4 pools will be removed in a future release. Please migrate to --topology subnet as soon as possible. 2023-08-16 06:23:18 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. Those two lines tells you something important. You should fix this. I'm not going to tell you how; read the documentation. It is fully explained in the man page. [...snip...] 2023-08-16 06:23:18 Listening for incoming TCP connection on [AF_INET][undef]:2000 2023-08-16 06:23:18 TCPv4_SERVER link local (bound): [AF_INET][undef]:2000 2023-08-16 06:23:18 TCPv4_SERVER link remote: [AF_UNSPEC] I suspect this if from a server configuration (also an important detail to tell). And it tells you your VPN server is listening TCP port 2000. [...snip...] 2023-08-16 06:23:18 Initialization Sequence Completed This line means that the OpenVPN tunnel is up an running. So that means this tunnel instance is ready to see clients connecting to it. And finally. Learn yourself some mailing list netiquette. Inline replies and replies at the bottom are very fine. But keep the indenting marks (>) on the original text so it's easier to understand who is writing what and what you are responding to. A reasonably good summary of most common mailing list netiquette rules used in open source (and this is the official recommendation from an open source project; not a random blog post) <https://wiki.openstack.org/wiki/MailingListEtiquette> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN stopped working after upgrade from 2.5.6 to 2.6.3
On 13/08/2023 10:58, Martin wrote: On 2023-08-13 08:52, Gert Doering wrote: Run the client with --verb 3 or 4, have a close look at the logfile. If there is nothing obvious to you, show us the log. /var/log/openvpn/ is empty. Probably I need to use journalctl ? If the server runs 2.3.10 (which is, like, "ancient") then my guess is that the server also runs "cipher BF-CBC", which is not considere a secure cipher anymore - so 2.6 will not use that by default. In this case, try adding cipher BF-CBC compat-mode 2.3.10 Adding cipher=BF-CBC compat-mode=2.3.10 to the [vpn] section of /etc/NetworkManager/system-connections/MyConnection did not help. Maybe this should go in my .opvn file. Yes, this must go into the .ovpn file. And it might very much be that the NetworkManager-openvpn does not grok the compat-mode option - so you can't run it via NetworkManager. Now I try to use `openvpn` at the shell, and it complains about: Options error: Unrecognized option or missing or extra parameter(s) in u...@myconnection.ovpn:47: tls-remote (2.6.3) The --tls-remote option was removed in OpenVPN 2.4. <https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--tls-remoteStatus:RemovedinOpenVPNv2.4> to your client config (... and get company to upgrade to at least 2.5.x as soon as possible). Thanks for the headsup! I'll push them to do so as hard as I can :-) Tell your IT folks about this page: <https://community.openvpn.net/openvpn/wiki/SupportedVersions> Make some fuzz about the the "End of life" date for OpenVPN 2.3. No Linux/*BSD distribution which is valid (supported by the vendor) ships with OpenVPN 2.3. RHEL/CentOS 7 + RHEL-8 are those shipping with OpenVPN 2.4.12 (via Fedora EPEL) - which are the oldest releases I'm aware of. For RHEL/CentOS we also have separate Fedora Copr repos which ships both OpenVPN 2.5 [1] and OpenVPN 2.6 [2]. Even though OpenVPN 2.4 is from the OpenVPN community perspective EOL, I do support this release for the lifetime of RHEL-7 and RHEL-8 (I am the official Fedora/EPEL package manager for OpenVPN). When needed security fixes are required - the OpenVPN 2.4 releaes will be updated as needed. But only highly critical issues are being considered. [1] <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/> [2] <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release-2.6/> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Hardening an OpenVPN server
On 10/08/2023 21:44, Jason Long via Openvpn-users wrote: [...snip...] Hello, I see. Can you show me a good article about hardening an OpenVPN server on Linux? The best hardening trick you can do to OpenVPN: Use tls-crypt together with UDP With this setup, port scanners will not see anything - and all you get on your end is some log noise that TLS-unwrap failed (because the tls-crypt protection can't decrypt the scan). And OpenVPN will silently drop the packet. If you use a different port than 1194 - you might not see so much noise even. Secondly, ensure you use AES-GCM algoritums (default with OpenVPN 2.6). Ensure your CA, server and clients use certificates with at least RSA 4096 keys or ECC based keys. And don't reuse certificates for more clients or servers. That's the main attack vector for OpenVPN. These two steps avoid random external users to attempt inspecting your OpenVPN server for weaknesses and it ensures only devices with key pairs issued by you can connect. And the strength of the AES algorithm coupled with the RSA/ECC based keys makes it harder to dump tunnelled traffic and decrypting that dump. To further control users/devices connecting, you can look into using --client-config-dir together with --ccd-exclusive. This will require the server side to have a file named the same as the "CN" field in the client certificate. This way you can also block devices/users which should have their access revoked very easily (remove the file, or just add "disable" as a line in CCD file). The rest of the hardening you can do is actually more pretty basic and standard network and host hardening, which is out-of-scope for OpenVPN itself. OpenVPN is basically just a "virtual network cable" between the VPN server and client. How you treat the traffic coming out or going into that cable is up to the host this "cable" is "plugged" into. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] A question about the VPN providers
On 31.07.23 21:42, Jason Long via Openvpn-users wrote: Hello,Is it possible to set public IP addresses from different countries on one NIC? This is a bit unclear. Generally, you assign multiple IP addresses to a single NIC (physical), but it gets quickly very messy to route that correctly. For virtual NICs (such as tun or dco interfaces), the remote end of that IP address will need to assign multiple IP addresses; OpenVPN does not support that. And it will be the remote end which needs to know what to do with these IP addresses and route them correctly on the server side. TL;DR: For physical local NICs, it *might* be possible with lots of extra work. For VPN services, multiple IP addresses on a single tun/dco interface is generally not possible. But you can run multiple VPN connections in parallel with separate tun/dco interfaces and route traffic (per IP range) accordingly. VPN provider companies provide VPN service with IP addresses of different countries. Do they have a separate server in that country? Yes. Or have they just set IP addresses from different countries on the same server? No. You can achieve such a per-country routing setup via the CloudConnexa service provided by OpenVPN Inc. But you need to setup a (VM) host in each country you want to send traffic via, and then configure them in CloudConnexa as egress points for specific IP ranges or even domain suffixes. When you connect your own client end to CloudConnexa, your Internet traffic will be automatically routed via the egress points you have defined in you CloudConnexa setup. But I am not aware of any other VPN provider having this capability. That said, I also don't have a too good overview of all of the VPN providers in this market; it's quite a wild west market segment (especially on the consumer VPN service side). -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] openvpn 2.6.5 RPM from Fedora Copr and data-ciphers patch
On 19/06/2023 14:45, Gert Doering wrote: Hi, On Mon, Jun 19, 2023 at 02:26:01PM +0200, Giulio wrote: I found this difference in the service script and I was wondering whether I should use it "as is" or maybe rebuild the RPM w/o that patch in order to let openvpn use its default crypto settings. I think this should go. It's likely a leftover from the dawn of times (like, 2.4 era). 2.6 will not advertise or use BF-CBC by itself, defaulting to the AES-GCM + CHACHA (if available) ciphers, negotiating between client and server what is available. As in: with 2.5 and 2.6, --cipher and --data-ciphers usually should not be touched, except if needed to be compatible with pre-2.4 clients that default to BF-CBC and can not negotiate something else. So the history of this hack is related to changing the default ciphers in Fedora 27 and newer: <https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN> A slight change was added recently as it broke the very newest Fedora releases and RHEL-9, and it was a simple fix to unbreak things. But somewhere far down on my todo list is an item to dig into if this is really needed with OpenVPN 2.6. I just haven't had enough to improve this. But I'm open to apply patches and pay attention to related discussions. As long as we're sure we don't break existing setups, I'm fine to also remove this for Fedora 38+ and RHEL 9+ (which are the distros shipping 2.6 through mainline Fedora repos). Fedora Copr repo for OpenVPN 2.6 will be kept in sync as well. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN 3 Linux v20 released
tributions - - Debian 10 (amd64, arm64) - Debian 11 (amd64, arm64) - Fedora 36, 37 and 38 (x86_64, aarch64, s390x) - Red Hat Enterprise Linux 7 (x86_64) - Red Hat Enterprise Linux 8 and 9 (x86_64, aarch64) - Ubuntu 18.04, 20.04 and 22.04, (amd64, arm64) The arm64 support on selected Debian and Ubuntu releases are considered tech-preview. We would like to get feedback from arm64 users how OpenVPN 3 Linux works here, then we can remove the tech-preview label for arm64. The non-LTS Ubuntu releases has been unlisted. The OpenVPN 3 Linux project will primarily focus the LTS releases. The non-LTS releases will still get builds, but they will no go through the same kind of testing before releases. Those builds will also not necessarily arrive at the same time as the builds for LTS releases. Installation and getting started instructions can be found here: <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> Credits --- Since this is the first stable release, it's appropriate to give some credits to people who have contributed in various ways to this project so far. A huge thanks goes to: Antonio Quartulli Arne Schwabe Ben Yanke David Schneider dangerfish96 fldu Frank Lichtenheld Frans Klaver Heiko Hund Jagadeesh Kotra Johan Draaisma John Eismeier Kevin Lindsay Lev Stipakov Mykola Stolyarenko Raphael Mader Romain Loutrel Samuli Seppänen In addition comes all those who have tested OpenVPN 3 Linux and provided feedback through various channels through all these releases. You have all been important in ensuring this project has evolved and matured. I'm sorry I don't have a proper list of all you, but you would also deserve to be mentioned. -- kind regards, David Sommerseth OpenVPN Inc Source tarballs --- * OpenVPN 3 Linux v20 <https://swupdate.openvpn.net/community/releases/openvpn3-linux-20.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-20.tar.xz.asc> SHA256 Checksums -- git references git repositories: <https://codeberg.org/OpenVPN/openvpn3-linux> (Primary) <https://gitlab.com/openvpn/openvpn3-linux> (mirror) <https://github.com/OpenVPN/openvpn3-linux> (mirror) git tag: v20 git commit: e7531f45d3743bfe58223a6b56794aa8bba01ba9 Changes from v19_beta to v20--- --- David Sommerseth (47): Coding style update build/clang++: Fix build issues with clang++14 log: Add default initialising of LogEvent members log: Extend LogEvent with group/category parsing from strings log: Extend LogEvent with str() method ovpn3cli/log: Use the new LogEvent::str() method log: Adding Log::Journald::Parser and related classes ovpn3cli: New command - openvpn3-admin journal copyright: Use SPDX license tags core: Update to OpenVPN 3 Core library v3.7.2 Add .git-blame-ignore-revs with instructions cli/session-manage: Make --resume and --restart run in background log: Ensure extracted systemd-journald fields have correct length docs/man: Fix missing backslash in Makefile.am build: Unbreak non-systemd based builds again dbus: Add AUTH_PENDING related constants client: Implement support for CR_TEXT pending authentication tests: Extend requires-queue tests with ClientAttentionGroup::CHALLENGE_AUTH_PENDING common/dbus: Migrate g_variant_get() to GLibUtils::ExtractValue<>() selinux: Allow openvpn3_client_t to use syslog copyright: Fix typo in a license tag ovpn3cli: User credential input error handling input with session-start cli: Improve behaviour with incorrect PK passphrase or CONN_FAILED netcfg: Exit early if systemd-resolved cannot be reached common: Add support for comment fields in SingleCommand arg parser build: Add a check for the libselinux library ovpn3cli/admin: Add new init-config command log: Don't hard-code --journald in auto-start service docs: Update openvpn3-autoload documentation copyright: Update copyright years build: Ensure OPENVPN3_STATEDIR is properly set ovpn3cli/admin: Check chown/chmod return codes in init-config ovpn3cli/admin: Make init-config check SELinux status first docs: Clean up the "SEE ALSO" sections in some base man pages log: Filter out UNDEFINED LogGroup and LogCategory log/jourald: Don't provide strings for LogCategory/LogGroup::UNDEFINED ovpn3cli/admin: Make init-config also check for configs subdir ovpn3cli/admin: Clean up incorrect wording in init-config man: Updating openvpn3-linux.7
Re: [Openvpn-users] easy-rsa in docker
On 16/03/2023 01:22, Arnold Somogyi wrote: Hello, I am building a docker image with easy-rsa based on the alpine Docker image. When I run the ./easyrsa init-pki command then I get the following error: Easy-RSA error: easyrsa_random failed Easy-RSA error: secure_session - random_session '' EasyRSA Version Information Version:   3.1.2 Generated:  Fri Jan 13 15:49:32 CST 2023 SSL Lib: Git Commit:  354c20d82bdc5db364e197aa1290e84b46abe487 Source Repo: https://github.com/OpenVPN/easy-rsa <https://github.com/OpenVPN/easy-rsa> Host: 3.1.2 | nix | Linux | /bin/bash I think that I get this error because there is almost nothing installed in this linux image and the required tools/commands are missing. Even though I honestly don't see the value of dockerizing Easy-RSA, I gave it a quick test run using 'podman run -it alpine:latest'. I had to install the openssl package, and the 'easyrsa init-pki' kicked off without issues. But I'm really curious why you find it valuable to dockerize Easy-RSA. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to check if OpenVPN server is working properly?
On 25/02/2023 16:36, Bo Berglund wrote: On Thu, 23 Feb 2023 18:34:11 +0100, David Sommerseth wrote: Yes, you can issue new certificates using *the same* private and public keys (essentially re-using the CSR). This will issue a new certificate with a new expiry date. Since the certificate and CA is the same, it just works as before. Are most files used in this context NOT stamped with an expiration date? I.e. does only .crt files have expiration times? That is correct. The expiration time is part of the certificate only. In that case I would only need to handle the ca.crt for expiration, right? Correct. Only a new CA certificate needs to be distributed, as long as the CA private key stays the same. A CA certificate can be renewed in similar ways as client and server certs; but it must be distributed to all clients. [...snip...] Is ca.crt the only one I need to worry about? You have 1 client/server certificate and 1 CA certificate in the simplest setups. All of them have expiration times. Normally a CA has between 10-20 years expiration time. Server certs typically have 2-4 years, at least in OpenVPN context. Client certs even shorter. But YOU as the CA admin decides the policy you want for your certificates. If you want 10 years for everyone, you can have that. When the client ovpn files are created the content comes from these in the easy-rsa/keys dir: ca.crt ta.key clientcommonname.crt clientcommonname.3des.key ca.crt and clientcommonname.crt are the ones you need to beware of. These files are also created but not used in the ovpn files: clientcommonname.key clientcommonname.csr The .csr file is the Certificate Signing Request, which is kinda like an unsigned certificate. The CA will take this request, you review the content of the meta data and modify it if that is needed, then sign it with the CA private key. That gives the certificate as output (.crt file). For the .key file, I see you have two variants. .3des.key sounds like a password protected key, while the plain .key file is unencrypted. The former will make OpenVPN ask for a private key passphrase, the second one will just start the OpenVPN process without asking for that passphrase. Which of them to use in your configs depends on the security policy you want for your VPN connection. And and the data from the files are placed inside sections in the client ovpn files: ca.crt ta.key clientcommonname.crt clientcommonname.3des.key Question: - Is any part of the ovpn files affected if I update the main ca.crt file? No. Only the --ca option is affected. I.e. does an ovpn file depend on having been created after the ca.crt has gotten its expiration extended? No. Then I would have to recreate all of them and update the clients too, right? You only need to do that if you replace the CA signing key (the private CA key) and need to issue a completely new CA certificate (and don't start playing with cross signing, and such things; that's quite a bit more complicated). You will also need to do similar changes if the client private key is update. That would affect only the --key and --cert. When renewing a client certificate only the --cert needs to be changed. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to check if OpenVPN server is working properly?
On 24/02/2023 00:20, Bo Berglund wrote:
[...snip...]
I'll let others follow up on the easy-rsa usage.
This renewed certificate uses the original entity private key.
This expiration business, does it apply only to crt files?
With all other files remaining the same over time?
Yes. The certificate files (".crt") are basically a public key with
some meta data and a signature done by the CA. This signature is there
to ensure the meta data has not been modified after the certificate was
issued.
The meta data is information about who the certificate belongs to
(Certificate Subject), validity (start/end dates; hereby the expiry
dates), who signed the certificate and the intended usage for this
public key.
The signature in a certificate can be validated by having a copy of the
public key of the CA, hence you have the CA certificate distributed.
By keeping the private key the same, the public key (which is derived
from the private key) stays the same. And when keeping the meta data
the same - with the exception of the expiry time, it is basically just
the validity and CA signature which changes in the certificate.
In that context, you can basically say that the Certificate Signing
Request (the ".csr" file) is the public key + some meta data which the
CA signs, which then has the certificate (".crt") as the output. During
the signing process, the CA verified the suggested meta data. But the
CA may decide to modify this information before signing it. The only
thing the CA cannot change, is the public key attached to the CSR.
--
kind regards,
David Sommerseth
OpenVPN Inc
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to check if OpenVPN server is working properly?
On 23/02/2023 17:43, Bo Berglund wrote: On Thu, 23 Feb 2023 15:36:48 +, tincantech via Openvpn-users wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, --- Original Message --- On Thursday, February 23rd, 2023 at 15:10, Bo Berglund wrote: When I first try (and fail) to connect then go in via the other server to read the log I find this: 217.31.190.108:63723 TLS: Initial packet from [AF_INET]217.31.190.108:63723, sid=863c9ad5 e9b05ce9 217.31.190.108:63723 VERIFY ERROR: depth=0, error=CRL has expired: C=US, ST=TX, L=Austin, O=Companyname, OU=IT, CN=BosseB_AGI, name=BosseB_AGI, emailAddress=*** Your CRL (certificate revocation list) has expired. If you use Easy-rsa (https://github.com/OpenVPN/easy-rsa) then you can build a new CRL with: easyrsa gen-crl This builds a new CRL which is valid for 180 days. You can configure the validity period with option --days: easyrsa --days=365 gen-crl You can also get advanced warning of expiring certificates with: easyrsa show-expire The default is 90 days but that can also be configured via option --days Hope that helps. Most definitely! Thank you very much! Some time ago (Jan 22, 2023) I added the crl handling to the server to lock out logins of people that have stopped working here. That part worked fine. But I had no idea that this was a time limited block and that after a month *everyone* would be locked out even if they were not added to the list. I have now commented out the crl line on the two server conf files and restarted both services and now connection is working again! You can consider alternative approaches. The --crl-verify can be pointed at a directory instead, and then give the keyword 'dir' as the second argument. Then you can create an empty file in that directory with the serial number of the certificate which was revoked. Or you can use --client-config-dir together with --ccd-exclusive. Only clients which has a file in the --client-config-dir directory with the same name as an escaped certificate CN value will be allowed to connect. If the certificate has "CN = John Doe", the filename would need to be "John_Doe". You can also explicitly disable clients this way with client-config-dir by adding the option "disable" inside such a CCD config file. Then you have a few possibilities via the --tls-verify and --client-connect script hooks as well. Meanwhile I checked my server certs and they expire in 2027, so this was not really an expiration issue at all! Questions: Can I extend the expiration time of my server and the cleints too before actual expiration such that this will not happen on Oct 24, 2027? Yes, you can issue new certificates using *the same* private and public keys (essentially re-using the CSR). This will issue a new certificate with a new expiry date. Since the certificate and CA is the same, it just works as before. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to check if OpenVPN server is working properly?
On 23/02/2023 16:10, Bo Berglund wrote: On Thu, 23 Feb 2023 13:25:46 +0100, Gert Doering wrote: Hi, On Thu, Feb 23, 2023 at 09:04:13AM +0100, Bo Berglund wrote: But now when I connect on 1194 or 1195 from a remote location nothing happens whereas on 1198 or 1199 I get instant connection. Basically there's two reasons why "nothing" could happen - one is "packets never make it to the server" (Firewall/NAT box being confused), the other is "something cert has expired, so the server does not want to talk to you". For debugging the OpenVPN server, you need to find out where it logs to - usually the OpenVPN server log is pretty clear on "I do not like this client because..." The logs are in /etc/openvpn/log so was simple to locate... When I first try (and fail) to connect then go in via the other server to read the log I find this: 217.31.190.108:63723 TLS: Initial packet from [AF_INET]217.31.190.108:63723, sid=863c9ad5 e9b05ce9 217.31.190.108:63723 VERIFY ERROR: depth=0, error=CRL has expired: C=US, ST=TX, L=Austin, O=Companyname, OU=IT, CN=BosseB_AGI, name=BosseB_AGI, emailAddress=*** 217.31.190.108:63723 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed 217.31.190.108:63723 TLS_ERROR: BIO read tls_read_plaintext error 217.31.190.108:63723 TLS Error: TLS object -> incoming plaintext read error 217.31.190.108:63723 TLS Error: TLS handshake failed 217.31.190.108:63723 SIGUSR1[soft,tls-error] received, client-instance restarting So it seems like some client cert has expired... Question: How can I update the cert (which cert) to extend the lifetime? For some other certs, I have such a simple check in a script: openssl x509 -noout -checkend $((40*24*3600)) -in $CERT_FILE if [ $? -eq 1 ]; then # Certificate is expiring echo "** EXPIRING ** Certificate dates (current): " openssl x509 -noout -dates -in $CERF_FILE fi This will check if the certificate will expire in less than 40 days. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to check if OpenVPN server is working properly?
On 23/02/2023 09:04, Bo Berglund wrote: I am running an Ubuntu 20.04.5 server on a remote LAN for hosting the OpenVPN service. This has been working for many years, but yesterday something happened that broke the remote connections and I am trying to figure out what is the problem. Luckily I have set up a secondary OpenVPN server too on the LAN for maintenance connections when the Linux main server needs to be updated. So I am still able to access the LAN via that VPN. With that I have have connected using SSH to the server command line to check the state and I have also rebooted the main OpenVPN server to no avail. On the server side the status of the two services report this using the status command (only showing the full web service but both look the same): Status? -- $ sudo systemctl status openvpn-server@serverweb ? openvpn-server@serverweb.service - OpenVPN service for serverweb Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2023-02-22 11:57:51 CST; 13h ago Docs: man:openvpn(8) https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage https://community.openvpn.net/openvpn/wiki/HOWTO Main PID: 927 (openvpn) Status: "Initialization Sequence Completed" Tasks: 1 (limit: 1066) Memory: 2.1M CGroup: /system.slice/system-openvpn\x2dserver.slice/openvpn-server@serverweb.service +-927 /usr/sbin/openvpn --status /run/openvpn-server/status-serverweb.log --status-version 2 --suppress-timestamps -> Feb 22 11:57:48 vpnserver systemd[1]: Starting OpenVPN service for serverweb... Feb 22 11:57:51 vpnserver systemd[1]: Started OpenVPN service for serverweb. --- Is the OpenVpn service OK? --- $ sudo journalctl -u openvpn-server@serverweb -- Logs begin at Tue 2023-02-07 22:40:22 CST, end at Thu 2023-02-23 01:33:48 CST. -- Feb 19 14:43:12 vpnserver systemd[1]: Starting OpenVPN service for serverweb... Feb 19 14:43:14 vpnserver systemd[1]: Started OpenVPN service for serverweb. Feb 22 11:56:51 vpnserver systemd[1]: Stopping OpenVPN service for serverweb... Feb 22 11:56:53 vpnserver systemd[1]: openvpn-server@serverweb.service: Succeeded. Feb 22 11:56:53 vpnserver systemd[1]: Stopped OpenVPN service for serverweb. -- Reboot -- Feb 22 11:57:48 vpnserver systemd[1]: Starting OpenVPN service for serverweb... Feb 22 11:57:51 vpnserver systemd[1]: Started OpenVPN service for serverweb. --- I would have expected more log details here if there are attempts connecting to the server. Do you have any --log or --log-append options in your configurations? That will override the systemd journal logging. And in that case you need to check the designated log files instead. If your current configurations have one of these options, I would recommend to remove them. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN 2.5.9 released
On 20/02/2023 04:43, Stella Ashburne wrote: For your information, I shall use version 2.6.0 on Microsoft Windows 11 and version 2.5.9 on Debian 11.6.0. The Linux DCO package for Debian is available only for the Testing branch (a.k.a. the future Debian 12). I noticed that the official repositories of Fedora 37 do not have the Linux DCO package as well. Fedora/Fedora EPEL package maintainer for OpenVPN here. I have no hope for getting the DCO module into mainstream Fedora repositories before the ovpn kernel module hits the mainstream Linux kernel. This is a packaging policy by the Fedora Project. There might be some exceptions, but they are really few and more special than what I would expect OpenVPN's situation to be. What *does* exist is a Fedora Copr repository which I am maintaining as well, where this kernel module is available. yum copr enable dsommers/openvpn3 yum install kmod-ovpn-dco The reasons it is in this repository is that the OpenVPN 3 Linux project was the first Linux implementation with ovpn-dco support. To avoid complicating things further for existing users of this package, I'm probably going to keep the ovpn-dco kernel module in this repository. Further information can be found here: <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN 2.6.0 released
On 25/01/2023 20:50, Frank Lichtenheld wrote: [...snip...] On Red Hat derivatives we recommend using the Fedora Copr repository. <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/> A slight update here. The repo above will be preserved for OpenVPN 2.5 releases. A new repository for OpenVPN 2.6 has been published: <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release-2.6/> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] 2.6rc2 client & DCO: down script fails since tun0 is already gone
On 19/01/2023 10:22, Ralf Hildebrandt via Openvpn-users wrote: A new day, a new observation! $ sudo openvpn --config charite-hildeb.ovpn --up /etc/openvpn/update-resolv-conf --down /etc/openvpn/update-resolv-conf ... connection is being established, and now I'm sending ctrl-c to openvpn on the client ... 2023-01-19 10:11:40 Initialization Sequence Completed ^C 2023-01-19 10:14:14 event_wait : Interrupted system call (fd=-1,code=4) 2023-01-19 10:14:14 SIGTERM received, sending exit notification to peer 2023-01-19 10:14:14 SENT CONTROL [openvpn.charite.de]: 'EXIT' (status=1) 2023-01-19 10:14:15 net_route_v4_del: 10.27.0.0/16 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 net_route_v4_del: 10.28.0.0/15 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 net_route_v4_del: 10.32.0.0/11 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 net_route_v4_del: 172.16.0.0/15 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 net_route_v4_del: 192.168.192.0/18 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 net_route_v4_del: 141.42.0.0/16 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 net_route_v4_del: 193.175.72.0/24 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 net_route_v4_del: 193.175.74.0/23 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 net_route_v4_del: 193.175.174.0/26 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 net_route_v4_del: 172.19.252.0/27 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 net_route_v4_del: 194.94.4.0/23 via 172.29.0.1 dev [NULL] table 0 metric 200 2023-01-19 10:14:15 Closing DCO interface 2023-01-19 10:14:15 net_addr_v4_del: 172.29.0.2 dev tun0 2023-01-19 10:14:15 net_iface_del: delete tun0 2023-01-19 10:14:15 /etc/openvpn/update-resolv-conf tun0 1500 0 172.29.0.2 255.255.248.0 init Failed to resolve interface "tun0": No such device 2023-01-19 10:14:15 WARNING: Failed running command (--up/--down): external program exited with error status: 1 2023-01-19 10:14:15 Exiting due to fatal error Question here: Does this matter? Is the tun0 interface taken down too early? Should I even care? The man page says: 8. --down Executed after TCP/UDP and TUN/TAP close. So this is probably as expected. You could use --route-pre-down, to run scripts requiring the VPN interface to be available. -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN 3 Linux client - v19 beta released
release will be one of the last beta releases or a stable release depends on what bugs and issues are discovered in this release and what kind of code changes are needed to complete the outstanding issues we want resolved for the stable release. Supported Linux distributions - - Debian 10 (amd64, arm64) - Debian 11 (amd64, arm64) - Fedora 35 and 36 (x86_64, aarch64, s390x) - Red Hat Enterprise Linux 7 (x86_64) - Red Hat Enterprise Linux 8 and 9 (x86_64, aarch64) - Ubuntu 18.04, 20.04, 21.10 and 22.04 (amd64, arm64) Both Fedora 37 and Ubuntu 22.10 will come in the near future as well, they are currently not made available yet. The arm64 support on selected Debian and Ubuntu releases are currently considered a tech-preview. We would like to get feedback from arm64 users how OpenVPN 3 Linux works here, then we can remove the tech-preview label for arm64. -- kind regards, David Sommerseth OpenVPN Inc Source tarballs --- * OpenVPN 3 Linux v18 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-19_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-19_beta.tar.xz.asc> SHA256 Checksums -- git references git repositories: <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> <https://codeberg.org/OpenVPN/openvpn3-linux> git tag: v19_beta git commit: 33da965fa4151a05f95f385f00f338fa028471a2 Changes from v18_beta to v19_beta -- David Sommerseth (74): tests: Improve MachineIDTest::get_systemd_api test build: Split up proxy-netcfg into a manager and device compilation unit core: Update to latest OpenVPN 3 Core Library 3.7 development shell: Fix proposing more options to --config shell completion shell: Fix trailing spaces in bash-completion build: Generate C compatible header file dbus: Add missing #include in glibutils.hpp log: Move LogTag into its own compilation unit log: Extend LogTag to enable/disable the tag mark encapsulation log: Extend LogTag with copy constructor log: Add new helper classes for log meta data log: Implement the new meta data log handling log: Extend LogMetaDataValue to process LogTag objects log: Extend LogMetaData with GetMetaDataRecords() method log: Use LogTag in Logger class instead of std::string common: Allow setting default filename in Configuration::File ctor common: Extend Configuration::File with Get/Set for more data types log: Re-implement configuration state saving log: Switch to GLibUtils::ExtractValue in LogEvent log: Implement LogTag prefix configuration setting log: Extend LogEvent with LogGroup/Category string extraction log: Add support for native systemd-journald logging log: Implement systemd-journald support in openvpn3-service-logger log: Split logwritter.hpp into its own compilation unit log: Split out StreamLogWriter and ColourStreamWriter log: Split out SyslogWriter to its own compilation unit log: Split out JournaldWriter to its own compilation unit log: Final change of the logwriter.hpp split-up refactoring log: Extend LogWriter API to provide backend info log: Extend net.openvpn.v3.log interface with log_method property cli/log: Provide information about logging method in use cli/log: Add admin --enable-log-prefix config setting log: Fix memory corruption with syslog/openlog() log: Rework initial opening information in logger service common: Extend Configuration::File with GetFilename() log: Extend state/config file option coverage log/logger: Simplify exclusive option check log/logger: Rework configuration/state loading log/logger: Extend with D-Bus property for config_file common: Add missing include files in cmdparser-exceptions.hpp cli/log: Add new options for logger config file management logger: Enable --journald as default log method build: Don't use space in PACKAGE_NAME docs/man: Add missing --auth-req option in openvpn3 session-auth docs: Added GitHub pull-request template log: Avoid halting logger startup on missing log-service.json dbus: Make bus_name and interface protected members in DBusProxy dbus/proxy: Check if property proxy is configured dbus/connection: Add extra connection tests in DBus constructors common: Add PlatformInfo API client: Send platform OS/distro peer information to server client: Simplify IV_GUI_VER string utils: Fix incorrect string concat in get_guiversion() tests/unit: Handle PlatformInfo::DBus error gracefully py
Re: [Openvpn-users] Checking server and client certificates expiration?
On 28/09/2022 16:40, Joe Patterson wrote: The general form of what you want to do is: openssl x509 -in file.crt -noout -text | grep 'Not After' An easier way; this checks if the certificate expires within the next 30 days: $ openssl x509 -noout -checkend $((30*24*3600)) -in file.crt || echo "NEED RENEWAL" -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Commanding remote client to reconnect following server reboot?
If at all possible see if you can add ipv6 on the server and then see if you can use ipv6 on the various client sites with the problems. That should avoid the NAT problems. The use of IPv6 SHOULD not have a mandatory extra charge as it is NORMAL internet access. Provided that the ISP does not also charge extra for IPV6. If so, tunnelbroker.net can work reasonably okay. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Commanding remote client to reconnect following server reboot?
On 06/09/2022 16:48, Bo Berglund wrote: On Tue, 6 Sep 2022 16:00:20 +0200, David Sommerseth wrote: On 06/09/2022 15:42, Bo Berglund wrote: On Tue, 6 Sep 2022 15:23:29 +0200, David Sommerseth wrote: On 06/09/2022 10:14, Bo Berglund wrote: 2. Find a way to push the blocking of persist-tun via a ccd command for this client only. But it might not be possible if the persisted tun is in operation already when the client reaches the server? Unfortunately, this is not possible to push. This is only possible to set in the local configuration file. Long story short: It's related to when this option is parsed; which is before it starts to connect to the remote server. Figured as much! It stands to reason that a client function executed *before* there is an actual connection to the server cannot be changed by a push with a different argument. Thanks for the clarification! So I have to tell the person at the remote location to bring the router back when he travels to Sweden next so I can modify the config file. When doing that, I'd recommend you to ensure you can SSH into this router without needing the VPN. Use SSH keys and possibly restrict the IP ranges to networks you know you can connect from (typically ISP subnets and such like). But doing it without VPN is hard when the ISP is not providing a public IP address to the connected device... Use services like nsupdate.info ... or you could have a script running regularly reporting it's IP address to a web server of yours; then you would have the IP in your web server logs. You mentioned this was an ASUS RT-51UC ... I see that the ASUS RT-51U model is supported by OpenWRT[0], but I don't know what the difference between the UC and U models might be. If you're not running OpenWRT, I would recommend you to take that approach. OpenVPN is available here as well as a functional SSH server and iptables. [0] <https://openwrt.org/toh/asus/rt-ac51u> When I configured the router 4 months or so back I forgot to enable Telnet (SSH is not available on the RT-AC51U router firmware)... I would not enable Telnet that's like asking for trouble. Plain text auth ... My plan is to make it possible to access the router via the tunnel IP from here using the terminal interface. In that case I could modify the config files on the system via the connected tunnel in the future. But I must enable these items (both Telnet and Setup page) first in the GUI of course, so for a later day... I really do recommend you to kick out the ASUS firmware in favor of OpenWRT. I mean, even lower-end hardware from other vendors have ssh as an option to telnet these days. And it's not the device's fault; it's the firmware. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Commanding remote client to reconnect following server reboot?
On 06/09/2022 15:42, Bo Berglund wrote: On Tue, 6 Sep 2022 15:23:29 +0200, David Sommerseth wrote: On 06/09/2022 10:14, Bo Berglund wrote: 2. Find a way to push the blocking of persist-tun via a ccd command for this client only. But it might not be possible if the persisted tun is in operation already when the client reaches the server? Unfortunately, this is not possible to push. This is only possible to set in the local configuration file. Long story short: It's related to when this option is parsed; which is before it starts to connect to the remote server. Figured as much! It stands to reason that a client function executed *before* there is an actual connection to the server cannot be changed by a push with a different argument. Thanks for the clarification! So I have to tell the person at the remote location to bring the router back when he travels to Sweden next so I can modify the config file. When doing that, I'd recommend you to ensure you can SSH into this router without needing the VPN. Use SSH keys and possibly restrict the IP ranges to networks you know you can connect from (typically ISP subnets and such like). Having a backdoor like this is not necessarily too insecure, especially not when the IP range is restricted and the authentication is sane and solid (SSH keys; not passwords). And it can save you a lot of troubles later on. You mentioned this was an ASUS RT-51UC ... I see that the ASUS RT-51U model is supported by OpenWRT[0], but I don't know what the difference between the UC and U models might be. If you're not running OpenWRT, I would recommend you to take that approach. OpenVPN is available here as well as a functional SSH server and iptables. [0] <https://openwrt.org/toh/asus/rt-ac51u> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Commanding remote client to reconnect following server reboot?
On 06/09/2022 10:14, Bo Berglund wrote: 2. Find a way to push the blocking of persist-tun via a ccd command for this client only. But it might not be possible if the persisted tun is in operation already when the client reaches the server? Unfortunately, this is not possible to push. This is only possible to set in the local configuration file. Long story short: It's related to when this option is parsed; which is before it starts to connect to the remote server. -- kind regards, David Sommerseth OpenVPN Inc ___ 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
On 30/06/2022 12:37, Connor Edwards via Openvpn-users wrote: Hello, We are looking into using auth-gen-token on our new VPN server which will be using version 2.5.5. However, we've noticed that the behaviour of auth-gen-token has changed and our clients are being kicked off every hour which corresponds with the renegotiation interval (3600 secs). >127.0.0.1:57748 <http://127.0.0.1:57748> --auth-token-gen: auth-token from client expired On our existing VPN server which uses 2.4.7, clients are able to stay connected up to 12 hours with an auth token and this is not affected by the renegotiation interval. In 2.5.0 an additional auth token check was added that seems to limit the token lifetime to as long as the renegotiation interval, but we don't understand what this is for. It's a long while since I dug into the auth-gen-token code paths, but I have some vague memories we did quite some enhancements on that feature in OpenVPN 2.5. I recommend you to have a look at the man page, that should be up-to-date. In particular the 'lifetime' argument would be relevant for you. <https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html> Which version of OpenVPN are your clients running? -- kind regards, David Sommerseth OpenVPN Inc ___ 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 22/06/2022 22:03, Bo Berglund wrote: On Wed, 22 Jun 2022 15:58:35 +0200, David Sommerseth wrote: [...snip...] I see you get a recommendation to remove '--suppress-timestamp'. That is only useful if you decide to use --log. If you let the journal do that job, it will already provide the timestamps for you. And if you also have rsyslog installed too, it will pick up journal events and put these log entries to the configured log files - which will include timestamps. Generally speaking, consider the --log option only to be useful on systems without a system logger available. So if I simply remove the log entry in the conf file and restart openvpn services I will get the log into Journalctl including timestamps? Yes, correct! This seems like a modification I could do remotely without risking the system getting shut down? I mean commenting out the log setting in the conf file... Absolutely, removing the --log option is normally a safe operation. If you have SSH access to the box outside of the VPN, it is also safe to do a 'systemctl restart' of your openvpn-server@.service units. -- kind regards, David Sommerseth OpenVPN Inc ___ 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 20/06/2022 00:10, Nathan Stratton Treadway wrote: On Sun, Jun 19, 2022 at 23:03:15 +0200, Bo Berglund wrote: I get this: dpkg -L openvpn | grep systemd.*openv /lib/systemd/system-generators/openvpn-generator /lib/systemd/system/openvpn.service /lib/systemd/system/openvpn@.service /usr/lib/systemd/system/openvpn-client@.service /usr/lib/systemd/system/openvpn-server@.service Oh, that's interesting. We need to look into this more carefully, might be either that the package manager overlooked this detail or that we're lacking a "systemd service directory override" in our source code which Debian packaging would need. For whatever reason Debian has, they deviated from the rest of the Linux world insisting on putting service files under /lib/systemd ... where most others (all distros I know of) uses /usr/lib/systemd. But that's a Debian artifact - which Ubuntu picks up. -- kind regards, David Sommerseth OpenVPN Inc ___ 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 18/06/2022 23:20, Bo Berglund wrote: On Sat, 18 Jun 2022 20:01:10 +, tincantech via Openvpn-users wrote: If you want your log-file to contain time-stamps then edit the file: /lib/systemd/system/openvpn-server@.service remove '--supress-timestamps' I cannot find such a file... Well, you now know the solution. All you need do is find where your Ubuntu hides systemd, So I searched from / instead: sudo find / -name "openvpn-server*" /usr/lib/systemd/system/openvpn-server@.service ^^ This is the proper service file being packaged. Even though, as this is from a Debian package, I would have expected it under /lib/systemd/system. /sys/fs/cgroup/devices/system.slice/ All these files under /sys are on a pseudo file system, not a real file system. They represent data stored in the kernel. The /sys/fs/cgroup part is about resource management on your system. Generally, you don't need to care much about these areas unless you dig into system management through cgroup. /etc/systemd/system/multi-user.target.wants/openvpn-server@server.service /etc/systemd/system/multi-user.target.wants/openvpn-server@serverlocal.service These are the result of 'systemctl enable' commands. These are the files matching and I don't know which two are the real files to edit... I looked in the file: /usr/lib/systemd/system/openvpn-server@.service and it contains this: [Service} ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf So here I can remove the --suppress-timestamps argument, but does it cover BOTH of my two service instances?? As mentioned in a prior mail today; unless you insist on using --log, leave the --supress-timestamps alone :) A unit file which ends with a '@' means it is to be considered a "template". So when you call 'systemctl start openvpn-server@server.service', the %i is replaced with what comes between the '@' and '.service'. I assume I have to restart openvpn service to make it "take": sudo systemctl restart openvpn-server@server sudo systemctl restart openvpn-server@serverlocal Correct. Or is it: sudo systemctl restart openvpn-server There exists no 'openvpn-server.service' unit, so this will fail. Only the "template" version exists, which needs a "value" ... openvpn-server@value.service. -- kind regards, David Sommerseth OpenVPN Inc ___ 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 18/06/2022 10:26, Bo Berglund wrote:
On Wed, 15 Jun 2022 22:58:46 +0200, David Sommerseth
wrote:
[...snip...]
But will journalctl work independently of the openvpn log option settings, like
verbosity etc?
I have this now in the two instance conf files:
log /etc/openvpn/log/openvpn.log
verb 4
mute 10
and:
log /etc/openvpn/log/ovpn_local.log
verb 4
mute 10
No, it will not work independently. When the --log option is missing,
all logging goes to stdout ("terminal") and that's the output the
journald picks up. The --verb and --mute options will work as expected.
I see you get a recommendation to remove '--suppress-timestamp'. That
is only useful if you decide to use --log. If you let the journal do
that job, it will already provide the timestamps for you. And if you
also have rsyslog installed too, it will pick up journal events and put
these log entries to the configured log files - which will include
timestamps.
Generally speaking, consider the --log option only to be useful on
systems without a system logger available.
[...snip...]
This system was created back in 2016 or thereabouts on an Ubuntu Server system
and has been migrated through the Ubuntu versions since then. Now at Ubuntu
20.04.4 LTS.
So the way of launching the service has also changed ove the years, I only a few
months back moved to using the /etc/openvpn/server and /etc/openvpn/client
directories to store the conf files and modified the startup etc to suit the new
way of operation.
The way I did that:
1) sudo systemctl stop openvpn
sudo systemctl stop openvpn@server.service
sudo systemctl stop openvpn@serverlocal.service
2) sudo systemctl disable openvpn@server.service
sudo systemctl disable openvpn@serverlocal.service
sudo systemctl disable openvpn.service
3) Edit /etc/default/openvpn and comment out the AUTOSTART line
4) sudo mkdir /etc/openvpn/client
sudo mkdir /etc/openvpn/server
5) sudo mv /etc/openvpn/server*.conf /etc/openvpn/server/
6) sudo systemctl enable --now openvpn-server@server
sudo systemctl enable --now openvpn-server@serverlocal
It seemed to work, but you might have spotted a flaw in this migration, so
please advice how to actually disable/mask the offending services.
I would consider running:
systemctl mask openvpn.service openvpn@.service
And here's a another systemd trick ... with upstart/sysv init scripts,
you had the 'service' helper.
# service openvpn start
Which is essentially has this semantic: 'service SUBJECT VERB'. This
was changed with systemctl, so you now have: 'systemctl VERB SUBJECTS'
where you can list more SUBJECTS and perform the same VERB operation on
them all. So your step 1) can be done like this:
# systemctl stop \
openvpn openvpn@server.service openvpn@serverlocal.service
--
kind regards,
David Sommerseth
OpenVPN Inc
___
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 15/06/2022 16:48, Bo Berglund wrote: On Wed, 15 Jun 2022 14:00:52 +, tincantech via Openvpn-users wrote: I have scanned the documentation for OpenVPN: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ But I do not find a setting that will swichh ON timetsmps in log lines. There are these related items: --suppress-timestamps It seems to disallow timestam ps which is exactly what my installation does without this setting... --machine-readable-output I really do not understand the description here. It seems like this would use some kind of special formatting of the timestamp, but does not control the fact that we want timestamps in the first place... time_ascii and time_unix Seems to only be related to the execution of the --client-connect script. I have looked in vain for a --enable-timestamps settings. The only log related items in my conf file are: log /etc/openvpn/log/openvpn.log verb 4 mute 10 It would help a lot if I could see the timestamps when debugging problems I would recommend you to install rsyslog the package if you want to be more advanced. These do the log-to-disk in plain-text far more efficient than the primitive OpenVPN logging mechanism. And it removes some CPU cycles from the OpenVPN process doing that. So in other words: On a systemd enabled system, using the "log" option is not optimal. Generally speaking, on systemd enabled systems you have the journalctl which is the main interface to read log entries. The basic output looks quite similar to any common log file. But you can also use the '-o' output to get far more details, including better machine readable outputs. $ journalctl -o help short short-full short-iso short-iso-precise short-precise short-monotonic short-unix verbose export json json-pretty json-sse cat with-unit As you have explained, you run multiple OpenVPN configurations (server.conf, serverlocal.conf). With the journalctl, you can then filter on these configs alone: # journalctl -u openvpn-server@server.service And then you can narrow in to a smaller time window # journalctl -b(Since last boot) # jorunalctl -b-2 (Since the last 2 boots) # journalctl --since -10m (Last 10 minutes) # journalctl --since "2022-06-15 10:00" # journalctl --since yesterday It also supports --until as well. If you add -f, you get the "tail -f" behavior. When using the more verbose output formats (like verbose, json/json-pretty, export), you see there are more meta data fields. You can also filter on those: # journalctl _PID=2741081 # journalctl _COMM=openvpn + SYSLOG_FACILITY=3 And all of these options can be combined, including -u and -o. And you can also filter on fields not listed in the output. I also mentioned rsyslog initially, as that is also able to add filters and log specific events into dedicated log files. It also has a native journal support via the imjournal module, where rsyslog can also be configured to process the json formatted data and apply filters based on the structured journal data. And a final note in regards to the systemd unit files. Please disable/mask the use of openvpn@*.service and openvpn.service unit files. When you only use the openvpn-client@.service and openvpn-server@.client, you will have an environment which will be easier to debug and troubleshoot. I mention this as I saw the "openvpn@server.service" unit was listed as "failed". -- kind regards, David Sommerseth OpenVPN Inc -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, this is a setting in the openvpn systemd unit file. The setting to remove is --suppress-timestamps from the 'ExecStart=' line. Sorry, I forgot to say that my server is an Ubuntu 20.04.4 server with openvpn version: OpenVPN 2.4.7 x86_64-pc-linux-gnu Where can I find the openvpn systemd unit file to edit? The command: sudo ls -l /etc/systemd/system/ Does not show any openvpn related files... This is what I can get from systemctl: $ sudo systemctl | grep openvpn openvpn-server@server.service loaded active running OpenVPN service for server openvpn-server@serverlocal.service loaded active running OpenVPN service for serverlocal openvpn.service loaded active exitedOpenVPN service ? openvpn@server.service loaded failed failedOpenVPN connection to server system-openvpn.sliceloaded active active system-openvpn.slice system-openvpn\x2dserver.slice loaded active active system-openvpn\x2dserver.slice Why do I want this? --- I am trying to set up a back-channel for an ovpn connection for a remote router. It connects fine and the clients on that router can navigate the Internet just fine via VPN too. But I also want to be able to configure the router i
[Openvpn-users] OpenVPN 3 Linux client - v18 beta released
tdown phase of a VPN session, where it would typically wait for statistics data to be collected it, could print various errors about local variables being unavilable. This has now been improved. Note about future releases -- OpenVPN 3 Linux is now in a stabilization phase. We aim to have a few more releases tagged as 'beta' before the first real stable release, where the focus are primarily bug fixes and improving user experiences through the interfaces already available. This does mean that OpenVPN 3 Linux is generally considered quite stable and can be tested more actively in production environments. Supported Linux distributions - - Debian 10 (amd64, arm64) - Debian 11 (amd64, arm64) - Fedora 35, 36 and Rawhide (x86_64, aarch64, s390x) - Red Hat Enterprise Linux 7 (x86_64) - Red Hat Enterprise Linux 8 and 9 (x86_64, aarch64) - Ubuntu 18.04, 20.04, 21.10 and 22.04 (amd64, arm64) The arm64 support on selected Debian and Ubuntu releases are considered a tech-preview. -- kind regards, David Sommerseth OpenVPN Inc Source tarballs --- * OpenVPN 3 Linux v18 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-18_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-18_beta.tar.xz.asc> SHA256 Checksums -- 205ace04986a28ddf27b27b26b57132c9ba83eda32bfb482576aeed456ab3941 openvpn3-linux-18_beta.tar.xz f1a822be0e0fec7b06bb1ddaf687fa7b87793e51bacf7e08324d2533636f2208 openvpn3-linux-18_beta.tar.xz.asc git references git repositories: <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> git tag: v18_beta git commit: 5c47318f719aa04606219c2f0913f5d63d3ee999 Changes from v17_beta to v18_beta -- David Schneider (1): docs: Fix incorrect doc paths in net.openvpn.v3.sessions docs David Sommerseth (79): core-extension: Revamp the whole OptionListJSON class core-extension: Remove the ProfileMergeJSON class ovpn3cli: Improve session-start tip with URL auth python: Add support for enable-legacy-algorithms in config parser python: Extend openvpn3.Configuration class with GetConfigName() python: Extend openvpn3.Configuration class with SetOwnershipTransfer() python: Extend openvpn3-as with systemd integration python: Extend openvpn3-as with --owner log/proxy: Switch over from RCPtr to std::shared_ptr log/proxy: Add LogServiceProxyException exception class log/proxy: Add LogServiceProxy::AttachInterface() helper function configmgr: Switch over to LogServiceProxy::AttachInterface() sessionmgr: Switch over to LogServiceProxy::AttachInterface() netcfg: Switch over to LogServiceProxy::AttachInterface() client: Switch over to LogServiceProxy::AttachInterface() addons/aws: Switch over to LogServiceProxy::AttachInterface() python: Add --auth-nocache to ConfigParser's ignore list python: Fix spurious errors during disconnect in openvpn2 common: Add error handling to Configuration::File::Save() dbus: Fix various warnings in connection.hpp dbus: Fix/improve header inclusion in signal.hpp client: Add missing include dbus-log.hpp in backend-signal.hpp log: Fix several spelling errors in comments in logwriter.hpp log: Remove the openvpn namespace and improve includes in dbus-log.hpp build: Rework distro/systemd EXTRA_DIST file list python: Allow --auth-retry to be passed on tests: Fix incorrect namespace closing in machine-id test build: Disallow AWS addon builds without OpenSSL build: Remove hard-coded gio-unix-2.0 include paths common: Fix missing header include for UID/GID lookups dbus: Remove the openvpn namespace from DBus related classes dbus: Extend DBus class with GetUniqueBusName() dbus: Ensure the D-Bus connection is valid dbus: Make path.hpp a separate compilation unit dbus: Free some GError structures in DBusProxy calls log: Refactor service.hpp to be a separate compilation unit log: Replace RC/RCPtr based smart pointers with standard C++ log: Make dbus-log.hpp a separate compilation unit log: Don't log or proxy empty log events dbus: Extend with DBusSignalProducer::set_object_path() client: Extend with BackendSignals::SetSessionPath() client: Extend RegistrationConfirmation D-Bus method with session path client: Extend BackendSignals with GetSessionPath() method client: Provide related session path as a property log: Implement net.openvpn.v3.log.AssignSession client: Provide session path details to log service log: Extend D-Bus
Re: [Openvpn-users] Can I script access of an OpenVPN client on/off?
On 18/05/2022 11:59, Aleksandar Ivanisevic wrote: On 16. May 2022, at 19:49, David Sommerseth <mailto:open...@sf.lists.topphemmelig.net>> wrote: I still recommend you to have a look at OpenVPN Cloud and the split-tunnel support based on domain names feature. How does that work? Do you use your own DNS and then resolve to a private range that you then NAT to the real destination? I don't recall exactly the implementation right now, but that sounds familiar. You do need to use the VPN provided DNS on the client for this to work. -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Can I script access of an OpenVPN client on/off?
On 14/05/2022 00:32, Bo Berglund wrote:
On Fri, 13 May 2022 17:26:16 +0200, David Sommerseth
wrote:
What kind of firmware is on the device? Does it have a web UI? That
could probably be simpler than an SSH login.
I found out that the router in this case is too simple (low end) so it does not
have ssh options. It has the standard ASUS router GUI and supports OpenVPN
client connections so it can be set up like I want for the original purpose.
But it does not lend itself to any "fancy" functions.
And the Merlin open-source f/w is not supported on this hardware.
So I will drop the search now and be content with the basic functions.
I still recommend you to have a look at OpenVPN Cloud and the
split-tunnel support based on domain names feature. With OpenVPN Cloud,
you only deploy clients. And for routers, like your ASUS router, you
download a configuration file generated by OpenVPN Cloud and upload it
to the router itself. That's all you need to do on that router.
But you do need to configure your egress ("output") points for your
tunnel, though.
If the ASUS OpenVPN integration is too stupid to import an OpenVPN
configuration file, then it gets more tricky indeed. But in most cases,
it could work.
--
kind regards,
David Sommerseth
OpenVPN Inc
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Can I script access of an OpenVPN client on/off?
On 12/05/2022 18:35, Bo Berglund wrote: [...snip...] The proper way is probably to be able to ssh into the router and issue some ovpn stop command at the proper place to disconnect the client. And of course the opposite to connect it. What is finally needed is for the tunnel to come down for local streaming and be up for remote streaming. I will look at what is possible with the router itself, it is an ASUS RT-AC51U latest hardware model. From the command line one could presumably shut down and start the service given the proper parameters. What kind of firmware is on the device? Does it have a web UI? That could probably be simpler than an SSH login. That said ... You could make use of OpenVPN Cloud for this use case. OpenVPN Cloud supports "domain based routing". So you can have VPN connectors (read: VPN clients) in several regions. In the Cloud setup you define that visiting .se domains should go via the VPN connector having a Swedish IP address. And say, netflix.com should via a VPN connector with a US IP address. You can also define a default VPN connector for all the other egress. Or you can have a split-tunnel setup where only defined routes goes via a VPN connector. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Request .deb package of OpenVPN 2.5.6
On 24/03/2022 02:50, Stella Ashburne wrote: [...snip...] The Fedora build you point at uses the standard upstream distro repository build system. And a similar infrastructure is also used for the Fedora Copr builds. Btw. openvpn-2.5.6 builds are already in all the Fedora pipes. From January 1, 2022 to February 28, 2022, whenever I installed openvpn-2.5.5-1.fc35, openvpn-2.5.5-2.fc35 and openvpn-2.5.5-3.fc35 onto Fedora 35, there were warnings about "globs" not being supported; nevertheless I continued with the installation of OpenVPN. If you had checked the latest "rpm -q --changelog openvpn" you would find: * Thu Jan 27 2022 David Sommerseth - 2.5.5-3 - Fix systemd related scriptlet error (#1887984) That number in parentheses points at the Red Hat Bugzilla ticket: <https://bugzilla.redhat.com/show_bug.cgi?id=1887984> [...snip...] The .deb package repositories hosted on <http://build.openvpn.net/debian/openvpn/> is a different story, as that's based on infrastructure managed by the OpenVPN project. This infrastructure has been through some massive overhaul, and it seems Samuli hit some dark corners there causing issues with the builds for this repository. According to Gert Doering, Samuli's problems with building a .deb package of OpenVPN were caused by: (sic) I guess that Samuli's build machine (which is a VM in some AWS VPC) has issues unrelated to Debian or OpenVPN - but fixing takes time, so won't always be possible "right the same day". > Anyway, it would be good if Samuli could elaborate the types of "esoteric technical problems" that prevented him from building packages of OpenVPN for Debian distro. It's related to a massive change of build infrastructure which has been going on for some months already, and some corner cases from the ported build code from the old setup failed. The details here is not really relevant for the OpenVPN user community. Feel free to join our IRC channels and ask about details there, if you feel the need to understand this in detail. The whole infrastructure has grown a lot since the community got a real kickstart back in 2009-ish, where it really picked up pace and become more of a real open source community. The issues we've stumbled across are related to lots of things which has changed and grown over many years, and sometimes a proper overhaul is needed - and that may break some unexpected things along the way. The more important detail: This is being worked on and will be resolved. [...snip...] The Fedora Copr repos is somewhat similar to Ubuntu PPA. These repositories does not have the same strict version upgrade policy, but also does not carry the same types of stability guarantees. The project provided apt repository is also a best-effort repository. There are no guarantees it won't break, but we try to fix things as soon as possible. On the other hand, the official OpenVPN 2.x releases from the project are generally very stable. But it does not go through the same set of testing which many distributions does before shipping it. I hope this could clarify a bit of the differences and align some of the expectations better. Yes, your clarification helps a lot for folks like us. Could someone upload such clarification to the OpenVPN's wiki for Debian packages please? Sure, I'll put it on my todo list. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Request .deb package of OpenVPN 2.5.6
On 23/03/2022 12:51, Stella Ashburne wrote: Hi Samuli Sent: Wednesday, March 23, 2022 at 6:04 PM From: "Samuli Seppänen" To: "Stella Ashburne" , openvpn-users@lists.sourceforge.net Subject: Re: [Openvpn-users] Request .deb package of OpenVPN 2.5.6 There are esoteric technical reasons for that. Would you like to elaborate what those "esoteric technical reasons" are with regards to building the .deb package? Are the "esoteric technical reasons" confined to Debian only? I ask because David Sommerseth produced the openvpn package, version 2.5.5 and now 2.5.6, for Fedora 35, such as openvpn-2.5.6-1.fc35 (URL: https://packages.fedoraproject.org/pkgs/openvpn/openvpn/fedora-35-updates.html) So you got my attention ;-) Both as an OpenVPN Inc employee, working on the open source projects, and as the official Fedora openvpn package maintainer. The Fedora build you point at uses the standard upstream distro repository build system. And a similar infrastructure is also used for the Fedora Copr builds. Btw. openvpn-2.5.6 builds are already in all the Fedora pipes. The .deb package repositories hosted on <http://build.openvpn.net/debian/openvpn/> is a different story, as that's based on infrastructure managed by the OpenVPN project. This infrastructure has been through some massive overhaul, and it seems Samuli hit some dark corners there causing issues with the builds for this repository. That said, comparing upstream Fedora 3x repos with the OpenVPN project provided repos is not really a fair reference point. The Fedora repositories are similar to the upstream Debian repositories - but version wise, they are probably much closer to Fedora EPEL repositories. And in regards to upstream distribution repositories, the package maintainers there ensure that the OpenVPN versions distributed from there are up-to-date in regards to important bug and security fixes. They are typically back-ported from newer versions. The version number in these repositories may not be completely accurate. But very seldom are features back-ported. This is due to repository polices, where major version updates are not allowed and minor updates are attempted kept at a minimum for the distribution - to ensure the package stays stable and have a predictable behavior. The Fedora Copr repos is somewhat similar to Ubuntu PPA. These repositories does not have the same strict version upgrade policy, but also does not carry the same types of stability guarantees. The project provided apt repository is also a best-effort repository. There are no guarantees it won't break, but we try to fix things as soon as possible. On the other hand, the official OpenVPN 2.x releases from the project are generally very stable. But it does not go through the same set of testing which many distributions does before shipping it. I hope this could clarify a bit of the differences and align some of the expectations better. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Check how openvpn was installed on Ubuntu?
On 07/02/2022 13:46, Bo Berglund wrote: I have an OpenVPN server running on an Ubuntu Server 18.04 LTS and it is due for release-upgrade. The installation of OpenVPN was originally done back in 2017 on the 16.04 LTS version. Now I do not remember *how* it was installed, if I just used apt install openvpn like I do nowadays or if I first added the OpenVPN repositories to apt... Any customizations of apt sources will be overwritten bya a release-upgrade so I need to figure this out before the upgrade can be done. I check 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 library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.10 So it seems rather old, but if I do the same check in another newer Ubuntu 20.04.3 I have then I get this: $ openvpn --version OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 This is the same 2.4.7 version on both but the dates differ a lot... Hi, So the upstream version number (2.4.7 in this case) might not be the code you are actually running. You need to check the .deb package instead, like `dpkg -s openvpn`. On a Debian 11 box I use for testing I see the "Version" line has "2.5.1-3", and the "-3" part is important. For all the LTS distros, the OpenVPN packages are not upgraded during the lifetime of the distro itself. But the package maintainer backports fixes from newer versions to the version in the distro repository, and this is what the "-3" part indicates. The package maintainer does his utmost to ensure these updates does not break a running system. But you may have added an additional repository, where you pick the packages from our own apt repository. This is provided by the OpenVPN community project, but we don't provide the same guarantees as the distro maintainer does. However, you get much newer releases quicker - which in most cases works very well. I am not able to understand nor see where openvpn-aptrepo.list comes from. I would suggest you to compare that with information found here: <https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos> In general, old configuration files will usually work just fine. But if you are in doubt, install a test machine (or use a Docker container, or similar - for smoke testing the config) where you install the wanted OpenVPN version and copy over your production configs. Then just try to run the openvpn command directly on the configuration files. If it doesn't complain about anything in the configuration file itself, it will in most cases work just fine. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Start OpenVPN client in background, it's possible?
On 02/02/2022 16:25, Bo Berglund wrote: 2) The config file needs to*not* be password protected because I do not know how one can set up a decryption password for an ovpn file and pass it to systemd. I am using this connection system on a RaspberryPi device and it works very well, but I created a specific client ovpn file*without* the client password for it. The connection is protected by the certificates anyway. It's a log time since we implemented the systemd-ask-password support in OpenVPN. But it should actually ask for credentials or passwords if needed automatically during boot, if that is required. This should be automatically handled by systemd when starting the OpenVPN session. Basically, OpenVPN asks systemd to ask the user for the required information. The systemd-ask-password implementation does that on the available consoles and provides the response back to OpenVPN. If no console is available at that point, it should be possible to complete this later by manually running systemd-tty-ask-password-agent in a console. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to modify old OpenVPN installation to new way of operation?
On 19/01/2022 19:27, Bo Berglund wrote: On Wed, 19 Jan 2022 16:24:20 +0100, David Sommerseth wrote: What are these *.slice items??? The best answer is found in: man 5 systemd.slice There is a lot of man pages for systemd, and it is all kept up-to-date and answers almost everything you need to know about managing a system with systemd. Thanks, I guess it is managed by openvpn/systemd then. TL;DR version of man page: Slices are essentially resource management control via cgroup, which systemd handles all by itself. We have not bothered that much with profiling OpenVPN to be restrained to a certain resource usage. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to modify old OpenVPN installation to new way of operation?
On 18/01/2022 15:21, Bo Berglund wrote: On Tue, 18 Jan 2022 10:58:02 +0100, David Sommerseth wrote: On 17/01/2022 23:37, Bo Berglund wrote: [..snip...] I have two server instances running with and without Internet routing from conf files server.conf and serverlocal.conf. I want to change them to the new handling. So to switch over I assume could do as follows: 1) sudo systemctl stop openvpn 2) Edit /etc/default/openvpn and comment out the AUTOSTART= line 3) sudo mkdir /etc/openvpn/client ; sudo mkdir /etc/openvpn/server 4) sudo mv /etc/openvpn/server*.conf /etc/openvpn/server/ 5) sudo systemctl enable openvpn-server@server 6) sudo systemctl enable openvpn-server@serverlocal 7) sudo systemctl start openvpn-server@server 8) sudo systemctl start openvpn-server@serverlocal Would this be all that is needed? This looks reasonable. You can combine the enable/start operations in one go, for simplicity: systemctl enable --now openvpn-server@server The '--now' argument will run the 'start' command for you. Or is there some other cleanup I need to perform in order to get it done properly? Some other service I need to stop? Yes, you need to ensure that 'openvpn.service' and any 'openvpn@*.service' have been stopped. This is easy to check by running: systemctl status openvpn.service openvpn@*.service You can also ensure they are all stopped and disabled in a similar way as enabling services: systemctl disable --now openvpn.service openvpn@*.service OK, so I have now run through the commands I listed. After all is said and done I now have this (and the client connects fine): sudo systemctl | grep openvpn openvpn-server@server.service loaded active running OpenVPN service for server openvpn-server@serverlocal.service loaded active running OpenVPN service for serverlocal system-openvpn.sliceloaded active active system-openvpn.slice system-openvpn\x2dserver.slice loaded active active system-openvpn\x2dserver.slice What are these *.slice items??? The best answer is found in: man 5 systemd.slice There is a lot of man pages for systemd, and it is all kept up-to-date and answers almost everything you need to know about managing a system with systemd. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to modify old OpenVPN installation to new way of operation?
On 17/01/2022 23:37, Bo Berglund wrote: [..snip...] I have two server instances running with and without Internet routing from conf files server.conf and serverlocal.conf. I want to change them to the new handling. So to switch over I assume could do as follows: 1) sudo systemctl stop openvpn 2) Edit /etc/default/openvpn and comment out the AUTOSTART= line 3) sudo mkdir /etc/openvpn/client ; sudo mkdir /etc/openvpn/server 4) sudo mv /etc/openvpn/server*.conf /etc/openvpn/server/ 5) sudo systemctl enable openvpn-server@server 6) sudo systemctl enable openvpn-server@serverlocal 7) sudo systemctl start openvpn-server@server 8) sudo systemctl start openvpn-server@serverlocal Would this be all that is needed? This looks reasonable. You can combine the enable/start operations in one go, for simplicity: systemctl enable --now openvpn-server@server The '--now' argument will run the 'start' command for you. Or is there some other cleanup I need to perform in order to get it done properly? Some other service I need to stop? Yes, you need to ensure that 'openvpn.service' and any 'openvpn@*.service' have been stopped. This is easy to check by running: systemctl status openvpn.service openvpn@*.service You can also ensure they are all stopped and disabled in a similar way as enabling services: systemctl disable --now openvpn.service openvpn@*.service -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN 3 Linux client - v17 beta released
compatible with the development stack on this distribution. Both the OpenVPN 3 Core library and the Linux client has been modified to be able to build successfully. * Distro: Python 3.6 or newer is now required As of this release, any Linux distribution with Python older than version 3.6 is no longer supported. This removes the support for Debian 9. Supported Linux distributions - - Debian 10 (amd64, arm64) - Debian 11 (amd64, arm64) - CentOS 7 (x86_64) - CentOS 8 (x86_64, aarch64) - Fedora 34, 35 and Rawhide (x86_64, aarch64, s390x) - Red Hat Enterprise Linux 7 (x86_64) - Red Hat Enterprise Linux 8 (x86_64, aarch64) - Ubuntu 18.04, 20.04 and 21.04 (amd64, arm64) - Ubuntu 21.10 (amd64, arm64) is available for testing The arm64 support on selected Debian and Ubuntu releases are currently considered a tech-preview. -- kind regards, David Sommerseth OpenVPN Inc Source tarballs --- * OpenVPN 3 Linux v17 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-17_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-17_beta.tar.xz.asc> SHA256 Checksums -- 9eba02c67d3e5606ee8d02e0d60032009d3f97a0564d42c91ff154fb06b47e61 openvpn3-linux-17_beta.tar.xz b1a3928074eed09ebde6ad03b51551883abd357fa2dd5f61bdb07285bf5b50d1 openvpn3-linux-17_beta.tar.xz.asc git references git repositories: <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> git tag: v17_beta git commit: 079e9da7f66f5cca59cf80ba8c548f0dedd433db Changes from v16 to v17 ------- David Sommerseth (61): cli/session-start: Add --background support log: Improve LogEvent formatting log: Use the LogEvent GVariant generator in LogSender log: Extend the LogSender::Log() with duplicate check client: Simplify BackendSignals::Log() client: Remove some not needed log duplication client: Don't switch to Reconnecting state on initial connect python: Remove aenum workaround for Python 3.5 or older python: Remove spurious import line from openvpn2 python: Ignore --mute-replay-warnings option python: Add --insecure-certs option to openvpn3-as git: Switch to https for submodules python: Extend ConfigParser to understand --tls-crypt-v2 python: Fix a few errors in ConfigParser sessionmgr: Fix incorrect LogEvent proxy format core-ext: Properly parse options which may be used more times common: Extend MachineID to support systemd API for machine-id python: Fix incorrect parsing of filenames with spaces client: Add support for static-challenge configurations common: Extend command line parser with alias command support ovpn3cli: Depreacte config-show in favour of config-dump core: Update to latest OpenVPN 3 Core library build: Avoid GNUism in Makefile.am configmgr/client: Remove support for forcing AES-CBC cipher configmgr: Extend with session ownership transfer flag ovpn3cli: Extend config-acl to support --transfer-owner-session sessionmgr: Respect the configuration profile transfer-ownership flag client: Parse the --verb option to set log-level client: Add support for 'log-level' override sessionmgr: Retrieve the client log-level for the session log-level sessionmgr: Proxy log-level settings in session to backend tests: Extend config-export-json-test to process files too core-ext: Fix incorrect handling of --static-challenge in JSON export systemd: Fix incorrect access to mainloop object in status handler systemd: Fix incorrect sd_notify() behaviour systemd: Add support for profiles needing user credentials common/shell: Fix bash-completion for options with optional arguments common: Don't throw an exception in ParsedArgs::GetValueLen() ovn3cli/session: Extend session-manage to set session log-level core: Update to latest OpenVPN 3 Core library dbus: Change the proxy call timeout to 5 seconds log: Don't throw exception on invalid LogGroup/LogCategory client: Use the proper index value to retrieve the --verb value client: Change default log-level to 3 systemd: Do not change the log level at startup by default client: Extend StatusEvent with stringstream formatting control cli/session: Extend the session module with session-auth cli/session: Extend session-auth to also list URL based auth cli/session: Implement completing on-going auth in session-auth cli/session: Add shell-completion support for session-auth cli/session: Remove "Auth URL" from sessions-list
Re: [Openvpn-users] Linux client DNS resolver - does it even work?
On 15/11/2021 14:31, Gert Doering wrote: however I wonder if NM (at least in Fedora) has a problem with re-uping connection after system resumed from sleep. Well, that is most easily tested, no?:-) (As far as I understand, NM is "sleep aware", and will stop the OpenVPN session before sleep and resume afterwards - which brings certain kinds of problems, but fixes other kinds) Unfortunately, NM is even "more clever" than that. If the main link goes down, it stops all VPN connections as part of that. NM does not trust OpenVPN is able to recover the VPN connection on its own, even if gateways changes. -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Linux client DNS resolver - does it even work?
On 10/11/2021 23:18, lejeczek via Openvpn-users wrote: Hi guys. I have, I'd like to think a "regular" server setup where clients from Windowze and Macs do get name resolution work apparently very well, whereas Linux client - all clients do use almost identical config - seems pretty broken. Linux client seems to take notice of what server pushes, namely DNS server & domains but, really nothing comes out of it. It cannot be some limitation of Linuxes - I'm on latest Fedora - I must be missing something and what that might be, if you care to suggest, I'll appreciate. many thanks, L. Have you tried OpenVPN 3 Linux? That does DNS seutp out-of-the-box. With the Fedora builds it also integrates natively with systemd-resolved. <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN 3 Linux client - v16 beta released
e servers could need a more specific cipher to be set. This is believed not to be needed in OpenVPN 3, so instead we just ignore these options if found. * Build: Code has been made reproducible It should now be possible to rebuild the code with using the same host or image and get the exact same binary output. The only supported distribution not capable of being reproducible at the moment is the CentOS 7 builds. Supported Linux distributions: - Debian 9 (amd64) << !! Last update for this release !! - Debian 10 (amd64, arm64) - Debian 11 (amd64, arm64) - CentOS 7 (x86_64) - CentOS 8 (x86_64, aarch64) - Fedora 33, 34 and Rawhide (x86_64, aarch64, s390x) - Red Hat Enterprise Linux 7 (x86_64) - Red Hat Enterprise Linux 8 (x86_64, aarch64) - Ubuntu 18.04, 20.04 and 21.04 (amd64, arm64) The next release will also add Ubuntu 21.10 support. The arm64 support on selected Debian and Ubuntu releases are currently considered a tech-preview. This will also be the last release which includes support for Debian 9. As of the next release Debian 10 and CentOS 7/RHEL 7 will be the oldest supported releases. The Data Channel Offload (DCO) tech-preview feature is supported in these distributions: - CentOS 8 - Fedora 33, 34 and Rawhide - Ubuntu 20.04 and 21.04 - Red Hat Enterprise Linux 8 We have not yet had any chances to test DCO on Debian 11 yet. Ubuntu 21.10 will also get ovpn-dco packages. This work will be part of the next release. -- kind regards, David Sommerseth OpenVPN Inc Source tarballs --- * OpenVPN 3 Linux v16 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-16_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-16_beta.tar.xz.asc> SHA256 Checksums -- 3c8a4e26feca72a7d8887426c496a148df4606b9656f720848853c1f17a030a4 openvpn3-linux-16_beta.tar.xz 7aa2ae44e8c7cfcf5b9129107ab7842b97ad6f026385c8e65c79045bb1500c9a openvpn3-linux-16_beta.tar.xz.asc git references git repositories: <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> git tag: v16_beta git commit: 713b35e908489579bf5246b577373880923cf6fe Changes from v15 to v16 --- Arne Schwabe (1): Implement WEB_AUTH auth pending method David Sommerseth (39): vendor: Upgrade to googletest 1.11 python: Harden openvpn3-as HTTPS connect ovpn3cli: Add --timeout support to session connect operations python: Remove connection attempt counting in openvpn3-autoload python: Add SessionManagerEventType constants python: Add SessionManagerEvent callback systemd: Add support for VPN session management via systemd sessionmgr: Grammar fix in an error message sessionmgr: Split out pure manager functions from OpenVPN3SessionProxy python: Use std namespace explicitly dbus: Add DBusProxy::Introspect() method tests: Make netcfg-proxy-unit test aware of other devices dbus/creds: Add new DBusCredentials::CheckACL_allowRoot() method sessionmgr: Grant root user access to read all session properties ovpn3cli/admin: Add sessionmgr-service command common: Fix duplicated imports of config.h sessionmgr: Simplify the ACL check for properties cli/sessionmgr: Simplify property extraction core: Update OpenVPN 3 Core library (DNS cache fix) common: Improve the OptionValueType::Present implementation common: Extend Configuration::File with an UnsetOption() method common: Configuration::File - Add backwards compat parsing for present opts cli/admin: Call instead Config::File::UnsetOption() on --config-unset common: Add private ParsedArgs::remove_arg() method common: Simplify ParsedArgs::ImportConfigFile() common: Don't throw on missing key in ParsedArgs::GetAllValues() cli/openvpn3: Fix missing space in config-remove warning cli/config: Fix incorrect spelling python: Handle CTRL-C in openvpn3-as gracefully python/openvpn3-as: Improve profile download error handling python/openvpn3-as: Fix incorrect exception type ovpn3cli: Fix session-start with dynamic challenge auth python: Fix dyn-challenge auth in openvpn2 cli/session: Not all connection failures are timeout related cli/session: Fix never ending session with failed 2FA lookup: Add error checking to sysconf() lookups common: Fix typo with MachineID::SourceType::NONE netcfg/resolved: Don't configure --dhcp-option DOMAIN as routing domains python: Add --data-ciphers and related options to the ignore list. Frank Lichtenheld (3): build: make gen-openvpn2-completion.py output reproducible on old Python
Re: [Openvpn-users] Unable to locate the .deb package of OpenVPN 2.5.4 for Debian 11/Bullseye
On 15/10/2021 13:06, Stella Ashburne wrote: Debian gets a major release about once every two years and the OpenVPN package is somewhat outdated. You seem to miss my point. No, it is not out-of-date. It is fully supported and receives bug and security updates by the Debian package maintainer for the lifetime of the distribution. So far the OpenVPN maintainers over the last 10-15 years has been pretty good at keeping the OpenVPN package in a decent shape. That the Debian repositories does not do major updates when the OpenVPN community releases one, is a Debian package policy. So you will miss new features arriving in new major releases. But the packages in supported Debian releases _are_ _up-to-date_ in regards to latest security and bug fixes. And this is what makes Debian releases far more stable than many other more bleeding edge distributions. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Unable to locate the .deb package of OpenVPN 2.5.4 for Debian 11/Bullseye
On 09/10/2021 18:42, Mathias Jeschke wrote: If you really need a newer major (3.x) or minor release (2.x) [...] Just a clarification here. OpenVPN 2.x, OpenVPN 3.x are "generations". OpenVPN 2.x is written in C, OpenVPN 3 is a "brand new" (it's been available for about 10 years) implementation written in C++. OpenVPN 2.4, 2.5 as well as OpenVPN 3.5, 3.6 are major releases. This is where new features and more intrusive internal code changes happens. OpenVPN 2.5.1, 2.5.2, 2.5.3 as well as OpenVPN 3.6.1, 3.6.2 are minor releases. This is where security and bugfixes typically happens in released versions. Occasionally we might add minor features or other related improvements to ensure better backwards compatibility with newer OpenVPN major releases. To summarize: OpenVPN X.Y.Z X = Generation(implementation platform) Y = Major version (feature releases) Z = Minor version (bug/security fixes) -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Unable to locate the .deb package of OpenVPN 2.5.4 for Debian 11/Bullseye
On 08/10/2021 16:17, Stella Ashburne wrote: Hi Mathias Sent: Friday, October 08, 2021 at 3:00 PM From: "Mathias Jeschke" To: openvpn-users@lists.sourceforge.net Subject: Re: [Openvpn-users] Unable to locate the .deb package of OpenVPN 2.5.4 for Debian 11/Bullseye What is wrong with the Debian package from the official repo? https://packages.debian.org/bullseye/openvpn Do you really need 2.5.4 instead of 2.5.1? Your questions are really pertinent. For as long as I can remember, the person who built and released the community versions of OpenVPN also released them for Debian. That person preceded our friend, Samuli. I just went with whatever was offered by that person and then Samuli. You asked me: "Do you really need 2.5.4 instead of 2.5.1?" I myself am unable to answer it. It's good to understand how distribution packages are maintained. I'm a Fedora/RHEL/CentOS user/contributor myself, so there might be some details not matching completely with Debian/Ubuntu. But it should be somewhat similar. - Major updates of a package (for OpenVPN, that means 2.4->2.5, 2.5->2.6, etc), these happens in the major distribution releases (like Debian 10 to Debian 11) - Minor updates of a package (for OpenVPN: 2.5.1->2.5.2->2.5.3, etc) can be handled in two ways. a) Update to the upstream minor release; which is what I do for Fedora/Fedora EPEL/Fedora Copr repositories. This updates the package version number in the package. b) Backport important fixes from newer releases to the current one in the distribution. This keeps the upstream version but updates the "build" number. This is very common for Debian/Ubuntu, as well as for enterprise distributions such as Red Hat Enterprise Linux and CentOS. Both these approaches gives you a reliable and up-to-date version. Method b) often results in smaller changes being applied, so the stability can often be more predictable - but it depends on how good the package maintainer is. The OpenVPN package maintainer for Debian packages (which ends up in Ubuntu too) are well maintained. Using the OpenVPN community provided packages is commonly more useful when the distro provided version is based on an older OpenVPN major release. If there are no new features you require in the community provided repository, using the standard distro repository might be more than good enough. On the other hand, it might take a bit longer for a distribution repository to get an updated package compared to using the community provided packages. That's the quicker introduction to this topic. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] On-demand OVPN connection from Windows 10?
On 21/09/2021 16:27, Bo Berglund wrote: On Tue, 21 Sep 2021 13:15:53 +, tincantech via Openvpn-users wrote: Or can I stop the ongoing connect attempt when it seems to fail? I.e. no connection within say 60 seconds then kill the running connection attempt. In the GUI itself (when I run manually on Windows) I can click "Disconnect" to make it stop... See --connect-retry-max in the manual. Concerning the OpenVPN-GUI manual, are you referring to this: https://github.com/OpenVPN/openvpn-gui#send-commands-to-a-running-instance-of-openvpn-gui which Selva Nair pointed me to? If so I cannot find it, I entered the "--connect-retry-max" string in the Ctrl-F box in Firefox but there was no hit. Pretty sure he meant the man-page of OpenVPN 2.5 <https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN 3 Linux client - v15 beta released
Hi, The OpenVPN 3 Linux v15 (beta) is now available. This is primarily a bugfix release as a few issues appeared soon after the last release. * Bugfix: 2FA authentication with dynamic challenge protocol Servers (most commonly OpenVPN Access Server) deployed with 2FA based authentication would fail when the dynamic challenge protocol was utilized. The result would be a client disconnecting with a time-out error and in some cases the openvpn3 sessions-list' would enlist "ghost" sessions not responding. This command would also wait for a long time before reporting the complete list of sessions when such ghost sessions are present. This is fixed. Reported: <https://github.com/OpenVPN/openvpn3-linux/issues/55> * Bugfix: Fix misbehaviours with --tls-crypt-v2 This feature has been a known issue for a long time, but newer OpenVPN Access Servers now pushes tls-crypt-v2 profiles resulting in connections failing with NETWORK_EOF_ERROR errors in the log. This is finally fixed. Reported: <https://github.com/OpenVPN/openvpn3-linux/issues/55> * Feature: Added openvpn3-admin variables command This "openvpn3-admin variables" command will provide runtime information used by openvpn3-linux. First variable accessible is the value reported in the IV_HWADDR field sent to the VPN server. This can be seen using: # openvpn3-admin variables --machine-id Supported Linux distributions: - Debian 9 (amd64) - Debian 10 (amd64, arm64) - CentOS 7 (x86_64) - CentOS 8 (x86_64, aarch64) - Fedora 33, 34 and Rawhide (x86_64, aarch64, s390x) - Red Hat Enterprise Linux 7 (x86_64) - Red Hat Enterprise Linux 8 (x86_64, aarch64) - Ubuntu 16.04 (amd64) - Ubuntu 18.04, 20.04, 20.10 and 21.04 (amd64, arm64) The arm64 support on selected Debian and Ubuntu releases are currently considered a tech-preview. The Data Channel Offload (DCO) tech-preview feature is supported in these distributions: - CentOS 8 - Fedora 33, 34 and Rawhide - Ubuntu 20.04, 20.10 and 21.04 - Red Hat Enterprise Linux 8 Remember to update the kmod-ovpn-dco package to the latest available version. Instructions how to install OpenVPN 3 Linux can be found here: <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> -- kind regards, David Sommerseth OpenVPN Inc Source tarballs --- * OpenVPN 3 Linux v15 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-15_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-15_beta.tar.xz.asc> SHA256 Checksums -- 86a29c6cc8bc4dfa15aa913f696e048989ebf682bbc184ae050f61256f87e37f openvpn3-linux-15_beta.tar.xz be0fedded031a135ae2fe82edcac742b5352d17d16648643328b247476953c0f openvpn3-linux-15_beta.tar.xz.asc git references git repositories: <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> git tag: v15_beta git commit: 6c9bbc9e10d7c499339c1ac774d1614e8df88573 Changes from v14 to v15 --- David Sommerseth (5): docs: Update README.md with new DCO and SELinux info common: Extend MachineID to provide source information ovpn3cli/admin: Add a new 'variables' admin command Revert "client/core: Improve fatal exception handling in event()" core-ext: Add support for inline --tls-crypt-v2 ___ Openvpn-devel mailing list openvpn-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN 2fa user authentication
On 05/07/2021 18:39, Gert Doering wrote: Hi, On Mon, Jul 05, 2021 at 11:56:01AM -0400, David Mehler wrote: Thank you for your reply. I do not have a plugin-auth-pam I've run a find for it.Where would this be at, this would be perfect, espeecially if I'm understanding your response right each client certificate would then be bound to a specific username and password which would have to be validated serverside. You need to set up server authentication "somehow". *How* you do this is not built into OpenVPN, as everybody's needs are too different. OpenVPN provides a plugin interface, and the package includes a plugin that can query PAM modules (auth-pam.so), and also a script interface (--auth-user-pass-verify $script). Now, depending on your specific 2FA method, PAM might be a good approach if there is a PAM module already around. But you'll need to do some googling and reading. Gert is right, there are no community "out-of-the-box" solutions for this on the server side. If you feel doing it yourself takes too much efforts, you may consider the commercial OpenVPN Access Server [1] or OpenVPN Cloud [2] offerings as an alternative to a DIY approach. [1] <https://openvpn.net/access-server/> [2] <https://openvpn.net/cloud-vpn/> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] figuring out connection interface
On 09/06/2021 07:57, Gert Doering wrote: Hi, On Tue, Jun 08, 2021 at 11:31:40PM +0200, Aleksandar Ivanisevic wrote: I looked around a bit and haven???t found a way for a non commercial user to open a change request with openvpn team, please point me out if I???m wrong. You're talking to the open source community. Here, it works by either sending a patch, or by offering a bounty for someone else to do the patch. The openvpn commercial branch is not maintaining the openvpn 2.x package but offering the "OpenVPN AS" server. Just to give a more official response to what Gert says. The OpenVPN community is quite self-managed, with contributors from a larger scope than OpenVPN Inc alone; which is great for everyone. We do have people on our pay-roll who spends time on the community project as well, but that is primarily to submit patches needed for OpenVPN Access Server and to review other patches which we find interesting. That said, we all (community and company) do try to review as much as possible of the patches sent to the -devel mailing list. If the change is reasonable and has a valid use case, it will most likely be merged and included in a future release. If you don't want to develop and contribute such a feature or change, you may try to contact OpenVPN Support [1] and open a feature request there. If you are a paying customer and the feature is something we see being valuable both for Access Server and the community, then we might look into it and develop it. This feature will then arrive in both Access Server and the a community OpenVPN 2.x release. Just filing a request in the community Trac instance [2] will most likely just collect dust until someone finds that feature interesting enough to help providing a patch for it. That's sad, but that's the reality - as most of the community developers have other paid jobs they need to care for first and they typically fixes issues which they are hit by in their own use cases. So if you want to see your issue being resolved the quickest way, the best way is to contribute with a patch yourself - or that you hire someone to do it on your behalf. [1] <https://openvpn.net/support/> You don't have to be a paying customer to sign up for an account. [2] <https://community.openvpn.net/openvpn/newticket> You must register for an account (valid for community Trac and forums) if you don't have one already. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] The preferred way to run a client on linux?
On 07/06/2021 23:00, Bo Berglund wrote: On Mon, 7 Jun 2021 11:46:02 +0200, David Sommerseth wrote: On 07/06/2021 09:41, Bo Berglund wrote: 2) By adding a service -- Do the same as above with the client.ovpn file Then: sudo systemctl enable openvpn@client.service sudo service openvpn@client start or sudo systemctl start openvpn@client This is also NOT recommended. Put client configuration files into /etc/openvpn/client ... private keys may be placed in /etc/openvpn/private Then use: systemd start openvpn-client@CONFIG_NAME This is the only approach supported by the upstream OpenVPN project. For more details: <https://github.com/OpenVPN/openvpn/blob/master/distro/systemd/README.systemd> The command you quoted above does not work, whereas this does: sudo systemctl start openvpn-client@CONFIG_NAME Yes, sorry about that! It should be systemctl, not systemd. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] log
On 06/06/2021 14:33, Gokan Atmaca wrote: Hello I want to keep the records of all the clients connected to the ovpn ip addresses for 1 year. How can I do that ? Thanks. Use the --client-connect script hook on the server side. That script will get all the details about connecting clients, and you can store them in a text file, insert into a database or similar things. More information can be found in the openvpn man page: <https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/script-options.rst> -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] The preferred way to run a client on linux?
On 07/06/2021 09:41, Bo Berglund wrote: I am now on the home stretch at setting up a number of Raspberry Pi units as data collectors and they need to connect by OpenVPN to a dedicated server. The RPi units are running the latest version of Pi-OS based on Debian Buster. I have seen different ways of accomplishing this: 1) Via the openvpn defaults --- In this case the client.ovpn file is renamed to client.conf and placed in /etc/openvpn. Then the defaults file is edited: sudo nano /etc/default/openvpn And the AUTOSTART line is set like this: AUTOSTART="client" Then: sudo systemctl restart openvpn This is not recommended at all. This approach is Debian's way to simulate the behaviour of the pre-systemd days. Over the years, this has caused may unexpected behaviours. 2) By adding a service -- Do the same as above with the client.ovpn file Then: sudo systemctl enable openvpn@client.service sudo service openvpn@client start or sudo systemctl start openvpn@client This is also NOT recommended. Put client configuration files into /etc/openvpn/client ... private keys may be placed in /etc/openvpn/private Then use: systemd start openvpn-client@CONFIG_NAME This is the only approach supported by the upstream OpenVPN project. For more details: <https://github.com/OpenVPN/openvpn/blob/master/distro/systemd/README.systemd> 3) By setting up a cron job running on startup -- In this case cron is set up to run openvpn with the client.conf file as config, not necessarily located in /etc/openvpn This sounds like a cludgy workaround hack. Don't do that. You will have much more control when systemd is used correctly. In addition to systemd's journal also fetching the logs in way which is easier to navigate in afterwords. The openvpn-server@.service unit also has "RestartSec=5s" and "Restart=on-failure" set, which will automatically restart openvpn servers if they die unexpectedly. You can do a similar trick with the openvpn-client@.service - also for only specific configuration files: # systemctl edit openvpn-client@CONFIG_NAME This will fire off an editor, where you add these lines: [Service] RestartSec=1m Restart=on-failure This will automatically restart this particular configuration after 1 minute if the openvpn process dies unexpectedly. "1 minute" may be tweaked, but also consider race conditions against your server. Not all client configs will be too happy if started too quickly afterwards. 1 minute is very conservative - but based on this is a common timer delay on the server side, 30 seconds might be enough and work fine too. For those wondering why we don't ship with this restart by default on client configs, it is simply that each site has different configs where some values works better than others. We can't evaluate that on-the-fly. Some sites might not even want this behaviour. We could enable it on the server side as we expect most uses wanting OpenVPN servers started via systemd to run constantly. And we can have the short 5 seconds delay as that config will anyhow start the OpenVPN server with a clean and fresh state. For clients restarting, there exists a state already on the server side which we want to avoid confusing. -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] GUI auto-disconnect option
On 27/05/2021 18:23, Gert Doering wrote: Linux distributions upgrade in their own pace, and if 2.5.0 wasn't released when the distribution had their "cutoff for new versions day", they will usually stick to 2.4.x for ever, backporting security fixes. On 27/05/2021 18:29, tincantech via Openvpn-users wrote: See: https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos Basically, Gert is right. Using the distro provided packaging is the preferred and recommended approach, as that ensures stability during the lifetime of the distribution release. Most distributions have a fairly rigid QA/testing process before a release is done, which sorts out a lot of issues before the release hits users. And OpenVPN is typically part of that implicitly. We do however provide a third-party repository. We do try to ensure it is kept stable there as well, but we do not have the same amount of resources and possibilities to thoroughly test the complete range of distributions, distributions releases and OpenVPN releases. There will be some situations where we have missed a spot. But for the vast majority of impatient users wanting a newer OpenVPN release than what the Linux distro provides, our third-party repo is usually good enough. But the third-party repos should only be used if you have no other choice to the distro provided packaging. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] systemd[1]: openvpn@X.service: start operation timed out. Terminating.
On 27/04/2021 17:57, Felix Natter wrote: hello openvpn-users, Felix Natter writes: Apr 23 11:08:13 sidact-lap11 systemd[1]: Starting OpenVPN connection to Y... Apr 23 11:08:44 sidact-lap11 systemd[1]: openvpn@Y.service: start operation timed out. Terminating. sorry for the noise, the colleague got the wrong passphrase. FWIW ... The openvpn.service and openvpn@.service unit files are not officially supported by the community; there is quite a difference in these unit files across distributions - where they often behave differently. The official community supported approach are the openvpn-client@.service and openvpn-server@.service unit files; as described here: <https://github.com/OpenVPN/openvpn/blob/v2.5.2/distro/systemd/README.systemd> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Kill stale session at the server
On 09/04/2021 08:16, Gert Doering wrote: HI, On Thu, Apr 08, 2021 at 07:05:32PM -0400, Selva Nair wrote: On Thu, Apr 8, 2021 at 6:53 PM Mason Walters via Openvpn-users < openvpn-users@lists.sourceforge.net> wrote: I've ran into this issue with 2.5 clients. Adding 'explicit-exit-notify' to the client's config resolved it for me. ???explicit-exit-notify [n] I have always felt that this (with say n=1) should have been on by default in UDP clients. And ignored byTCP clients instead of flagging a FATAL error. Wonder why keep this as an optional option. Not sure. I assume it's a relict from ancient times when the main focus was "p2p with --secret" (where you could restart each end without the other side having to notice). On the server side, explicit-exit-notify is a bit more problematic today (it currently interferes in strange ways with saved tokens on the client), but on the client side I'm not sure I see drawbacks. That said, maybe we should just make it pushable *and* de-FATAL it for TCP mode (pushed or not). So server operators can decide what they want. Even though you already found out it should be pushable, I kinda also agree with Selva here. Also, OpenVPN 3 Core library already has explicit-exit-notify as the default (it doesn't even grok this option; it's hard-coded to always be enabled). But it needs to be restricted to UDP only and most likely tls-client mode only. -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] ERROR: setrlimit() failed: Operation not permitted (errno=1)
On 20/03/2021 22:13, Selva Nair wrote:
HI,
On Sat, Mar 20, 2021 at 4:57 PM Gert Doering <mailto:g...@greenie.muc.de>> wrote:
Hi,
On Sat, Mar 20, 2021 at 12:20:45PM -0400, Selva Nair wrote:
> We should have probably made this not a FATAL error.
The rules could be twisted a bit ("if uid == 0 then not fatal"), but
generally speaking, we setrlimit() to avoid running into memory issues
later on - and if that fails, someone else is imposing restrictions
on us. So better fail right away than in malloc() later on.
With that patch we increased the capability requirements when using
--mlock. mlockall() only requires CAP_IPC_LOCK, it's the added
setrlimit() that needs CAP_SYS_RESOURCE.
So, someone who has carefully set the mlock limit to, say, 50MB based on
their needs, and using an existing systemd unit file will get an
unnecessary error exit.
Anyway let's document the new capability need for using mlock when
started with RLIMIT_MEMLOCK < 100MB. And update the included systemd
unit file.
As a short term solution, updating with CAP_SYS_RESOURCE may be
reasonable. But I think we need to look more into how we handle
capabilities inside OpenVPN, at least on Linux. For example, with the
new netlink interface in 2.5 (sitnl), OpenVPN should be able to be
*started* without root privileges as long as the user has CAP_NET_ADMIN.
But it may break other things expecting to run as root, which is why
we're threading carefully here for the moment.
But my main point is that we should actually have an improved pre-start
check where capabilities are evaluated and then warn or abort starting
up as early as possible. And once a capability is no longer needed, it
should be dropped, as ideally any program should run with as few
privileges as possible.
--
kind regards,
David Sommerseth
OpenVPN Inc
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Fragment
On 09/03/2021 19:51, tincanteksup wrote: Hi, On 05/03/2021 18:43, Gert Doering wrote: Hi, On Fri, Mar 05, 2021 at 06:20:54PM +, tincanteksup wrote: All other clients behave normally but they do not use --fragment or --mssfix. It should be, but I'm not sure if --fragment can be set on a per-client basis (yet)... --mssfix can be set on a per-client basis FTR: --mssfix can *not* be set on a per-client basis ,my log: 2021-03-09 18:45:25 us=933178 tct.66.c.w7e/10.10.201.107:58670 OPTIONS IMPORT: reading client specific options from: tuns_12666u/CCD_net30/tct.66.c.w7e 2021-03-09 18:45:25 us=933308 tct.66.c.w7e/10.10.201.107:58670 Options error: option 'mssfix' cannot be used in this context (tuns_12666u/CCD_net30/tct.66.c.w7e) Server is: OpenVPN 2.6_git [git:master/a4eeef17b20541a7] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct 13 2020 What I suspect Gert meant was that you can add it in the client config on the clients - and each client config may have different --mssfix values. -- kind regards, David Sommerseth OpenVPN Inc OpenPGP_signature Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Windows ovpn server DHCP
On 02/03/2021 04:22, tincanteksup wrote:
On 28/02/2021 21:13, Gert Doering wrote:
Hi,
On Sun, Feb 28, 2021 at 08:02:54PM +, tincanteksup wrote:
Clearly, this is no longer the place to ask.
thanks .
Ask, always.
Claim "this is a bug", only if you can back this by more than "oh,
this log line is confusing me".
The context of that log line is complex - socket.c,
link_socket_init_phase2(),
and it basically means "local bind, no address family specified, no
--remote known yet, need to choose a protocol for the actual bind()
call".
Since IPv6 sockets can handle dual-stack connections, this is what we
do if we do not know yet if the other end is IPv4 or IPv6, and no
protocol
is forced ("udp4" or "udp6").
I resubmit this as a genuine bug:
* Openvpn should error out on the rare occasions that it cannot select
the correct protocol, with an error directing the use of v4 or v6.
Openvpn should not proceed to fail.. without error.
So the crux of the discussion here is from this log line:
On 28/02/2021 18:09, tincanteksup wrote:
2021-02-28 08:00:36 Could not determine IPv4/IPv6 protocol. Using AF_INET6
(Selected IPv6 when IPv4 is required ?)
This is related to (which Gert rightfully says) the use of the bind()
call. Simply said, it ties together ("binds") a file descriptor socket
with a remote end. The remote end is defined with a protocol using
AF_INET or AF_INET6 for addressing in TCP/IP stack.
What might be quite unknown, confusing or surprising, is that many OSes
are capable of binding to an IPv4 address using an AF_INET6 (IPv6)
socket. Linux can do that, and we use that the be able to listen to
both IPv4 and IPv6 addresses at the same time. OSes not capable of that
need an independent socket per protocol (which is the behaviour you seem
to expect).
So, while this log line is surprising, it is not necessarily wrong or a
bug by itself.
What is more interesting in your log extracts are these lines:
2021-02-28 08:00:26 ROUTE_GATEWAY 192.168.0.254/255.255.255.0 I=11
HWADDR=dc:f4:01:e4:f4:10
[]
2021-02-28 08:00:26 Notified TAP-Windows driver to set a DHCP IP/netmask
of 10.8.0.1/255.255.255.252 on interface
{27C77640-C538-4BDA-A9ED-B7A480CAF22D} [DHCP-serv: 10.8.0.2, lease-time:
31536000]
[...]
2021-02-28 08:00:36 Warning: route gateway is not reachable on any
active network adapters: 10.8.0.2
I am no Windows person, so I do not fully grasp the finer details here.
But it seems like the the TAP-windows6 interface did not manage to get
properly configured. Since it uses the DHCP protocol in this case to
configure the IP address, that seems not to have been picked up in time.
Perhaps it just was a bit slow to react, so you need to use the
--route-delay option?
The last log line above just says that "OpenVPN was not able to find any
device configured with 10.8.0.2". The two last log lines you refer to:
2021-02-28 08:06:47 C:\Windows\system32\route.exe DELETE 10.8.0.0 MASK
255.255.255.0 10.8.0.2
2021-02-28 08:06:47 ROUTE: route deletion failed using
DeleteIpForwardEntry: Impossibile trovare elemento
They are also a natural result of the prior errors. The TAP-Windows6
based interface was not configured properly, thus it failed to remove a
route which does not exist.
So, the conclusion is that this isn't an OpenVPN bug by itself as it
stands now.
Error messages should ideally be easier to grasp and relate to each
other, but there is a mixture of error messages reported by the OS
(Windows) directly and some which comes from OpenVPN. We don't want to
add code parsing error codes in details to make the log file look
completely coherent - as that would require quite some code which would
need to far better understand in which situation an error was happening
and interpret and "translate" fairly general OS errors into OpenVPN
specific situation specific errors. While the end-user friendliness
could be improved, the code complexity adding this kind of logic (which
would also have potential for misinterpretations and even more confusing
misrepresentations), it is far better to leave these errors untouched as
far as possible and just pass them on. These errors are also different
on different platforms, so understanding the platform you're debugging
on is required anyhow.
What will be more important for you to figure out is *why* the
TAP-Windows6 driver didn't pick up the DHCP message and configure the
interface? Was it just due to responding late? Or was it due to some
firewall rules blocking DHCP announcements happening on the TAP-Windows6
interface? Was something running with incorrect privileges?
Once that has been figured out, we can more easily see and understand if
something in the OpenVPN code paths was misbehaving. But from what we
see from
Re: [Openvpn-users] TCP syn]
On 25/02/2021 17:56, tincanteksup wrote: How about ... On 25/02/2021 01:03, tincanteksup wrote: Keeping up with the internet is hard: https://squeeze.isobar.com/2019/04/11/the-sad-story-of-tcp-fast-open/ I guess the bottom line is: Use UDP, if you are worried about TCP SYN to your server. Instead of UDP.. Use --port-share and have the other application drop all incoming packets anyway. Would that work ? I have not tested .. Not really. If you're worried about TCP SYN attacks this happens before any application on the system. The whole TCP handshake is handled in the kernel. You need a stateless protocol layer (UDP) to battle the TCP SYN challenges. And with --port-share, OpenVPN becomes a (MITM) proxy also for all the traffic not identified as OpenVPN packets. --port-share needs a destination port for the non-OpenVPN traffic. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] TCP syn]
On 24/02/2021 23:05, tincanteksup wrote: On 24/02/2021 21:28, tincanteksup wrote: On 24/02/2021 20:05, Marc SCHAEFER wrote: On Wed, Feb 24, 2021 at 07:27:09PM +, tincanteksup wrote: I wonder if IPv6 has any new features which can customise the initial Syn packet in any way ? Not to my knowledge. Why would you want to do that? Just a passing thought .. I think I just sort of re-invented syn-cookies without realising it ;-) I was thinking that IPv6 might have something like that actually defined by RFC and built in to a syn packet. I mean, why not ? In fact, this idea seems to TCP Fast Open (https://tools.ietf.org/html/rfc7413) Similar to but not the same as TFO. In my idea, the initial client SYN would have an encrypted cookie if it came from OpenVPN client. The server could simply drop all SYN *with Zero ACK* which does not have this encrypted cookie, to be verified by OpenVPN not IP stack. So data passed directly to the application for review and no response from IP until the application allows it. But after reading the RFC I realise this is way outside the scope of TFO as it is currently being designed. So, as I understand TFO the main goal is to shave off some round-trips by sending a data payload together with the SYN packet from the client. In OpenVPN context that would not need to be much different from how we handle UDP packets today. This is essentially the difference between UDP (stateless) and TCP (stateful). With UDP, OpenVPN looks at the UDP packet arriving, does the TLS-auth/crypt validation and drops the packet if it fails. If the validation is good, the content is being decrypted and handled accordingly. Since UDP is stateless, it does not reveal to the sender if a packet was dropped or not - thus the port will seem to be unavailable by port scans. With normal TCP, first the SYN - SYN ACK - ACK dance happens and *then* the first data packet is passed on from the kernel to OpenVPN where can look at and do the TLS-auth/crypt validation. But since TCP is stateful, it has already signalled to the sender that "I have a service available on this port" - and this is before OpenVPN kicks in. Now with TFO in play, from a very simplistic view, the client would need to send data together with the ACK. At this point OpenVPN would get the data and can do the TLS-auth/crypt validation and close the connection if it fails. In this case, it would be a mixture of UDP and TCP for OpenVPN. Yes, OpenVPN can shut the connection down quicker. But it will still signal to the client that "yes, I have a service available on this port". But I'm really not sure if there is a big gain in OpenVPN of doing that. It makes the initial TCP handshake faster, yes. But that happens in the beginning of a VPN session and on reconnections where the previous connection was lost/closed. Once the TCP handshake has passed, you don't notice this at all - it's all the same connection. TFO has a bigger advantage in short-lived TCP sessions (like web browsers) where you open several independent TCP connections to fetch data in parallel and then close them down. Here TFO will have an edge. Now you might argue about the crypto part in the TFO SYN cookies, but that is entirely handled by the kernel and TCP stack - nothing OpenVPN (or any other application) will need to or can care about. This Linux Weekly News article has a nice walk-through of TFO at an earlier development stage: <https://lwn.net/Articles/508865/> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN Setup on a VM with two NICs
On 16/02/2021 20:37, Nikolaos Milas wrote: Hello, I would like to ask for your help for a setup according to the following scenario. [...snip...] Will OpenVPN clients automatically select the NIC2 gateway since they will be having IP Addresses on the NIC2 subnet? The routing table on your VPN clients and server decides where and how the traffic will flow. That is entirely up to you how you want the flow. That said, the traffic will always exit at the NIC which has a an exit route. Will OpenVPN server accept 10.10.128.2 as an interface to 10.10.128.0/22? How should it be configured? (Or it will only automatically set 10.10.128.1 as an interface?) When starting OpenVPN, it will use its own tun interface, with its own network range. And routing takes care of the rest. Is there any example of such a setup published somewhere? (I have not been able to find one.) Have a look here: <https://community.openvpn.net/openvpn/wiki/GettingStartedwithOVPN> <https://community.openvpn.net/openvpn/wiki/BridgingAndRouting#Usingrouting> These should generally provide some of the basics needed for your setup. (We would also want to enable IPv6 on all functions, but this matter will be treated later.) IPv6 is handled in the same as IPv4, you just need to use the -ipv6 related options in addition. See the man page for details. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN 3 Linux client - v13 beta released
Hi, The OpenVPN 3 Linux v13 beta is now ready. The highlights of this release includes: * Feature: IPv6 and TCP protocol support in OpenVPN Data Channel Off-load (DCO) kernel module - ## WARNING ## TECH-PREVIEW FEATURE ## - The DCO feature is currently a tech-preview feature. It is not targeted for production usage in its current shape. As this is still under heavy development, we currently only support the latest Fedora releases (Fedora 32 and newer), Ubuntu 20.04 and Ubuntu 20.10. This currently requires Linux kernel 5.4 and newer. This release includes an updated ovpn-dco implementation which adds both TCP and IPv6 protocols to be used for the transport between client and server. If you are testing the DCO feature, also be sure you use the updated kmod-ovpn-dco package or build the ovpn-dco module based on git commit 8f04ed862539f0. Please see the information at the end how to enable the DCO feature. * Bugfix: Misleading argument count when options are missing arguments If an option requring a certain minimum amount of arguments was missing one or more arguments, for example using just --keepalive 30, the error would be: ERR_PROFILE_OPTION: option_error: option 'keepalive' must have at least 3 arguments This is incorrect. The correct number should be "2 arguments". This has been fixed in the OpenVPN 3 Core library which generated this error string. * Bugfix: Multi-factor authentication broke with v12_beta With the v12_beta release, web based authentication was added. This also added signalling support for the CR_TEXT authentication method which was not intended to be added. This resulted in many multi-factor authentication configurations to fail, in particular those connecting to OpenVPN Access Server. This has been corrected and openvpn3-linux does no longer signal CR_TEXT authentication method support. Supported Linux distributions: - Debian 9, 10 (x86_64) - CentOS 7 and 8 (x86_64, aarch64) - Fedora 32, 33 and Rawhide (x86_64, aarch64, s390x) - Red Hat Enterprise Linux 7 and 8 (x86_64, aarch64) - Ubuntu 16.04, 18.04, 19.10 and 20.04 (x86_64) - Tech-preview: Ubuntu 20.10 [grovy] (x86_64) Ubuntu 20.10 is expected to be fully supported as of the next release. Instructions how to install OpenVPN 3 Linux can be found here: <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> -- kind regards, David Sommerseth OpenVPN Inc Tech preview: Enable OpenVPN Data Channel Offload -- - ## WARNING ## TECH-PREVIEW FEATURE ## - The ovpn-dco kernel module is under heavy development. This means that the API used between the kernel space and OpenVPN user space processes may change. Therefore the kernel module version must be the same which OpenVPN 3 Linux has been compiled against. Once the API is has become stable, this restriction will no longer be needed. Currently the DCO feature is only available for testing on Fedora 32, Fedora 33, Fedora Rawhide, Ubuntu 20.04 and Ubuntu 20.10. On Fedora, with the openvpn3 Copr repository enabled: # yum install kmod-ovpn-dco On Ubuntu, with the openvpn3 apt repository configured: # apt install kmod-ovpn-dco With the kernel module installed, the configuration file must be be imported: $ openvpn3 config-import --config CONFIG_FILENAME \ --name CFGNAME \ --persistent Then the imported configuration profile must get the DCO feature enabled: $ openvpn3 config-manage --show --config CFGNAME --dco true To preserve this setting through reboots, --persistent was added when importing the configuration file via 'openvpn3 config-import'. Now everything is ready and a VPN session can be started: $ openvpn3 session-start --config CFGNAME In the log data generated by OpenVPN 3 Linux, you should see an UDPv4-DCO, UDPv6-DCO, TCPv4-DCO or TCPv6-DCO reference similar to this line: [...] CONNECTED servername:port (x.x.x.x) via /UDPv4-DCO [...] Source tarballs * OpenVPN 3 Linux v11 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-13_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-13_beta.tar.xz.asc> SHA256 Checksums --- 3eb1ea7166f21525c23ff37d971ac71916e4b476df7ddd6c50dc3684e864e738 openvpn3-linux-13_beta.tar.xz fa69dedbeaf754eac298e55f7b3b490959cc34b183ee777cd8651533b403241e openvpn3-linux-13_beta.tar.xz.asc git references - git repositories: <https://gitlab.com/open
[Openvpn-users] OpenVPN 3 Linux client - v12 beta released
Hi,
The OpenVPN 3 Linux v12 beta is now ready.
The highlights of this release includes:
* Feature: Web-based authentication
For servers allowing web based authentication, OpenVPN 3 Linux
will now pick up this authentication type request and handle
it. If the openvpn2 or openvpn3 user-front-end applications
are able to open a browser window with the given URL, it will
do so. If not, it will present the URL needed for the further
authentication process. In addition, any VPN sessions awaiting
web based authentication is also presented via the
`openvpn3 sessions-list` command together with the authentication
URL.
* Bugfix: OpenVPN 3 Linux configuration manager could crash
If the openvpn3-service-configmgr program was started with the
--state-dir argument pointing at an unreadable or non-existing
directory, it would crash. This has been fixed to provide a
better error message and exit gracefully. Front-end
applications will still report that the net.openvpn.v3.configruations
service is unavailable, this fix is not visible for end-users - just
improving the behaviour of openvpn3-service-configmgr.
* Bugfix: Properly handle restart of paused sessions
VPN sessions being paused (like via
`openvpn3 session-manage --pause`) would not recover properly if
it was recovered by using the `restart` method instead of `resume`.
When trying to pause the session again, it would not do so as the
session was considered paused already. Resuming a VPN session
via both the `resume` and the `restart` method are considered
appropriate and is now handled correctly.
* Bugfix: openvpn2 running in the foreground could exit with an error
If the openvpn2 front-end was used to start a VPN session and it
was running in the foreground (no use of --daemon), it would present
and error message when closing the session *if* the VPN session
was closed via another channel (such as `openvpn3 session-manage`).
This has been fixed and it will now exit properly if this situation
appears, without any additional error messages.
* Bugfix: openvpn2 would misinterpret --keepalive
The OpenVPN option parser in the Python 3 openvpn module would not
properly parse a few arguments which used multiple arguments - such
as --keepalive. This has been fixed.
* Enhancements: openvpn2 now understands --tls-version-{min,max}
In prior releases, the Python 3 openvpn module did not understand
the --tls-version-min and --tls-version-max options. This has been
resolved and these options are forwarded properly to the
configuration manager.
--
kind regards,
David Sommerseth
OpenVPN Inc
[0] <https://gitlab.com/openvpn/openvpn3-linux>
<https://github.com/OpenVPN/openvpn3-linux>
Source tarballs
* OpenVPN 3 Linux v11 beta
<https://swupdate.openvpn.net/community/releases/openvpn3-linux-12_beta.tar.xz>
<https://swupdate.openvpn.net/community/releases/openvpn3-linux-12_beta.tar.xz.asc>
SHA256 Checksums ---
899a4211e883682f5d1fb50dad4425c743283c117b068d3af3d1189f65c2e0ce
openvpn3-linux-12_beta.tar.xz
7b592b652daa7f4119019d9764005a019765bc4a2ab5de65cf5faf982d0617f4
openvpn3-linux-12_beta.tar.xz.asc
git references -
git tag: v12_beta
git commit: be65151677fa854080a563a52d1a96b38ab29544
Changes from v11 to v12 --------
David Sommerseth (11):
client: Properly reset the paused flag on session restart
python: Improve parsing of options with multiple arguments
python: Extend argument parser with support for --tls-version-min/max
dbus: Add web-auth constant to ClientAttentionGroup
client: Enable web-auth support and URL extraction
python: Add support for handling web-auth in openvpn2
python: Resolve error in openvpn2 on disconnect with pre-closed sessions
common: Implement function for opening up URIs on the host
ovpn3cli: Add support web auth via openvpn3
ovpn3cli: Improve 'sessions-list' for sessions awaiting web auth
configmgr: Abort properly if --state-dir processing fails
-
signature.asc
Description: OpenPGP digital signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVpn and re-authenticate
On 09/11/2020 10:32, Olivier CALVANO wrote: > Hello, > > I have a problem on a recent OpenVPN installation, the server asks > clients to re-authenticate every hour, whether there is activity on the > tunnel or not. > > How can I fix this problem? While Gert is correct about --reneg-sec. This renegotiation is there for a reason as well. It is recommended to renegotiate the tunnel at regular intervals, to ensure the integrity of the VPN tunnel. It ensures the encryption keys used are renewed and rotated. For some users disabling the timer based renegotiation might be the right solution. But then you should enable renegotiation based on bytes or packet counters (--reneg-bytes, --reneg-pkts) instead. -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN Static Challenge With External Script
On 06/11/2020 11:28, Vertigo Altair wrote: > Hi OpenVPN Community, > > I want to make 2FA with my external program. The users gets OTP with > Google Authenticator. > My external program would validate username/password firstly, and after > that, it would validate the OTP. > > On the server configuration, I added the > 'static-challenge "Enter Google Authenticator Token" /my_external_script' > >  line, and on the Client configuration, I added  > >  'static-challenge "Enter Google Authenticator Token" 1' > > line. But I cannot make it work.. > Is there any way to get user's entered OTP to my external program via env? > The --static-challenge is not a server side option. Eric F. Crist has been kind enough to write a blog post about OpenVPN and Multi-Factor-Authentication ... this might get you going quicker: <https://openvpn.net/multi-factor-authentication-with-openvpn-community-edition/> -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] [Openvpn-devel] OpenVPN 3 Linux client - v11 beta released
On 02/11/2020 19:22, Gert Doering wrote: > Hi, > > On Mon, Nov 02, 2020 at 03:00:58PM +0100, David Sommerseth wrote: >>> Then the imported configuration profile must get the DCO feature >>> enabled: >>> >>> $ openvpn3 config-manage --show --name CFGNAME --dco true >> >> So I managed to introduce a typo here, this config-manage operation >> should use --config instead of --name: >> >> $ openvpn3 config-manage --show --name CFGNAME --dco true > > Yeah, right. The difference is quite obvious :-) Gah! If this fails, I'm giving completely up! :) $ openvpn3 config-manage --show --config CFGNAME --dco true Hopefully, I didn't mess up again :-D -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN 3 Linux client - v11 beta released
On 02/11/2020 14:30, David Sommerseth wrote: > With the kernel module installed, the configuration file must be > be imported: > > $ openvpn3 config-import --config CONFIG_FILENAME \ > --name CFGNAME \ > --persistent > > Then the imported configuration profile must get the DCO feature > enabled: > > $ openvpn3 config-manage --show --name CFGNAME --dco true So I managed to introduce a typo here, this config-manage operation should use --config instead of --name: $ openvpn3 config-manage --show --name CFGNAME --dco true Thanks to Lev for spotting this. It is correct in the wiki page and Fedora Copr repository page. -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN 3 Linux client - v11 beta released
27; tools could crash unexpectedly. This was an error related to the argument alias processing and has been fixed to avoid this issue. * Enhancements: The openvpn2 bash-completion support is extended In prior versions, the openvpn2 command did not provide any shell completion help to the --config option. This has been resolved. * OpenVPN Access Server configuration import improvements The 'openvpn3-as' utility now signals to the Access Server the downloaded configuration profile is intended to be imported into a local storage. -- kind regards, David Sommerseth OpenVPN Inc [0] <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> Source tarballs * OpenVPN 3 Linux v11 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-11_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-11_beta.tar.xz.asc> SHA256 Checksums --- 1207fa09f32d887cbbe8abc13ea589d0aa67126b70f6e9d1508006d67cedf12d openvpn3-linux-11_beta.tar.xz 5af11fd30a8a73f8151eb062a4bb85bbd0e416d9816b835a585b892b3ccc53c1 openvpn3-linux-11_beta.tar.xz.asc git references - git tag: v11_beta git commit: 087393e775fb5b58b28147819ffc55a30b1d29ff Changes from v10 to v11 Arne Schwabe (1): Indicate that the openvpn-as imports a config David Sommerseth (13): configmgr: Better handling of incorrect configuration profiles docs: Fix incorrect attribute header - user-auth:password core: Update client and aws service to use new Core process init common/cmdargparser: Fix lacking alias initialization netcfg: Rename the tun device properly on non-DCO builds configmgr: Add DCO device naming hack Update to latest OpenVPN 3 Core library dco: Update ovpn-dco submodule to get the latest header files docs: Update README with related to the new DCO feature docs/man: Add missing options in openvpn3-config-manage man page build: Fix out-of-tree builds when --enable-bash-completion is enabled shell: Improve openvpn2 --config bash completion core/ovpn-dco: Sync up DCO API changes Lev Stipakov (16): openvpn3-service-client: add debug option to specify client path build: Define OPENVPN_USE_SITNL in configure.ac core: Update to latest openvpn3 Core library common: adapt to Core library changes in core JSON extensions tests: add missing include in netcfg cli Add ovpn-dco submodule build: Add ovpn-dco build options configmgr: Add support for "dco" config property client/netcfg: Initial support for ovpn-dco netcfg: Implement crypto key passing for ovpn-dco netcfg: Implement ovpn-dco tun establish() client/netcfg: Handle ovpn-dco device creation error netcfg: Implement ovpn-dco crypto key swapping netcfg: Implement setting peer properties for ovpn-dco Jenkinsfile: add ovpn-dco support ovpn-dco: explicitly subscribe for genl packets - signature.asc Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN GUI Windows, OpenVPN running as service
On 22/09/2020 12:48, Helmut Schneider wrote: > Am 21.09.2020 um 23:16 schrieb Selva Nair: > >> On Mon, Sep 21, 2020 at 9:11 AM Helmut Schneider > <mailto:jumpe...@gmx.de>> wrote: >> >> Â Â Â Hi, >> >> Â Â Â I'm running OpenVPN GUI as Service on Windows 10. >> >> I do not understand what that means. Are you referring to the OpenVPN >> Interactive Service? > > https://openvpn.net/vpn-server-resources/use-openvpn-connect-v3-on-windows-in-service-daemon-mode/ > > > And the GUI seems unavailable in this case unfortunately. You seem to mix "OpenVPN GUI" (community based open source OpenVPN for Windows) [1] with "OpenVPN Connect" (OpenVPN Inc provided closed source VPN client only) [2]. These two are very different. * OpenVPN GUI is the more traditional version, where you need to get a config file and save that in the proper directory on the client to get started. * OpenVPN Connect includes a more seamless integration with OpenVPN Access Server [3] and OpenVPN Cloud [4], where you provide an appropriate server URL and user credentials and the VPN client is configured for you. This client does only support TUN devices (no TAP devices, thus no bridging). Regardless of the client, it is possible to use OpenVPN GUI with Access Server and OpenVPN Cloud, as well as using OpenVPN Connect against a most other OpenVPN based servers and services. [1] <https://openvpn.net/community-downloads/> [2] <https://openvpn.net/client-connect-vpn-for-windows/> [3] <https://openvpn.net/access-server/> [4] <https://openvpn.net/cloud-vpn/> -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] On Access policies
On 31/07/2020 22:53, Alex K wrote: > > > On Fri, Jul 31, 2020, 08:39 Gert Doering <mailto:g...@greenie.muc.de>> wrote: > > Hi, > > On Thu, Jul 30, 2020 at 11:33:45PM +0300, Alex K wrote: > > On Wed, Jul 29, 2020, 07:57 Peter Fraser <mailto:softwareinfo...@gmail.com>> wrote: > > > I set up my OpenVPN Server for IT access but now everyone seems to > love > > > and I have to be allowing more and more persons. I wonder, is there a > way > > > to prevent one user from accessing a particular route that is listed > in the > > > global config file. I have only seen how to the opposite, that is, > allow a > > > user access to a route not listed in the global config. Any help > would be > > > greatly appreciated. > > > > > As a simple approach, I would recommend pushing specific routes to > users > > through the ccd file. Each ccd file named according to the common name > of > > the user's cert. > > While this works, it's not a good security measure - the server will not > verify (can not) that the client is using *only* those routes that you > push. > > So if you put "route 1.2.3.4 255.255.255.255" in the client config, > that address will be routed into the VPN as well, in addition to what > the server pushed. > > Indeed. If you have to deal with such users then you may push specific vpn ips > to each user then control access with firewall rules at vpn server statically, > though this approach seems not very much scalable as you have to carefully > manage the firewall and assigned ips. To make it more fun, and still keep it > simple, I would prepare a connect script on server side which according to the > client name it would add/remove firewall rules to allow specific access to the > dynamically assigned vpn ip. This is basically the whole idea with eurephia [0] ;-) Web page has not been updated in a long while, but the project does still live and should work fine with OpenVPN 2.4 servers when using --compat-names. OpenVPN 2.5 servers support will arrive as soon as I have time to hack more on this project again; or someone sends patches fixing it. Client side is not version dependent at all. [0] <https://www.eurephia.net/> -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Is OpenVPN based on SSL VPN?
On 15/08/2020 16:03, Turritopsis Dohrnii Teo En Ming wrote: > Good day from Singapore, > > I have a question. > > Is OpenVPN based on SSL VPN? > > I am looking forward to hearing from you soon. > > Thank you very much. Just to extend the answers from Gert and Stefan M. a little bit. OpenVPN uses OpenSSL or mbed TLS for the cryptographic operations, as well as passing encrypted data between the local and remote side. But it does not use the plain SSL/TLS protocol. The OpenVPN protocol consists of two channels: Data Channel and Control Channel. The Data Channel transports the tunneled network traffic, using a symmetric encryption. This is plain binary data, wrapped together with some OpenVPN specific header information. The Control Channelis used to exchange configuration and authentication data and provides the needed data to derive the symmetric encryption key used for the data channel. Some modes of the control channel implies wrapping the standard TLS protocol into an OpenVPN specific packet format. The very first byte of each packet being transported over the wire identifies the "OPCODE" which indicates if the rest of the packet is a data or control channel packet. So depending on what you mean with "SSL VPN", OpenVPN may or may not be an SSL VPN. OpenVPN has its own protocol, but it does use the standard TLS protocol for some of its operation. -- kind regards, David Sommerseth OpenVPN Inc ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN 3 Linux client - v10 beta released
Hi, The OpenVPN 3 Linux v10 beta is now released. This is available in our git repositories [0] and URLs for source tarballs are listed later in this e-mail. We have pre-built binaries for the following Linux distributions: * Fedora 31 and 32 (via Fedora Copr: x86_64, aarch64) * RHEL/CentOS 7 and 8 (via Fedora Copr: x86_64, aarch64) * Debian 9 and 10 (amd64) * Ubuntu 16.04, 18.04, 19.10 and 20.04 (amd64) A quick-start guide for OpenVPN 3 Linux can be found here: <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> The highlights of this release includes: * Feature: systemd-resolved integration By default, OpenVPN 3 Linux will modify the /etc/resolv.conf file with DNS configurations pushed by the VPN server. This release adds systemd-resolved as an alternative to this approach, where the systemd-resolved service will be in charge of querying the proper DNS resolvers and there will no longer be any fight over configuration files such as /etc/resolv.conf. In this release, pushed DNS configurations will be handled quite similar to how DNS queries has been handled before. The DNS settings pushed by the VPN server will typically take precedence, but systemd-resolved may query other servers on other interfaces as well. That said, if the VPN server pushes "dhcp-options DOMAIN ", hosts under that domain will in this case only be queried via the VPN tunnel alone. You may call this a partial DNS-split. In coming releases, we will evaluate further possibilities to configure how DNS requests would be handled by systemd-resolved. This could include modes such as full split (only query for pushed DOMAIN via the DNS server provided by the VPN) or exclusive VPN (DNS queries should only go via the VPN tunnel). This systemd-resolved integration requires at least CentOS 8, Fedora 31, 32 or Rawhide, Red Hat Enterprise 8 or Ubuntu 20.04. Other distributions may work as long as it uses systemd v243 or newer. To enable systemd-resolved, fully ensure that systemd-resolved is properly configured and activated on your system. Currently only Ubuntu 20.04 does that somewhat out-of-the-box (there might be some additional changes to nsswitch.conf is required for optimal performance). Please read the available systemd-resolved documentation for your Linux distribution. Once systemd-resolved is enabled and activated, run this command as root before starting any VPN tunnels: # openvpn3-admin netcfg-service --config-set systemd-resolved 1 and wait until the openvpn3-service-netcfg has restarted. With the log-level set to 5 or higher in netcfg-service, the log file will include this log line: Network Configuration VERB2: systemd-resolved DNS configuration backend * Feature: openvpn3 log with --config will now wait for a not-started session When starting the end-user session logging, prior versions required the VPN session to already be running before a log client could be attached. With this release, if the session has not already been started, the openvpn3 log command will wait until it sees the appropriate VPN session has started and will attach to it instantly. This allows to grab the first log lines of a starting VPN sessions for an end-user without other ways of accessing OpenVPN logs. * Improvement: openvpn3-as indicates tls-crypt-v2 support to AS When downloading a VPN configuration profile from an OpenVPN Access Server, the openvpn3-as script will now signal to the server it is capable of handling configurations with --tls-crypt-v2. * Bugfix: AWS integration failed to propagate routes in some AWS regions The openvpn3-service-aws process could in some AWS regions fail to push routes to the AWS-VPC, leading to a process crash. Both the crash and the AWS service has been extended with more region CA certificates used for the request validations. In addition it will now pick up more of system CA certificate file locations than before. -- kind regards, David Sommerseth OpenVPN Inc [0] <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> Source tarballs * OpenVPN 3 Linux v10 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-10_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-10_beta.tar.xz.asc> SHA256 Checksums --- 6fb565d2ec19331ee3203d027d90598e51dec3cb31888be25d15e1c9911dbcd1 openvpn3-linux-10_beta.tar.xz bc95ac62700e0924b43d7846a3ca7601d1ac2ef3efeb32f2f01d48d3b11d32f0 openvpn3-linux-10_beta.tar.xz.asc git references - git tag: v10_beta git commit: ff27a9f83b29448797e72ce9f92abc498647202a Changes from v9 to v10---
Re: [Openvpn-users] peer-peer vpns and systemd
On 19/07/2020 07:09, Richard Hector wrote:
> Hi all,
>
> I have 4 machines (actually VPSes) that have a full mesh of VPNs between
> them. I'm using a slightly-modified version of the 'client' example
> config. Since it appears TLS, and the use of certificates, requires
> named client and server peers, I'm using a PSK (one for the whole set).
>
> This, when it works, seems to work fine.
>
> The trouble occurs when trying to (re)start the services with systemd.
> Using 'systemctl restart openvpn-client@host1', for example, will
> sometimes hang, and eventually return when I run the corresponding
> command on host1 - but that one then hangs, till I run it on the first
> one again ... and so on indefinitely. I can usually make it work if I
> stop both, then start both. But arranging timimg like that is difficult,
> if one machine needs to reboot - whether the VPN between them will come
> back is unpredictable, to say the least.
>
> On the other hand, the VPNs I have with a more conventional cert-based,
> client-server setup cope with reboots at either end just fine.
>
> Any suggestions on why this happens - what state the peers go into, for
> example - and how to avoid it would be gratefully received.
Hi Richard,
As I'm the one who introduced the openpn-{client,server}.service files, I feel
obliged to answer here :)
First of all, the static key p2p mode (using --secret with a preshared key on
both sides) is really not recommended. It's fine for testing a VPN setup for
a short while, but not recommended for production environments - as it does
not give you any forward secrecy (PFS [1]) at all. This means it is possible
to bruteforce the encryption on encrypted data traffic which has been
collected. An successful attack results in all prior and future tunnel
traffic is considered compromised.
This is also why I never really considered the static key p2p mode when
implementing these new unit files. The advantage of these unit files are
essentially that they add more hardening outside of OpenVPN as well and the
server side will automatically restart if the openvpn process suddenly dies.
Also consider that the static key p2p does not really have a client/server
relation. They are both equal nodes which configures "my end point" and "the
remote end point", reflected in the --ifconfig where the IP addresses are
reversed on the hosts. That said, you might have better luck using the
openvpn-server@.service unit files on both sides.
The p2p mode, however, is useful, and often enough for many use cases. But I
do recommend you to use a p2p using a PKI setup. This gives the p2p network
configuration simplicity and adds the PFS aspect. All you need to do here is
to create your own CA (using easy-rsa[2,3]) and create a client and server key
and certificates.
On one side (I'll probably recommend the node with 10.111.111.41) designate
this as the server, by adding --tls-server to the configuration, as well as
adding --ca, --cert, --key and --dh (generated using 'openssl dhparam' with at
least 2048 bits). This side should use the openvpn-server@.service unit file.
The other will be the client side, and needs a copy of the same CA certificate
and its own client key and certificate. The configuration file needs to be
extended with --ca, cert and --key (no --dh). This side can now use the
openvpn-client@.service unit file.
With this slightly changed configuration you keep your network configuration
but enhances the security and this should work fine with the existing unit
files.
[1] <https://en.wikipedia.org/wiki/Forward_secrecy>
[2] <https://github.com/OpenVPN/easy-rsa/>
[3] <https://github.com/OpenVPN/easy-rsa/blob/master/README.quickstart.md>
--
kind regards,
David Sommerseth
OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN issues with Windows NLA
On 03/07/2020 09:46, Marc SCHAEFER wrote: > On Fri, Jul 03, 2020 at 01:20:09AM +0100, tincanteksup wrote: >> DNSSec would put an end to this sort of snooping .. lol > > As Gert said, no, it won't. > > What you may want is DNS over HTTPS or over TLS. However, in that case, it's > the DNS provider that can snoop on you, but no longer your ISP. If your ISP > does not spy on you, the mixing with all of its customers and the caching it > offers are valuable. > > Google and CloudFare offer DNS over HTTPS, bypassing your local DNS, > the latter seem to less spy on its users. > >https://en.wikipedia.org/wiki/DNS_over_HTTPS For a more in-depth walk-through about the issues around DNS over HTTPS (DoH), please see this: <https://www.youtube.com/watch?v=ZxTdEEuyxHU> Paul Vixie is one of the biggest names in the DNS scope, and this guy knows what DNS is all about. DoH is really not a good solution for very many use cases. And it is a move in the opposite direction of the benefit of a proper DNS protocol, decentralizing requests. And DoH needs to implement additional complexity on the server side if you want to consider regional based DNS lookups (like using a local CDN) ... and this is not even touching the privacy/tracking issues in DoH. What is often ignored by many of the DoH promoters, DNS over TLS (DoT) exists and provides the same level of features as unencrypted DNS lookups - without all the issues DoH adds. The biggest challenge of DoT is that many DNS servers have not been upgraded to a reasonable solution with this support, and many who has done that has not configured DoT yet. -- kind regards, David Sommerseth ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] OpenVPN webinar - 24th June
Hi, OpenVPN Inc will host a webinar covering OpenVPN configuration and how the community version differs from the OpenVPN Access Server. The webinar is held by Johan Draaisma. 24th June at 18:00 CET / 19:00 CEST /10:00 PDT Webinar details: <https://go.openvpn.net/aswebinar.html> Time details: <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenVPN+Access+Server+webinar&iso=20200624T10&p1=224> -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] First steps toward setting up openvpn
On 27/05/2020 17:25, Joshua Webb wrote: > I run a stable version of Debian and I would like to set up an OpenVPN, but I > do not know where to start. Would somebody point me to the documentation I > would need to implement an OpenVPN on my base system? > This might be a reasonable starting point: <https://community.openvpn.net/openvpn/wiki/GettingStartedwithOVPN> -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] syslog, drop Port Sharing Messages
On 26/05/2020 14:48, Morris, Russell wrote: > [...] it does trigger, but the message seems to be sent more than once? Not > sure why, still working through that. But I did confirm, the double send is > happening on the sending end (i.e. not the remote syslog). Could it be that your script both prints data to stdout and sends log data to syslog? I struggle to see how the script-hook itself would be called twice in the code, there are some locks ensuring the "connection established" handling is only done once per connection. It should also not be possible to have multiple --client-connect scripts configured, the later one should overwrite the prior one. -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
