You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(12) |
Apr
(45) |
May
(34) |
Jun
(50) |
Jul
(39) |
Aug
(39) |
Sep
(29) |
Oct
(28) |
Nov
(30) |
Dec
(28) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(18) |
Feb
(20) |
Mar
(10) |
Apr
(19) |
May
(72) |
Jun
(42) |
Jul
(31) |
Aug
(153) |
Sep
(156) |
Oct
(233) |
Nov
(213) |
Dec
(137) |
2004 |
Jan
(255) |
Feb
(292) |
Mar
(449) |
Apr
(241) |
May
(412) |
Jun
(541) |
Jul
(532) |
Aug
(611) |
Sep
(689) |
Oct
(804) |
Nov
(676) |
Dec
(715) |
2005 |
Jan
(639) |
Feb
(695) |
Mar
(756) |
Apr
(562) |
May
(497) |
Jun
(424) |
Jul
(394) |
Aug
(427) |
Sep
(390) |
Oct
(418) |
Nov
(387) |
Dec
(494) |
2006 |
Jan
(503) |
Feb
(436) |
Mar
(563) |
Apr
(448) |
May
(400) |
Jun
(420) |
Jul
(240) |
Aug
(362) |
Sep
(292) |
Oct
(408) |
Nov
(318) |
Dec
(245) |
2007 |
Jan
(330) |
Feb
(241) |
Mar
(259) |
Apr
(216) |
May
(305) |
Jun
(277) |
Jul
(288) |
Aug
(269) |
Sep
(273) |
Oct
(248) |
Nov
(267) |
Dec
(265) |
2008 |
Jan
(312) |
Feb
(454) |
Mar
(358) |
Apr
(195) |
May
(352) |
Jun
(305) |
Jul
(233) |
Aug
(385) |
Sep
(441) |
Oct
(325) |
Nov
(301) |
Dec
(329) |
2009 |
Jan
(344) |
Feb
(263) |
Mar
(350) |
Apr
(262) |
May
(255) |
Jun
(161) |
Jul
(330) |
Aug
(281) |
Sep
(285) |
Oct
(230) |
Nov
(304) |
Dec
(284) |
2010 |
Jan
(353) |
Feb
(260) |
Mar
(357) |
Apr
(403) |
May
(335) |
Jun
(236) |
Jul
(199) |
Aug
(247) |
Sep
(212) |
Oct
(160) |
Nov
(118) |
Dec
(110) |
2011 |
Jan
(172) |
Feb
(105) |
Mar
(113) |
Apr
(120) |
May
(124) |
Jun
(88) |
Jul
(94) |
Aug
(63) |
Sep
(78) |
Oct
(42) |
Nov
(137) |
Dec
(90) |
2012 |
Jan
(75) |
Feb
(113) |
Mar
(90) |
Apr
(77) |
May
(68) |
Jun
(58) |
Jul
(67) |
Aug
(119) |
Sep
(56) |
Oct
(60) |
Nov
(72) |
Dec
(48) |
2013 |
Jan
(78) |
Feb
(93) |
Mar
(114) |
Apr
(79) |
May
(57) |
Jun
(56) |
Jul
(29) |
Aug
(84) |
Sep
(55) |
Oct
(75) |
Nov
(61) |
Dec
(40) |
2014 |
Jan
(42) |
Feb
(14) |
Mar
(48) |
Apr
(132) |
May
(96) |
Jun
(58) |
Jul
(90) |
Aug
(116) |
Sep
(88) |
Oct
(69) |
Nov
(97) |
Dec
(93) |
2015 |
Jan
(61) |
Feb
(38) |
Mar
(62) |
Apr
(63) |
May
(67) |
Jun
(124) |
Jul
(79) |
Aug
(101) |
Sep
(60) |
Oct
(109) |
Nov
(64) |
Dec
(135) |
2016 |
Jan
(107) |
Feb
(83) |
Mar
(90) |
Apr
(78) |
May
(125) |
Jun
(100) |
Jul
(52) |
Aug
(96) |
Sep
(23) |
Oct
(74) |
Nov
(85) |
Dec
(168) |
2017 |
Jan
(63) |
Feb
(75) |
Mar
(51) |
Apr
(87) |
May
(48) |
Jun
(135) |
Jul
(90) |
Aug
(72) |
Sep
(38) |
Oct
(54) |
Nov
(102) |
Dec
(42) |
2018 |
Jan
(25) |
Feb
(55) |
Mar
(1) |
Apr
(10) |
May
(31) |
Jun
(72) |
Jul
(61) |
Aug
(12) |
Sep
(30) |
Oct
(41) |
Nov
(33) |
Dec
(16) |
2019 |
Jan
(19) |
Feb
(26) |
Mar
(72) |
Apr
(32) |
May
(38) |
Jun
(26) |
Jul
(19) |
Aug
(12) |
Sep
(8) |
Oct
(19) |
Nov
(61) |
Dec
(26) |
2020 |
Jan
(18) |
Feb
(21) |
Mar
(26) |
Apr
(206) |
May
(59) |
Jun
(18) |
Jul
(64) |
Aug
(28) |
Sep
(22) |
Oct
(15) |
Nov
(22) |
Dec
(21) |
2021 |
Jan
(17) |
Feb
(46) |
Mar
(64) |
Apr
(84) |
May
(86) |
Jun
(84) |
Jul
(45) |
Aug
(12) |
Sep
(27) |
Oct
(38) |
Nov
(49) |
Dec
(42) |
2022 |
Jan
(37) |
Feb
(55) |
Mar
(35) |
Apr
(31) |
May
(27) |
Jun
(61) |
Jul
(15) |
Aug
(4) |
Sep
(71) |
Oct
(15) |
Nov
(14) |
Dec
(12) |
2023 |
Jan
(20) |
Feb
(86) |
Mar
(57) |
Apr
(3) |
May
(7) |
Jun
(28) |
Jul
(105) |
Aug
(189) |
Sep
(33) |
Oct
(63) |
Nov
(40) |
Dec
(71) |
2024 |
Jan
(174) |
Feb
(120) |
Mar
(5) |
Apr
(42) |
May
(39) |
Jun
(19) |
Jul
(17) |
Aug
(23) |
Sep
(16) |
Oct
|
Nov
|
Dec
|
From: Reprobus <rep...@ho...> - 2024-09-18 22:58:24
|
In the Easy-RSA documentation after creating the CA file, under the heading; Importing requests to the CA. It mentions the command to use after the CA is created, although I do not know which `req` file it's referring too ? As well, I assume the nameOfRequest under the same heading is the name of the file to be used which can be the client requesting this request file ? Thank You. |
From: Gert D. <ge...@gr...> - 2024-09-16 07:48:08
|
Hi, On Mon, Sep 16, 2024 at 09:15:24AM +0200, Antonio Quartulli wrote: > In a nutshell, you need to configure both a route and a "iroute" to inform > the VPN server (your relay point) where a certain LAN is. AND some amount of NAT might be involved, depending on "from where do you want to access this Client-LAN?" - something in the Server-Network, some *other* Client of "the OpenVPN Server", or "The Internet". From OpenVPN's point of view, "it is easily solved" :-) - on the openvpn client, enable ip forwarding (so it won't throw away packets "not to itself" but will forward them to the LAN) - on the openvpn server, use route+iroute to ensure that the client LAN is sent to *this* connection (-> what Antonio said) - ensure routing to the VPN, that is, either: - on all(!) involved machines make sure that "routes to client LAN" and "routes back to whoever accesses the client LAN" point towards the respective OpenVPN machines or: - add sufficient doses of iptables NAT wherever suitable so routing isn't needed the best approach here is to do a big picture showing all network infra (routers on both ends, OpenVPN server, OpenVPn clients), and "the networks involved" (client network, etc.), and then check what machines need to know so IP packets can flow both ways - either "routes" or "packet gets NATted, so no routes needed". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... |
From: Antonio Q. <a...@un...> - 2024-09-16 07:13:24
|
Hi, On 16/09/2024 08:46, Bo Berglund wrote: > We would like to set up an OpenVPN service on a summer home to access its local > LAN remotely. > > The site has newly installed fiber access to the Internet, but via an ISP which > has CGNAT:ed the router so there is no access to its IP address from outside. > Therefore I cannot set up a regular OpenVPN server on that LAN to dial into. :( > > I have access to other fiber connected sites where the external IP is a public > address and where I have set up OpenVPN for access and it works fine. > > So I would like to know if it is possible to set up a connection to the CGNAT:ed > LAN by using an OpenVPN client on that LAN connecting to OpenVPN on the publicly > accessible server, and then somehow relaying traffic into the CGNATED LAN via > the connection set up from within that LAN to the publicly accessible server? > > Like having a relaying service utilizing the VPN client connection set up from > the client on the CGNAT-ed LAN allowing a user to connect to the accessible > OpenVPN server and then from there into the tunnel towards the CGNATed LAN? > > If so is there some documentation as to how one could set it up (and what would > such a scheme be named for further web searches)? Yes, this is possible and it's a scenario commonly known as "Client LAN" (connecting a LAN behind a client). We have a flow chart that help you understanding if you went through all the steps required to get it working: https://community.openvpn.net/openvpn/attachment/wiki/IRCimages/clientlan.png In a nutshell, you need to configure both a route and a "iroute" to inform the VPN server (your relay point) where a certain LAN is. Hope this helps. Regards, -- Antonio Quartulli |
From: Minh N. N. <ken...@gm...> - 2024-09-16 07:06:30
|
Minh c6 |
From: Bo B. <bo....@gm...> - 2024-09-16 06:47:04
|
We would like to set up an OpenVPN service on a summer home to access its local LAN remotely. The site has newly installed fiber access to the Internet, but via an ISP which has CGNAT:ed the router so there is no access to its IP address from outside. Therefore I cannot set up a regular OpenVPN server on that LAN to dial into. :( I have access to other fiber connected sites where the external IP is a public address and where I have set up OpenVPN for access and it works fine. So I would like to know if it is possible to set up a connection to the CGNAT:ed LAN by using an OpenVPN client on that LAN connecting to OpenVPN on the publicly accessible server, and then somehow relaying traffic into the CGNATED LAN via the connection set up from within that LAN to the publicly accessible server? Like having a relaying service utilizing the VPN client connection set up from the client on the CGNAT-ed LAN allowing a user to connect to the accessible OpenVPN server and then from there into the tunnel towards the CGNATed LAN? If so is there some documentation as to how one could set it up (and what would such a scheme be named for further web searches)? -- Bo Berglund Developer in Sweden |
From: David S. <daz...@eu...> - 2024-09-05 15:40:24
|
OpenVPN 3 Linux v23 (Stable release) The v23 release is stable release which expands the distribution target since v22_dev was released. The goal for this step was to stabilize the codebase which was migrated to GDBus++ and the new Meson building system. The next release (v24) will also be a stable release, with focus on further stabilisation and less intrusive changes. The v23 release brings back the OpenVPN 3 AWS-VPC Add-on which was not ready for the v22_dev release. This service has also been migrated to use GDBus++. The behaviour of this add-on should otherwise be identical to the service shipped in v21 and older releases. In addition, a new add-on is included in this release. The Cloud Connexa service is being extended with a new functionality, referred to as Device Posture Checks (DPC). This feature will enable the VPN server to request certain checks to be performed on the client side and reported back to the server. These checks are restricted to what the new OpenVPN 3 Device Posture Service (openvpn3-service-devposture) provides. This new feature is NOT installed nor enabled by default. To enable the client-side functionality, the openvpn3-addon-devposture package must be installed, the VPN client configuration must be pre-imported and an Enterprise ID must be assigned to the configuration profile. That will allow the server to request Device Posture Checks to be performed. The currently implemented DPC tests only provides platform information, like Linux distribution name and version, kernel versions, CPU architecture and the client's local time. In future releases, more tests may be implemented. More information on available tests and the declaration of test profiles can be found here: <https://codeberg.org/OpenVPN/openvpn3-linux/src/branch/master/addons/devposture/profiles/profile-format.md> Known issues: - openvpn3-service-client may not exit cleanly unless stopped via 'openvpn3 session-manage --disconnect' first. This may delay the shutdown process if a VPN session is running when the host is being shut down. A fix is in progress and will be prepared for v24. - 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: * Improvement: Upgrade to OpenVPN 3 Core Library v3.10.1 This library update provides the functionality to provide the Device Posture Check functionality in the OpenVPN wire protocol. A fix to resolve compilation errors when the -Wnon-virtual-dtor compiler flag is enabled is included too. * Bugfix: Report client and version correctly in IV_GUI_VER The v22_dev release unfortunately changed the format of the IV_GUI_VER. It would report: 'openvpn3-linux/v22:dev' when it should have been 'OpenVPN3/Linux/v22_dev'. This has been fixed. * Bugfix: --tag option not working with config-import or config-manage A regression bug was introduced in v22_dev which handled the available tracking of Configuration Manager features incorrectly and ended up disabling this feature in the openvpn3 config-import and openvpn3 config-manage commands. This has been fixed. * Bugfix: systemd-resolved support rejected IPv6 DNS resolver address An oversight in the systemd-resolved implementation refused to accept pushed DNS resolver addresses when it was an IPv6 address. This has been fixed and both IPv4 and IPv6 addresses are now fully supported. * Improvement: Python configuration parser support for --connect-retry{,-max} The Python configuration parser in the openvpn3 module did not provide a pass-through for --connect-retry and --connect-retry-max options. This would result in configuration profiles containing these options would not function when using the Python based tools while it would work using the 'openvpn3' command. Credits ------- Thanks goes to those continuing testing and reporting issues. A special thanks to Grzegorz Gutowski who provided the fix to the Python module. He is also the project lead behind the openvpn3-indicator project, which provides a tray-icon for OpenVPN 3 Linux. If you use a graphical desktop, that's a project worth checking out! Many thanks also goes to Razvan Cojocaru who has stepped in providing many great improvements and done all the work for the Device Posture support in OpenVPN 3 Linux. And Lev Stipakov who migrated the OpenVPN 3 AWS-VPC add-on service to GDBus++ Supported Linux distributions ----------------------------- - Debian: 12 - Fedora: 39, 40, Rawhide - Red Hat Enterprise Linux 8, 9 - Ubuntu: 20.04, 22.04, 24.04 Installation and getting started instructions can be found here: <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> Debian 11, Red Hat Enterprise 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 |
From: Gert D. <ge...@gr...> - 2024-09-04 14:51:50
|
Hi, On Wed, Sep 04, 2024 at 02:26:37PM +0200, Ralf Hildebrandt via Openvpn-users wrote: > What the rationale of having both client and server ping each other at > the same interval, but then use ping-restart with different timeouts? This is ancient stuff, so nobody around *knows*. We do suspect that the intention is "if there is network trouble, the client will always timeout the session first", which is also related to "only the client had support for --explicit-exit-notify" (letting the server know that it went away). The part about "make the client notice first" is backed by the manpage ;-) - the "--explicit-exit-notify" reasoning is what we came up with as possible explanation. Now, "+10" would have been perfectly sufficient for that, and we do not know why the code does "*2" instead. In doubt, just expand the macro yourself and configure what suits you - there should not be any real adverse effect if the server timeouts earlier. The --explicit-exit-notify thing won't have an effect on "the network broke" anyway. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... |
From: Ralf H. <Ral...@ch...> - 2024-09-04 12:26:52
|
While reading the docs, I noticed this bit: For example, --keepalive 10 60 expands as follows: if mode server: ping 10 # Argument: interval ping-restart 120 # Argument: timeout*2 push "ping 10" # Argument: interval push "ping-restart 60" # Argument: timeout else ping 10 # Argument: interval ping-restart 60 # Argument: timeout So, while both server and client ping each other at least once every 10s, the server uses "ping-restart 120", and the client gets pushed "ping-restart 60" What the rationale of having both client and server ping each other at the same interval, but then use ping-restart with different timeouts? -- Ralf Hildebrandt Charité - Universitätsmedizin Berlin Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration Invalidenstraße 120/121 | D-10115 Berlin Tel. +49 30 450 570 155 ral...@ch... https://www.charite.de |
From: <md...@bt...> - 2024-09-04 08:31:17
|
On Wed, 4 Sep 2024 09:22:08 +0200, Antonio Quartulli wrote ... > That practically means that QUIC is equally broken everytime macOS is > used behind a router with a smaller MTU (like the PPPoE case mentioned > by Gert). > > Are we truly sure about these statement? In fact, all UDP applications are extremely conservative about maximal packet sizes: e.g. QUIC never uses packets larger than 1385 bytes, MPEG-TS over RTP/UDP uses max. 1328 bytes etc. Thus PPPoE is no problem, as it provides 1492 byte MTU. Also iPhone's/iPad's safety-belt default MTU 1450 in 5G/LTE networks still works. However mssfix=1400 in OpenVPN might result in max. usable packet of e.g. 1376 bytes, which is 9 bytes less than needed for QUIC. Combined with UDP packet blackholing, that's a serious problem - and much better approach would be to lower tun-mtu, if you want to completely avoid fragmentation for all protocols. With kind regards, MD |
From: <md...@bt...> - 2024-09-04 06:48:51
|
On Wed, 4 Sep 2024 08:24:07 +0200, Gert Doering wrote ... > So how does MacOS deal with intermediate routers that can only handle > 1492? This is a very common scenario for PPPoE-based DSL connections, > and since it's not "a local interface" it would have to handle the > ICMPs somehow. > > I know that Linux can directly return the ICMP errors to the userland > socket (which no other platform supports, alas) - but Linux will also > put "packet too big" ICMPs into a route cache, so the next sendto() > call can do the fragmentation / EMSGSIZE return right away, not > having to wait for the incoming ICMP packet. Doesn't MacOS has a > comparable mechanism? It does, but it seems to be implemented only in TCP driver. Thus UDP/RAW sockets can't use ICMP Fragmentation needed. IIRC, the same limitation was in the past on BSD Unix, not sure what's the current status. With kind regards, MD |
From: Gert D. <ge...@gr...> - 2024-09-04 06:24:21
|
Hi, On Wed, Sep 04, 2024 at 08:08:14AM +0200, Marian ??urkovi?? wrote: > On Tue, 3 Sep 2024 21:42:23 +0200, Gert Doering wrote > ... > > I agree that the decision by Connect to do "1500 byte MTU, but > > generate the ICMP itself" (instead of doing ifconfig with lower MTU) > > is somewhat questionable - but for the application, the net result > > should be the same - packet too big, ICMP message, deal with it. > > MacOS is very different from e.g. Linux in this regard. > > If you set tun-mtu to 1400, the operating system correctly fragments UDP packets larger than interface MTU, or returns EMSGSIZE to sendto() call if the DF bit was set on the socket. > > However, for non-TCP sockets, MacOS doesn't react on received ICMP Fragmentation needed. PMTU discovery is only available for TCP and I have it enabled: > > net.inet.tcp.path_mtu_discovery: 1 So how does MacOS deal with intermediate routers that can only handle 1492? This is a very common scenario for PPPoE-based DSL connections, and since it's not "a local interface" it would have to handle the ICMPs somehow. I know that Linux can directly return the ICMP errors to the userland socket (which no other platform supports, alas) - but Linux will also put "packet too big" ICMPs into a route cache, so the next sendto() call can do the fragmentation / EMSGSIZE return right away, not having to wait for the incoming ICMP packet. Doesn't MacOS has a comparable mechanism? > Thus approach implemented by OpenVPN Connect doesn't work at all on MacOS and results in blackholing of non-TCP packets larger than mssfix. I do wonder why. MacOS needs to deal with MTU steps "on the path", otherwise things would break more often. So there should not be a fundamental difference here. (I do agree that taking the --mssfix option and causing something else not related to MSS is surprising at least, and not very logical - I can't fix it, though, as I'm only working on OpenVPN 2.x) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... |
From: <md...@bt...> - 2024-09-04 06:08:21
|
Hi Gert, On Tue, 3 Sep 2024 21:42:23 +0200, Gert Doering wrote ... > I agree that the decision by Connect to do "1500 byte MTU, but > generate the ICMP itself" (instead of doing ifconfig with lower MTU) > is somewhat questionable - but for the application, the net result > should be the same - packet too big, ICMP message, deal with it. MacOS is very different from e.g. Linux in this regard. If you set tun-mtu to 1400, the operating system correctly fragments UDP packets larger than interface MTU, or returns EMSGSIZE to sendto() call if the DF bit was set on the socket. However, for non-TCP sockets, MacOS doesn't react on received ICMP Fragmentation needed. PMTU discovery is only available for TCP and I have it enabled: net.inet.tcp.path_mtu_discovery: 1 Thus approach implemented by OpenVPN Connect doesn't work at all on MacOS and results in blackholing of non-TCP packets larger than mssfix. With kind regards, MD |
From: Gert D. <ge...@gr...> - 2024-09-03 19:42:35
|
Hi, On Tue, Sep 03, 2024 at 07:29:41PM +0200, Marian ??urkovi?? wrote: > on MacOS, ICMP Fragmentation needed messages only work for TCP protocol. > They are never delivered to any UDP application. For this reason, sending ICMP messages is useless for anything else than TCP on MacOS. This is a curious statement to make. If there is anything in your packet path that can not handle 1500 byte packets (like, a 1492 byte PPPoE based Internet router), applications will receive ICMP frag required when sending 1500 byte packets, and will have to deal with them. And this is working mostly well (unless someone filters ICMP), completely unrelated to "OpenVPN". So, bringing in OpenVPN - if you use 2.x, and configure "--tun-mtu 1400", this is EXACTLY what is happening - application generates a 1500 byte packet, operating system looks at the outgoing interface, sees 1400 byte MTU, and the OS will then generate said ICMP packet. I agree that the decision by Connect to do "1500 byte MTU, but generate the ICMP itself" (instead of doing ifconfig with lower MTU) is somewhat questionablex - but for the application, the net result should be the same - packet too big, ICMP message, deal with it. If you accept 1500 byte packets into the tunnel, you'll end up with external fragmentation, which causes more issues overall (due to broken NAT routers, over-eager firewalls, anti-ddos boxes rate-limiting fragments, etc.). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... |
From: <md...@bt...> - 2024-09-03 17:48:18
|
Hi Antonio, on MacOS, ICMP Fragmentation needed messages only work for TCP protocol. They are never delivered to any UDP application. For this reason, sending ICMP messages is useless for anything else than TCP on MacOS. But the main problem here is, that mssfix OpenVPN config option was intended to manipulate solely the MSS parameter in TCP SYN packets and nothing else. It's completely valid approach to configure OpenVPN to send TCP traffic without fragmentation by reducing MSS, but allow full 1500-byte packets for UDP and other protocols. To prevent fragmentation for *all* protocols, tun-mtu should be lowered instead. But for unknown reason, OpenVPN Connect tries to (ab)use completely unrelated config option to achieve the same effect, unfortunately its implementation is not suitable for all operating systems. With kind regards, MD On Tue, 3 Sep 2024 15:53:36 +0200, Antonio Quartulli wrote > Hi Marian, > > I am back on this topic. > > On 17/05/2024 08:10, Marian Ďurkovič wrote: > > [...] > > > Perhaps someone from this group could explain to OpenVPN Connect developers, that breaking OpenVPN and basic networking principles is never a good idea... > > since QUIC packets come with the DF bit set and OpenVPN is sending > back an ICMP packet-too-big, why isn't QUIC just handling that? IT > seems QUIC is ignoring the ICMP message? > > You said OpenVPN Connect is blackholing the packets, but it is > actually sending the ICMP back, so I don't think it can truly be > considered as such. Wouldn't you agree? > > Cheers, > > -- > Antonio Quartulli |
From: Alireza F. <rad...@gm...> - 2024-09-03 17:46:44
|
From: Antonio Q. <a...@un...> - 2024-09-03 14:05:22
|
Hi Marian, I am back on this topic. On 17/05/2024 08:10, Marian Ďurkovič wrote: [...] > Perhaps someone from this group could explain to OpenVPN Connect developers, that breaking OpenVPN and basic networking principles is never a good idea... since QUIC packets come with the DF bit set and OpenVPN is sending back an ICMP packet-too-big, why isn't QUIC just handling that? IT seems QUIC is ignoring the ICMP message? You said OpenVPN Connect is blackholing the packets, but it is actually sending the ICMP back, so I don't think it can truly be considered as such. Wouldn't you agree? Cheers, -- Antonio Quartulli |
From: Gert D. <ge...@gr...> - 2024-08-25 08:56:28
|
Hi, On Sun, Aug 25, 2024 at 06:01:05AM +0000, Peter Davis via Openvpn-users wrote: > I checked the OpenVPN log and saw something like below: That's not part of "the log", it's the status file... > OpenVPN CLIENT LIST > Updated,2024-08-25 09:15:08 > Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since > UNDEF, X.X.X.X:53719,3445,326,2024-08-25 09:14:32 > UNDEF, X.X.X.X:56244,1596,128,2024-08-25 09:14:59 Good question. Might be a setup without client certificates, so no CN. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... |
From: Gert D. <ge...@gr...> - 2024-08-25 08:54:42
|
Hi, On Sun, Aug 25, 2024 at 06:05:49AM +0000, Peter Davis via Openvpn-users wrote: > When you want to connect to an OpenVPN server, but the client cannot connect to the server, what tools and methods do you use for troubleshooting? common sense, client log (--verb 4), server log There's a few typical problems - network connection issues (firewall, NAT rules, server process not running, server IP/port misconfigured in the client config) - this is usually quite clear by not getting any response to connection attempts, and not seeing anything in the server logs. Sometimes "ping", "traceroute" etc. are helpful in figuring out where the packets are lost. - TLS/auth issues, in which case the client *can* talk to the server, but the server refuses to serve this client -> clear from the server logs (and in newer OpenVPN versions, usually also visible in the client logs) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... |
From: Peter D. <pet...@pr...> - 2024-08-25 06:06:07
|
Hello, When you want to connect to an OpenVPN server, but the client cannot connect to the server, what tools and methods do you use for troubleshooting? Thank you. |
From: Peter D. <pet...@pr...> - 2024-08-25 06:01:22
|
Hello, I checked the OpenVPN log and saw something like below: OpenVPN CLIENT LIST Updated,2024-08-25 09:15:08 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since UNDEF, X.X.X.X:53719,3445,326,2024-08-25 09:14:32 UNDEF, X.X.X.X:56244,1596,128,2024-08-25 09:14:59 ROUTING TABLE Virtual Address,Common Name,Real Address,Last Ref GLOBAL STATS Max bcast/mcast queue length,10END Why is it UNDEF instead of username? Thank you. |
From: Gert D. <ge...@gr...> - 2024-08-19 08:40:57
|
Hi, On Sun, Aug 18, 2024 at 07:15:44PM +0200, H H F wrote: > My password manager now all passwords are gone, so makes sense. This sentence does not make very much sense... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... |
From: H H F <hen...@gm...> - 2024-08-18 17:16:07
|
My password manager now all passwords are gone, so makes sense. On Wed, Aug 14, 2024, 9:50 PM Selva Nair <sel...@gm...> wrote: > > > On Wed, Aug 14, 2024 at 2:52 AM Gert Doering <ge...@gr...> wrote: > >> Hi, >> >> On Tue, Aug 13, 2024 at 08:14:23PM -0400, Selva Nair wrote: >> > Nonetheless, on Windows, we could easily add CryptProtectMemory() with >> > SAME_PROCESS access for good measure, especially for those who cannot >> use >> > "--auth-nocache". That will also add some protection to proxy passwords >> > which are always cached for some reason. >> >> Would you be willing to send something? >> > > Will try. Doesn't look as easy as I first thought, but still doable. > > >> >> (proxy auth caching has been reworked in commit 3cfd6f961d5c92bec2, and >> Frank / Gianmarco claim it is behaving better now - that is, caching if >> allowed, and not caching if --auth-nocache is in effect. I have not >> tested all possible variants myself) >> > > As far as I can see, the long-term storage buffer (one that persists > password > across restarts) is cleared if nocache is in effect. A local copy is still > retained for a > long while in establish_proxy_pass_through() as p->up and never properly > cleared. > Also there are some buffers into which password is copied into for auth, > and not > wiped clean after use. > > Not hard to fix, but I do not have a proxy setup to test. > > Selva > _______________________________________________ > Openvpn-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-users > |
From: Gert D. <ge...@gr...> - 2024-08-16 16:52:56
|
Hi, On Fri, Aug 16, 2024 at 09:57:32AM +0200, Ralf Hildebrandt via Openvpn-users wrote: > Under which circumstances is such a "CC-EEN exit message" generated > (and which side generated it)? that's the "control channel explicit-exit notify" message. It is triggered if you have --explicit-exit-notify configured on either client or server, and that side terminates the tunnel (so, client is ctrl-c'ed, or server terminates the client instance due to a management command etc). "CC" only happens for 2.6+<->2.6+ combinations - this is a new addition in 2.6.0, sending the EEN message as proper control-channel message, not as magic data packet (OCC). The primary reason was to make the DCO kernel level more straightforward - it already passes all control-channel packets to userland, but for OCC EEN (old style) extra code would be needed in kernel. It turned out later that receiving and handly OCC EEN is not actually that much code, and we might end up supporting that (for pre-2.6 peers) anyway, but as far as I'm aware no kernel DCO has implemented it yet. </historic note> gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ge...@gr... |
From: Ralf H. <Ral...@ch...> - 2024-08-16 07:57:46
|
We have a client that disconnected and reconnected again (on another of our gateways): 2024-08-16 06:59:22 gw166 openvpn-udp rebxxxdl/2001:16b8:b3b4:5b00:89ba:f323:d919:5b39 CC-EEN exit message received by peer (client: Mac, Tunnelblick, openvpn 2.6.) ... 2024-08-16 06:59:30 gw164 openvpn-udp rebxxxdl/2001:16b8:b3b4:5b00:89ba:f323:d919:5b39 MULTI: Learn: 172.29.224.30 -> rebstadl/2001:16b8:b3b4:5b00:89ba:f323:d919:5b39 (same client: Mac, Tunnelblick, openvpn 2.6.) Under which circumstances is such a "CC-EEN exit message" generated (and which side generated it)? -- Ralf Hildebrandt Charité - Universitätsmedizin Berlin Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration Invalidenstraße 120/121 | D-10115 Berlin Tel. +49 30 450 570 155 ral...@ch... https://www.charite.de |
From: Selva N. <sel...@gm...> - 2024-08-14 19:47:46
|
On Wed, Aug 14, 2024 at 2:52 AM Gert Doering <ge...@gr...> wrote: > Hi, > > On Tue, Aug 13, 2024 at 08:14:23PM -0400, Selva Nair wrote: > > Nonetheless, on Windows, we could easily add CryptProtectMemory() with > > SAME_PROCESS access for good measure, especially for those who cannot use > > "--auth-nocache". That will also add some protection to proxy passwords > > which are always cached for some reason. > > Would you be willing to send something? > Will try. Doesn't look as easy as I first thought, but still doable. > > (proxy auth caching has been reworked in commit 3cfd6f961d5c92bec2, and > Frank / Gianmarco claim it is behaving better now - that is, caching if > allowed, and not caching if --auth-nocache is in effect. I have not > tested all possible variants myself) > As far as I can see, the long-term storage buffer (one that persists password across restarts) is cleared if nocache is in effect. A local copy is still retained for a long while in establish_proxy_pass_through() as p->up and never properly cleared. Also there are some buffers into which password is copied into for auth, and not wiped clean after use. Not hard to fix, but I do not have a proxy setup to test. Selva |