Today's spanner in the network is Azure VPN Client

Bulb

So I was testing this Azure VPN so I can close the public endpoints of various things and can still access them through the private endpoints for debugging purposes when needed. So I set things up, connect and … the rest of my internet stops working. Well, it turns out that

The VPN to the company network, that I already have set up, configures default¹ route through gateway in the 172.27.0.0/16 network. And configures nameservers that are in a completely different 192.168.0.0/16 segment well beyond that gateway.

So now I connect to this Azure VPN, and I only tell it to route 10.231.80.0/20 (that I assigned to the vnet in Azure) and 10.231.96.0/20 (that I assigned to the VPN itself). But for some reason it adds explicit routes to the nameservers, on the interface of the first VPN that defined them, but without the gateway. So instead of making sure they keep working it makes sure they break.

… thinking about it I've also seen similar behaviour with a different VPN into a different such Azure segment, so it might be a bug in some generic Windows 10 subsystem or library that the VPN clients use to set up their routing.

¹ Well, forced; 0.0.0.0/1 and 128.0.0.0/1 to take precedence over the normal default route 0.0.0.0/0)

PS: Does anybody have an idea where to report it as a bug report so it gets actually treated as bug report?

HardwareGeek

@Bulb said in Today's spanner in the network is Azure VPN Client:

it might be a bug in some generic Windows 10 subsystem or library

report it as a bug report so it gets actually treated as bug report

Sent in, sent back, queried, lost, found, subjected to public inquiry, lost again, and finally buried in soft peat and recycled as firelighters?