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 LAN), the other ones are connected about a 100 MBit/s
>> connection.
>
>> route remote_host 255.255.255.255 net_gateway
> This suggests that the VPN server is inside the netblocks routed through
> the tunnel, right?
If I understood you correct: yes - all VPNs are "clients"
>
> When the problem happens, can you check whether the static /32 route
> towards the VPN server still exists and points outside the tunnel.
We will check if it occurs again and give you the output of "ip {a,r,l}"
Anything else needed?
>
> Please also check a couple of minutes before the ping timeout whether you
> see anything network related. Are you using ifupdown or NetworkManager
> on the client?
>
> Bernhard
>That is mostly hard to check, because that are many endpoints and clients. One client is located in the hosteurope network, which had got a maintainance this night (with a short outage), but also many other customer VPNs (sophos, self hosted VPNs and so on) were affected from different locations and links. So I dont think that this is the whole thing triggering this bug. I also uploaded the current testing version to stretch-bpo and deployed it on one host, to see if there is a difference later -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */
