With the implentation of an Azure CSR 1000v Router, we reviewed how we wanted our traffic to flow. We decided, all sites would terminate into the CSR and back to our Head Office with DMVPN, this gave us some redundancy in the event of a failure at either HQ or Azure.
The inbuilt Azure VPN would remain in place between itself and HQ, traffic between the two sites would use this. Whilst remote sites would forward its traffic out of the CSR router. As sites were migrated over to the DMVPN solution, we added them into the Route table that had been applied to all subnets bar the dedicated CSR subnet that we had created within our vNET (6 in total)
The route table would be used to forward any traffic destined for the /24 networks we defined, to the internal IP of our CSR router.
we set this up with a 10.0.0.0/8 traffic to forward to the virtual gateway (which led to the original Azure VPN). Then the more specific subnets (/24 in the above example) takes precedence.
Once I have implemented the ASAv into our environment – an additional post will cover the use of route tables for this feature to filter traffic.
Implementing Cisco CSR router into Azure turned out to be quite a learning curve. Originally there was multiple images available on the Azure marketplace, and there was multiple versions of conflicting documentation around the features/capabilities on what was supported.
Luckily, this looks like its being sorted out. There are now 2 images available on the marketplace, one of which is for the DMVPN transit VNETs.
When building the CSR, we assigned an entire /24 within the subnet from our /20 VNET. We did this just to separate the traffic which we could then lockdown access to remove any unnecessary changes.
IMPORTANT – Something that I forgot to do and it took alot of faffing around to get our traffic forwarding through the CSR.
On your Network interface card for the CSR > Go to IP Configurations
Here you would add additional IPs if required
But you also have the option for IP Forwarding Settings > Enable this, I think it requires a reboot if I remember correctly. and then you should be able to get traffic from one side of the interface to another
Currently the production vNet is a /20. This has been broken into 2 segments of /24’s at the moment, one for standard production VMs, the other for the DMZ.
A new /28 subnet will be created within the same vNet. This allows for 11 IP addreses to be assigned (Microsoft Reserve 5 addresses for backend). 11 IP’s is over the requirement of what we need, however the next option is 3, which is under our requirements.
Network Security Group
The NSG we use is assigned at subnet level. I do not tend to use them directly onto the network cards unless we are trying to lock down the VM from what would be the equivalent of Layer 2 devices.
We allow ports: 25,42,135,137,139,389,636,88,53,445,9389,5722,464,123,138,67,1024-5000,49152-65535
To domain controllers that are specified in the Destination IP range