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. >> >>> 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" No, the question is whether the outer IP address (the IP address of the VPN server, "remote_host" here) is within the network that is routed through the VPN tunnel. Example: VPN-Server at 10.1.1.1 routed network 10.0.0.0/8 A client has a wired connection with a default route to 1.1.1.1 default via 1.1.1.1 dev eth0 You can reach 10.1.1.1 through that default route. However, when the tunnel is established the routing table would look like this default via 1.1.1.1 dev eth0 10.0.0.0/8 via tun0 Traffic to 10.1.1.1 would be sent to tun0, encapsulated in OpenVPN into a packet to 10.1.1.1, which would be sent to tun0, ... So the statement above would create a more-specific route for the remote address through the wired connection default via 1.1.1.1 dev eth0 10.0.0.0/8 via tun0 10.1.1.1/32 via 1.1.1.1 dev eth0 The problem is, when eth0 flaps both routes are deleted, but only the default route is recreated. So you end up with the described internal routing loop until you restart OpenVPN (which recreates the /32 route). > I also uploaded the current testing version to stretch-bpo and deployed > it on one host, to see if there is a difference later Ah, I was already wondering who did. Bernhard
