Re: [Openvpn-devel] [PATCH applied] Re: Selectively reformat too long lines

2020-10-02 Thread Vladislav Grishenko
Gert, thank you > We need to cover this in the style guide, to make clear which variant is preferred > (if the text fits into one line if putting it onto its own line, this is a different > story). Indeed, it needs to be written down, including what to do with existing code on changes near

[Openvpn-devel] [PATCH] Add CRL extractor script for --crl-verify dir mode

2020-10-02 Thread Vladislav Grishenko
When --crl-verify is enabled, specified CRL file gets reloaded on every client connection. With huge CRL files it may take a significant amount of time - seconds and tens of seconds, during which OpenVPN is blocked and can't serve existing and/or incoming connections due its singlethread nature.

[Openvpn-devel] [PATCH applied] Re: Selectively reformat too long lines

2020-10-02 Thread Gert Doering
Your patch has been applied to the master and release/2.5 branch. I am not particularily happy about merging this sort of "cleanup" patch so late before 2.5 release - *but* I have very carefully checked that it's really all just re-wrapping long function calls, or long text strings, so the danger

[Openvpn-devel] [PATCH] Fix redirecting of IPv4 default gateway if connecting over IPv6.

2020-10-02 Thread Gert Doering
Commit aa34684972eb0 fixed a long-standing bug in setting the "route-list" flag RTSA_REMOTE_HOST for IPv4 ("we have a well-defined remote_host == VPN server IP address") even if connecting over IPv6. Unfortunately the logic in redirect_default_route_to_vpn() was also wrong, and refused

Re: [Openvpn-devel] with IPv6 VPN connection, IPv4 traffic does not get router over VPN

2020-10-02 Thread Gert Doering
Hi, On Fri, Oct 02, 2020 at 03:26:29PM +0200, François Kooman wrote: > The log shows this "NOTE": 2020-10-02 06:20:07 NOTE: unable to redirect > IPv4 default gateway -- Cannot obtain current remote host address I have a patch for that one already, which is fairly obvious: diff --git

Re: [Openvpn-devel] with IPv6 VPN connection, IPv4 traffic does not get router over VPN

2020-10-02 Thread Gert Doering
Hi, On Fri, Oct 02, 2020 at 03:26:29PM +0200, François Kooman wrote: > After testing connecting over native IPv6 to the VPN server, it turns > out the IPv4 traffic is not routed over the VPN. This worked in older > versions of OpenVPN (2.4.x) but no longer in OpenVPN 2.5rc2. I am > testing

Re: [Openvpn-devel] with IPv6 VPN connection, IPv4 traffic does not get router over VPN

2020-10-02 Thread Gert Doering
Hi, On Fri, Oct 02, 2020 at 05:05:33PM +0200, Gert Doering wrote: > I'll open a "blocker" ticket in trac... https://community.openvpn.net/openvpn/ticket/1332 JFTR gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest

Re: [Openvpn-devel] with IPv6 VPN connection, IPv4 traffic does not get router over VPN

2020-10-02 Thread François Kooman
On 10/2/20 5:12 PM, Arne Schwabe wrote: Is that a host that does not have a ipv4 default gw at all? Like IPv6 only connectivity? It does, it has both IPv4 (RFC 1918) and IPv6 (Public IP) connectivity behind a FritzBox. Both IPv4 and IPv6 work fine (checked it using v6.de) without VPN. When

Re: [Openvpn-devel] with IPv6 VPN connection, IPv4 traffic does not get router over VPN

2020-10-02 Thread Arne Schwabe
Am 02.10.20 um 15:26 schrieb François Kooman: > Hi all, > > After testing connecting over native IPv6 to the VPN server, it turns > out the IPv4 traffic is not routed over the VPN. This worked in older > versions of OpenVPN (2.4.x) but no longer in OpenVPN 2.5rc2. I am > testing with Windows 8.1,

Re: [Openvpn-devel] with IPv6 VPN connection, IPv4 traffic does not get router over VPN

2020-10-02 Thread Gert Doering
Hi, On Fri, Oct 02, 2020 at 03:26:29PM +0200, François Kooman wrote: > After testing connecting over native IPv6 to the VPN server, it turns > out the IPv4 traffic is not routed over the VPN. This worked in older > versions of OpenVPN (2.4.x) but no longer in OpenVPN 2.5rc2. I am > testing

[Openvpn-devel] with IPv6 VPN connection, IPv4 traffic does not get router over VPN

2020-10-02 Thread François Kooman
Hi all, After testing connecting over native IPv6 to the VPN server, it turns out the IPv4 traffic is not routed over the VPN. This worked in older versions of OpenVPN (2.4.x) but no longer in OpenVPN 2.5rc2. I am testing with Windows 8.1, but the same was reported on Windows 10. This is

[Openvpn-devel] [PATCH applied] Re: compat/lz4: Update to v1.9.2

2020-10-02 Thread Gert Doering
Your patch has been applied to the master, release/2.5 and 2.4 branch. (Even though I agree with Arne that it sounds like a good plan to just kick out compat-lz4 in master, given that the times have changed quite a bit compared to the initial import 6.5 years(!) ago, for consistency reasons I

Re: [Openvpn-devel] [PATCH] compat/lz4: Update to v1.9.2

2020-10-02 Thread Arne Schwabe
Am 02.10.20 um 12:03 schrieb Илья Шипицин: > > > пт, 2 окт. 2020 г. в 13:51, Arne Schwabe >: > > Am 01.10.20 um 17:46 schrieb David Sommerseth: > > It's a long while since the bundled lz4 library has received an > update. > > It pulls in a lot of

Re: [Openvpn-devel] [PATCH] compat/lz4: Update to v1.9.2

2020-10-02 Thread Илья Шипицин
пт, 2 окт. 2020 г. в 13:51, Arne Schwabe : > Am 01.10.20 um 17:46 schrieb David Sommerseth: > > It's a long while since the bundled lz4 library has received an update. > > It pulls in a lot of various fixes and enhancements, some of the changes > > fixes compiler warnings and hardens the code a

Re: [Openvpn-devel] [PATCH] compat/lz4: Update to v1.9.2

2020-10-02 Thread Arne Schwabe
Am 01.10.20 um 17:46 schrieb David Sommerseth: > It's a long while since the bundled lz4 library has received an update. > It pulls in a lot of various fixes and enhancements, some of the changes > fixes compiler warnings and hardens the code a bit too. > Ack for release/2.5. I double checked

Re: [Openvpn-devel] [PATCH v3] Speedup TCP remote hosts connections

2020-10-02 Thread Arne Schwabe
Am 02.10.20 um 00:53 schrieb Vladislav Grishenko: > For non-blocking TCP/Unix connection, OpenVPN checks was it established in > loop and if not - sleeps or handles management for next one second. Since > the first check is made right after the connection attempt, it will likely > be always