I’m trying to remove old route from Azure P2S VPN config. It’s no longer in use and conflicts with recent deployment in new office.
How does Azure VPN decide which routes to add on a Windows client? I’m not talking about custom routes I can add myself, I’m talking about the default ones.
It looks like routes are inherited from the configuration on all local gateways that have S2S setup to virtual network gateway in Azure. If the same virtual network gateway is used for P2S, the subnets from local gateways are all advertised as VPN routes.
I made sure the subnet for the route I’m trying to remove is no longer present in local network gateway config, but somehow, it’s still getting pushed by Azure VPN client in P2S connections.
I redownloaded the profile and set it up again, but that didn’t resolve the issue either (I didn’t expect that to be honest, the routes are not included there).
I can’t remove the virtual gateway and re-configure it from the ground up, as this is used in production.
EDIT: I also tried explicitly excluding the route, as described in MS documentation, but that had no effect. Looks like it’s a bug, which has been reported over a year ago in this github issue. Closed without resolution.
RESOLVED: Thanks all for your suggestions and kudos to u/SoMundayn for pointing me in the right direction. Resetting virtual network gateway did the trick, and it refreshed P2S VPN routes inherited from local network gateway.
Tried rebooting the VNG from the portal?
Is the route you’re trying to remove advertised to the VNET? If so, does it need to be on the the VNET?
I don’t think you can do this we ran into this issue and had to create separate vnets,gateway,vngs.
Check virtual van hub they were working on a fix for it in that but I haven’t tired it in a year or so. But you’ll probably want to raise a support ticket or rebuild your vng if you don’t need multiple p2s and s2s on one gateway
This is probably a route learned from the LGW (really a wild guess here). But you can look at the ‘Effective Routes’ on the NIC of the VM. See if you can find it there, feel free to dm me if you follow up questions.
You can check the LNG configuration and the routing table applied on the gateway subnet
I would try this as well. I usually need to reboot my gateway when I change routes so that they take effect on clients. As a result, I typically plan these changes after hours so that there are no interruptions to the user experience.
That was it! Thanks a lot. I feel dumb I didn’t think of this earlier. Resetting VNG did the trick, and it refreshed P2S VPN routes inherited from local network gateway.
No, it’s not. I don’t want to configure it yet.
Thanks, but it does not address the issue I’m describing. My specific scenario is one isolated vnet and a branch office (S2S). How do I remove a route for branch office subnet, which had been added there during initial configuration, and later removed? Am I expected to delete the gateway and set it up again to achieve that?
I’m not sure what you mean exactly. How would it be advertised to the vnet?
The only way that comes to my mind is via Azure Local Network Gateway for S2S connection. I removed that subnet from there, but it had no effect on P2S connections. Azure VPN P2S client still adds that route on endpoints.
And on p2s configuration you have a section with “additional routes to advertise”
What does the client route table say? All S2S routes to the gateway will be advertised to the P2S. You either exclude the unwanted route, or you disconnect the unwanted S2S. The route table on the client should have 2 entries for the excluded route - one will have preference for your home router IP.
“Made sure the subnet for the route I’m trying to remove…” I’m not sure what this means.
It means I removed the subnet from local network gateway, so it should no longer be advertised as a route.
The route table on the client says exactly what I included on the screenshot from Azure VPN client. All routes are added, including the one that should no longer be there.
Excluding the unwanted route does not work at all. I linked a GitHub issue where several people reported the same problem.
Maybe try using different terms? You add subnets to virtual networks, and you add gateways to subnets. I don’t see how you can “remove the subnet from local gateway.”
The screenshot is from the Azure VPN client. The Windows route table can be viewed with ‘route print -4.’ The route table will show your excluded route as having preference on the local gateway. You can’t delete the route unless you delete the S2S connection to the gateway that’s advertising it. The override simply tells Windows to send it locally. Are you using tunnel-all?
As for the GitHub, the screenshots show as I describe. This poster confirms it:
“Exclusion is working for me as expected. Albeit, I do see the same behavior with my local route table, as described by Sweggle. However, a test connection to a known private IP, in the subnet I’m excluding via the VPN XML, does not route through my VPN interface. It attempts to route through my local interface and subsequently fails.”
The route I’m trying to remove is for the onprem subnet that was setup on local network gateway for S2S link. It has been removed but is still advertised on P2S connections using the same virtual network gateway. I explained that already in the post. It’s not an Azure subnet, it’s not added to the virtual network there. It only existed on the local network gateway.
You picked one comment from that github page, while there are dozens of other people reporting an issue with exclusions. The same issue I’m experiencing here.
Yes, I do know how to check local routes on a Windows client, and it does still show an entry pointing to the VPN gateway for the subnet I’m trying to remove. Even after adding an exclusion. The traffic is still routed through the VPN gateway, not the local gateway as expected.
I appreciate your input and help, but your responses sound a bit pretentious, like you’re trying to prove I either don’t understand a specific network concept or made an error somewhere. Which could be true, but comes across as a bit rude, so thanks again, but I’ll try troubleshooting points raised by other people now.
