A scenario I recently encountered was a customer using Azure VPN gateways to host site to site connections with third-party vendors. In this post I am going to show you how I used Azure Route-maps to secure learned routes from the vendor VPN link.
The configuration for the environment looked like this:
BGP was configured between the gateway and the vendors BGP host. The vendor had a requirement to use BGP to allow the third-party vendor to manage their maintenance windows.
This presented a small problem to the environment. As the S2S gateway was part of an Azure secured virtual hub, routes learned from the gateway are shared automatically with the virtual hub and then on to the rest of the Virtual WAN. While the firewall would protect traffic, the BGP exchange was not filtered in any fashion. A malicious actor on the vendor side could inject additional routes into the environment causing havoc within the virtual WAN. As the route exchange is automatic and the S2S gateway is simple in its configuration, how were we to control what routes we would learn from the vendor?
Enter Azure Route-maps.
What are Azure Route-maps?
Route-maps allow you to control route advertisements and routing for Virtual WAN hubs. They provide greater control over routing for Azure Virtual WAN connections. This includes site-to-site VPNs, point-to-site VPNs, ExpressRoute, and virtual networks.
Azure Route-maps allows us to apply access lists to our routes much the same way you can control routes on a physical router. Using a small demonstration environment, I will show you how to secure the routes being advertised via BGP.
The test environment
To demonstrate how route maps work, I have built a small test environment:
- A virtual WAN with:
- virtual hub
- site to site VPN gateway
- virtual network
- connected virtual machine
- A remote VPN gateway connected to
- a local network connected to another peered network
- the peered network providing a range of addresses
Confirming the effective routes on the connected virtual machine, we can see all of the routes coming from the local hub and the remote gateway:
Adding any additional network to the connected VNET is automatically shared with the virtual hub and can be seen by the virtual network interface.
How do Azure Route-maps work?
From a high level, each route-map is a list of rules that are applied to the route information. Like firewalls, these rules are processed in order and you have the option to stop or continue processing when a rule is matched. Once you have created your ruleset, you then apply the map to a specific link in the hub to apply the rules to that link.
Note: When creating your first route-map for a hub, it takes up to 45 minutes to prepare the hub to leverage route-maps.
My problem
As you can see from our diagram above, I am learning multiple routes from the VPN gateway. But we only want to learn one network and ensure that no other networks come through. For the purposes of this demonstration, I only want to learn 10.7.1.0/24 from the VPN, all other networks are to be dropped.
Creating the route-map
Route-maps are scoped to a virtual hub and can be accessed via the Routing->Route-maps blade for the hub:
We are going to first create our route-map:
Once we’ve given it a meaningful name, I then need to create the rules that will allow us to only receive the route 10.7.1.0/24. Remembering that rules are processed in order, I am going to need two rules. One that identifies the route we want to keep and one rule to drop anything that doesn’t match.
Matching the required route
Creating my first route-map rule I give it a meaningful name. As we want to stop processing when we find the required route, I select “Terminate” for “Next Step”.
Match conditions
“Match conditions” are the criteria I need to meet for my specified route. This is relatively straight forward, I am going to base my selection on a route prefix that equals my route of 10.7.1.0/24:
Actions
This is where things are a little trickier. Only two options are available, to modify the routes in some way or to drop the routes altogether. The simplest option is to modify the AS Path of the route. Once I selected modify, I used the option to prepend one more AS number to the front of the route path:
To avoid confusion, I have decided to use the same AS number as supplied by the vendor.
Blocking the remaining routes
To block the remaining routes is a much easier prospect. Firstly I’ve given the rule a meaningful name and selected “Terminate” for next step:
Match conditions
The “Match conditions” are very simple for this rule. If no information is provided, then all routes are matched:
Actions
As we want to not accept any other routes, I selected “Drop” as the action for this rule:
Once saved, I now have two rules set for the route-map, one to match and prepend an AS number to the allowed route and one to drop all other routes.
Apply Route-maps to connections
Now that I’ve created a route-map, it needs to be applied to a connection. Selecting “Apply route-maps to connections” in the Route-maps blade, I am given the options to apply route-maps in a particular direction and the connection I want to use.
As the routes are coming from the vendor space, firstly I select my newly created route-map for the Inbound route-map. Then we need to apply this inbound route-map to the S2S VPN connection relevant to the vendor connection:
I now have 1 inbound connection associated with my new route map:
Returning to my test virtual machine, we can now see that only 1 route, 10.7.1.0/24, is coming from the S2S VPN Gateway:
As you can see, I have successfully created a route-map in my Virtual Hub, limited it to allowing 1 route only and applied it to my S2S VPN connection. This means that any other routes that the vendor tries to share with me will be blocked, protecting my internal route tables from being manipulated either accidentally or maliciously by the vendors connection.
