Control: tags -1 + pending
On Thu, Aug 03, 2017 at 11:21:28AM +0200, Bernhard Schmidt wrote:
> stretch-pu filed as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870604
Accepted into p-u, will be part of Debian 9.2 and should be available
shortly on
On 18.07.2017 13:26, Patrick Matthäi wrote:
> Am 18.07.2017 um 13:05 schrieb Patrick Matthäi:
>>> I've browsed through the git commits between 2.4.0 and 2.4.3, these
>>> might be relevant here
>>>
>>> https://community.openvpn.net/openvpn/ticket/812
>>>
Control: forwarded -1 https://community.openvpn.net/openvpn/ticket/812
> I have tested it three times, it is definitly
> https://community.openvpn.net/openvpn/ticket/812 which fixes this issue
Thanks, I'll fix it ASAP.
Bernhard
Am 18.07.2017 um 13:29 schrieb Bernhard Schmidt:
I've browsed through the git commits between 2.4.0 and 2.4.3, these
might be relevant here
https://community.openvpn.net/openvpn/ticket/812
https://community.openvpn.net/openvpn/ticket/887
Are you able to build a
Am 18.07.2017 um 13:05 schrieb Patrick Matthäi:
>> I've browsed through the git commits between 2.4.0 and 2.4.3, these
>> might be relevant here
>>
>> https://community.openvpn.net/openvpn/ticket/812
>> https://community.openvpn.net/openvpn/ticket/887
>>
>> Are you able to build a version with
Am 18.07.2017 um 13:26 schrieb Patrick Matthäi:
Hi,
> Am 18.07.2017 um 13:05 schrieb Patrick Matthäi:
>>> I've browsed through the git commits between 2.4.0 and 2.4.3, these
>>> might be relevant here
>>>
>>> https://community.openvpn.net/openvpn/ticket/812
>>>
Am 18.07.2017 um 12:58 schrieb Bernhard Schmidt:
> The notworking version does nothing like this. This smells like a bug.
>
> What I don't understand is that you claim the VPN endpoint is not
> reachable on the dead nodes (the outer IP I presume). Both nodes still
> have a hostroute towards the
Control: fixed -1 2.4.3-4
Am 18.07.2017 um 10:44 schrieb Patrick Matthäi:
Hi,
thanks for the logs!
> we have got the same issue with all our VPNs upgraded to Stretch now.
> Most VPNs are connected about a 1 GBit/s datacenter connection with each
> other (also same LAN), the other
Am 12.07.2017 um 16:17 schrieb Bernhard Schmidt:
> Am 12.07.2017 um 15:41 schrieb Patrick Matthäi:
>
> Hi,
>
we have got the same issue with all our VPNs upgraded to Stretch now.
Most VPNs are connected about a 1 GBit/s datacenter connection with each
other (also same LAN), the
Hi,
> I also uploaded the current testing version to stretch-bpo and deployed
> it on one host, to see if there is a difference later
BTW, right now the version from Buster (2.4.3-4) is installable on
Stretch just fine, so no need for an official backport if you are doing
a short test.
Bernhard
Am 12.07.2017 um 15:41 schrieb Patrick Matthäi:
Hi,
>>> we have got the same issue with all our VPNs upgraded to Stretch now.
>>> Most VPNs are connected about a 1 GBit/s datacenter connection with each
>>> other (also same LAN), the other ones are connected about a 100 MBit/s
>>> connection.
>>
Am 12.07.2017 um 12:10 schrieb Bernhard Schmidt:
> On Wed, Jul 12, 2017 at 09:35:53AM +0200, Patrick Matthäi wrote:
>
> Hi,
>
>> we have got the same issue with all our VPNs upgraded to Stretch now.
>> Most VPNs are connected about a 1 GBit/s datacenter connection with each
>> other (also same
On Wed, Jul 12, 2017 at 09:35:53AM +0200, Patrick Matthäi wrote:
Hi,
> we have got the same issue with all our VPNs upgraded to Stretch now.
> Most VPNs are connected about a 1 GBit/s datacenter connection with each
> other (also same LAN), the other ones are connected about a 100 MBit/s
>
Please see below for updated logs regarding the issue, from the VPN start to
it's timeout.
1 Jun 04 19:15:13 $hostname NetworkManager[531]: [1496621713.5396]
audit: op="connection-activate" uuid="$uuid" name="$vpn_name" pid=28504
uid=1000 result="success"
2 Jun 04 19:15:13 $hostname
It seemed to take longer (almost exactly an hour since starting the VPN), but
the issue came back up. This was the only message in the logs:
May 25 20:11:51 $hostname nm-openvpn[26356]: WARNING: 'link-mtu' is used
inconsistently, local='link-mtu 1602', remote='link-mtu 1634'
May 25 20:11:51
Hi, could you test this using a wired connection?
On Tue, May 23, 2017 at 10:25:16PM -0400, Prescott Hidalgo-Monroy wrote:
> Despite the update to 2.4.0-6, I'm still experiencing the same issue as
> before.
>
> The only information could find are from these errors from the syslog. It
> took
Despite the update to 2.4.0-6, I'm still experiencing the same issue as before.
The only information could find are from these errors from the syslog. It took
approximately 15-20 minutes for the display to shut off for power saving
(19:57), based off of the first error message.
May 23 20:15:35
On Sun, May 21, 2017 at 06:40:31PM -0500, Prescott wrote:
> Package: openvpn
> Version: 2.4.0-5
> Severity: important
>
> Dear Maintainer,
>
>After the upgrade to openvpn 2.4.0-5 (from *-4), an issue has been
>occuring where after having been connected to the VPN for an
>approximate
Package: openvpn
Version: 2.4.0-5
Severity: important
Dear Maintainer,
After the upgrade to openvpn 2.4.0-5 (from *-4), an issue has been
occuring where after having been connected to the VPN for an
approximate amount of time of around 30-45 minutes, the network
connection will drop.
19 matches
Mail list logo
