Home / Nerdio Academy / Nerdio / Nerdio Fundamentals: Networking

Nerdio Fundamentals: Networking

0 commentsJune 16, 2019Videos

Joseph Landes
In this session, we are going to discuss networking in Dionne for Azure. We’ll talk about VPN gateway and its associated pricing, how to add VPN connections, role-based versus policy-based VPNs, firewalls and firewall rules, and IP address costs. A very important topic to understand when considering how to build a successful cloud practice in Microsoft Azure. Enjoy the session.

Vadim Vladimirskiy
We will be talking about networking and the various sub components of that in the NAP. So, first thing is let’s go into NAP and take a look at what’s available under networking. We have three modules. We have what’s called firewall, VPN connections, and on ramp regents.

Vadim Vladimirskiy
A quick reminder from an Azure perspective how all of this works. Let’s start with VPN connections. So, in Azure, a VPN connection is configured via something called a virtual network gateway. So by default when you provision an Azure environment, there is a virtual network as you remember, and then in order to get VPN to work you have to add this service called the VPN gateway. VPN gateway is a module like this. You can click add to create the new gateway. You have to specify a subnet which is going to be sort of a section of the complete VNET that is going to be plugged into.

Vadim Vladimirskiy
And then once the VPN gateways configured, then you can add a VPN connections, policies or whatever name it goes by. So basically, when you add the connection, that’s the definition of allowing another site to connect to your VPN from a site to site perspective. We’ll be talking about site to site VPNs today, not point to site. Those are not really commonly used in the typical Dionne deployment because there’s many other ways of getting to the data without having to rely on VPN.

Vadim Vladimirskiy
Site to site VPN, you’re doing that through a VPN gateway. Each VPN gateway has a subnet that it gets placed in. Let me show you, just remind you how this is priced. So we have Azure VPN pricing. There are different SKUs for the VPN gateway and the way that actually works on the back end is there is a VM that is a managed VM that comes up as the VPN gateway and manages the VPN connection. So by default, there isn’t like a firewall, which typically in a typical deployment, you’d have a SonicWall or FortiGate or Sophos. If it was on prem, that firewall device would handle the site to site VPN connectivity. In Azure by default it doesn’t exist. So when you create the gateway you basically are spinning up a VM that Microsoft manages and gives you basic interface into it in order to create policy/connections into it.

Vadim Vladimirskiy
So, these are the different SKUs. Let’s look at monthly pricing. The one that’s the cheapest, it’s called the basic, it’s about $27 per month. And the parameters are such that it gives you a hundred megabits of aggregate bandwidth and you can have up to 10 site to site tunnels and 128 point to site tunnels, which not really relevant to us, but 10 site to site tunnels. And then, if you need more throughput or more tunnels, you can upgrade to larger VPN gateways. And again, these are going to be bigger VMs that Microsoft provisions and manages for you. You don’t see this as a VM, you see it as a managed object like this. Here’s VPN gateway. It’s a managed object. You can go in and do your configuration.

Vadim Vladimirskiy
Okay, so that’s what it looks like on the back end. On the front end from a nerdier perspective, when the environment spins up, if it’s an enterprise environment, it will have VPN turned off, so this button will be set to off. You can then turn it on and then turn it back off. If I were to turn it off right now, it would delete all the connections and the VPN gateway itself. If it was off and I click to turn it on, it would go in and create this gateway, create the subnet and give me a VPN connection screen that would have no connections listed.

Vadim Vladimirskiy
I would then be able to click add connections and add the new one. This process takes about an hour, I think in order to enable VPN. So the process of provisioning a new VPN gateway takes about an hour. So keep that in mind when doing a deployment, it’s an important thing to schedule. It’s non-disruptive to anything that’s going on in the environment. But it does take some time.

Vadim Vladimirskiy
An important thing to remember that it gets provisioned initially as a basic gateway, which is this cheapest $27 per month with a hundred megabit with 10 tunnels. But this can be changed. So for instance, if someone wants a larger VPN gateway, they can come in here and they can upgrade the SKU. You can see some of these SKUs don’t have the same names as these. And the reason is Microsoft Azure switched from an older legacy deployment to a newer deployment, so the new deployment uses these types of names. The old deployment use these types of names. The environment that I’m in right now is the older deployment one. So that’s why I’m seeing these. But any newly provisioned gateways will have the newer SKUs.

Vadim Vladimirskiy
So, somebody could go in on the back end and upgrade the VPN gateway if they wanted to. And then transparently to the NAP. You don’t really see anything here that tells you what kind of gateway it is. But being able to make this change on the backend would allow one to upgrade the throughput if needed. I don’t think we’ve had any partners that needed higher throughput, a hundred megabits for VPN is generally sufficient, but that is something you can turn up and then turn down when needed. Remember there is a different costs associated with the different SKUs.

Vadim Vladimirskiy
Okay. Now, when you have the VPN enabled and you’re able to add the connection, you click add connection and you’re presented with a screen which asks you for four pieces of information. You give it a name, you give it the IP address of the VPN on the other side. So this would be a local SonicWall, Sophos, what have you, as far as a Meraki or whatever kind of firewall is on the other end of the connection. You then specify the local IP and it’s subnet mask, right? So, this would be 192.168.1.0/255.255.255.0. This would be an example of the local configuration of a VPN tunnel. And then you click save. It takes a couple of minutes, maybe a minute or so, it will create a connection under here. So there will be a connection like this.

Vadim Vladimirskiy
And then once the connection is created, it will show a pop up that is going to have the necessary configuration that can be plugged into the local firewall and the system will work from there. So let’s take a look at what that looks like. It will always use by default from NAP when you submit a connection creation request from NAP, it’ll use IPE V2. It’s going to use a route-based policies or route-based connections. It’s going to randomly generate the pre-shared key. It will use the default Dionne LAN subnet and the IP address assigned to the VPN gateway.

Vadim Vladimirskiy
So if we go in here and we look at this particular gateway, we can see the IP address. It’s not the same one that’s here because I’m in different tenants, but you get the idea. And then this is the information we typed in on the previous screen when we were adding a VPN connection, so this is the LAN subnet and this is the public IP of the local gateway. And then it will use these best practice phase one and phase two proposals and authentication and encryption methods. And what you need to do is go in onto the local firewall and duplicate all of these settings and assuming that your local firewall supports IPE version two and route-based connections, this is all you need. Once you do that and give it a couple of minutes, it’s going to connect and the configuration will will sync up and you’ll have an a VPN tunnel that’s running.

Vadim Vladimirskiy
A couple of things to keep in mind. Number one, Azure requires you to have a static IP address on the other end of the VPN connection. So it’s static IP on both ends. That’s because it’s using main mode. In other firewalls we’ve worked with, sometimes aggressive mode support it, in which case you can use dynamic IP on one of the ends being the the local end. In this case, you must use a static IP on both ends. So, if the customer doesn’t have a static IP address on their end, then it is something that’s going to prevent you from being able to set up a VPN tunnel, VPN connection from Azure.

Vadim Vladimirskiy
The second thing to keep in mind is there are two types of IPE policies. There’s route-based and policy-based. Route-based is sort of the more functional, more flexible, newer kind of standard that Azure prefers. It is something that they would recommend you use if you look the documentation. policy-based VPNs are commonly used by certain very popular Meraki VPN devices of Meraki firewalls. And policy-based VPNs are supported by Azure, but there are a bunch of limitations and I’ll go through those in a second.

Vadim Vladimirskiy
But when you’re using policy-based connections, you cannot configure them from the NAP. So there is a document out there that Kevin and the team often refer to and give links to, to partners when they have Meraki firewalls. They do not support route policy-based VPNs, but only policy-based ones. And then that document basically walks you through sending up Azure and plugging it into an existing firewall that has a VPN. However, even if you are using a policy-based gateway, you will still see the connection listed in the NAP, but you can’t edit it and you cannot add a new one. So just keep that in mind. That has to be done natively in Azure.

Vadim Vladimirskiy
The other limitation is although with route-based connections, you can add up to 10 site to site tunnels per gateway or 30 or more depending on which gateway you go with, when you’re using policy-based ones, I think it’s only one per gateway. So if you have more than one VPN connection and you’re using policy-based VPNs, you need to create multiple gateways. It gets really complex really quickly.

Vadim Vladimirskiy
Okay, so that is how VPN is enabled and configured. You can also edit the settings or remove them. So very simple. Again, editing the settings is simply editing these fields that we filled out initially and removing a VPN as the name implies, obviously just deleting them.

Vadim Vladimirskiy
Let me show you one other thing in the notification section. If we go to notification section, there is an alert that can be sent for network operations. So whenever a VPN is added, a VPN is deleted, any sort of networking modifications are made, this will trigger an email notification from the NAP if this is turned on, but it will also trigger notification when the VPN status changes. What that means is if the VPN goes down, so if the status changes from let’s say from connected to connecting or disconnected or whatever other status or vice versa, there’s going to be an email triggered to whoever is listed on that notification screen or multiple people if that’s how it’s configured. So it’s a really convenient way of allowing an MSP to maintain tabs, keep tabs on the various VPNs that their customers have. So if a the status changes from connected to connecting or something else, there’ll be an email that goes out to alert the MSP. That is a setting that’s turned off by default, so somebody would have to come in and actually turn it on.

Vadim Vladimirskiy
Okay. That is all I have on VPNs. Firewalls. So, on their network and firewall, what you see here is a pretty familiar list of rules that is sorted by the subnet or the zone LAN versus DMZ. If you’ll recall, the way this is configured is we have a virtual network which is a 10125/16 and then we have it segmented into two subnets. We have the LAN subnet, which is 10125/17 and then 10.125.254/24. We have certain hosts in the DMZ, certain hosts in the LAN. You recall that you can go into the servers module, click on manage IP action and then change which subnet and individual server resides in. And then once you go into the firewall settings, what’s happening is there’s actually a set of rules which are grouped into a network security group, and NSG, and that NSG is tied to a subnet.

Vadim Vladimirskiy
So there’s a subnet called LAN. There is an NSG that is called LAN-NSG that contains all of these firewall rules. There is a similar one subnet called DMZ. There is a network security group called NSG-DMZ with all of these rules that’s tied to the zone and then any VM you place in either one of the zone, by default will have all of these rules apply to that VM or more precisely to the virtual network card of that particular VM.

Vadim Vladimirskiy
Okay, so a few things to point out. You’ll notice that a few of these rules have a tag in front of them in square brackets called system and these are not editable. You cannot really make any changes to them. If you add any new rules, you will see that they will not have a system tag, they will be clickable. They will have an edit or delete button next to them. So that’s how you know which ones are system in which ones are not. Okay? So this is the set of rules that’s defined by default. There are certain rules that allow traffic come in from LAN into the DMZ. For example, from LAN to the RD gateway on HTTPS port, from LAN to the RD gateway on the RDP port, from our network into the DMZ to be able to manage those systems, et cetera.

Vadim Vladimirskiy
And then, from the DMZ to LAN, you’ll see some connectivity. So like for example, this proxy 01, which is a ADFS proxy in the DMZ, can have traffic coming from the Internet into it and then the traffic can be tunneled from that server to DCO1 which is on the LAN. So really no public internet traffic ever comes into the LAN by default, only goes into the DMZ and then from DMZ into the LAN.

Vadim Vladimirskiy
Now, if you want to configure additional firewall rules, you can click on add rule and then we’ll look at that in just a minute, but before you do that, that’s important to look at this section, which is the public IP addresses section. So, you’ll recall in Azure there are two types of public IP addresses. We only use one of them. There is a dynamic IP address and a static IP address. A dynamic IP address doesn’t really have an IP V4 address. It has a DNS name and that the DNS name that’s going to be at the Microsoft managed DNS zone is going to resolve to an IP address. That DNS name will be static. The IP address that it’s going to resolve to is not necessarily going to be static. Most likely it’s going to change. Therefore, we don’t use them just for simplicity purpose.

Vadim Vladimirskiy
Everything in the NAP, when we talk about public IPs means we’re using static IP addresses. Static IP addresses are basically an actual IP address. They’re not continuous, so if I create one and then two and three, they may or may not be within the same subnet. They may or may not be one after the other. There is now a capability of doing something called, it’s not listed on this screen, but there is a way now that for whatever reason you needed a block of IP addresses that were contiguous, you can actually ask them to provision that to you. I think this may be it. Yeah. There we go. Public IP prefix. Public IP prefix is a range of contiguous public IP addresses. There is an additional charge to get those on top of the cost of the IP address, I believe.

Vadim Vladimirskiy
Okay, so the IP addresses are here. There are about, I think like between three and $4 per month per IP address. Our default deployment has four IP addresses by default. There is one for the ADFS proxy. There is one for the RD gateway, one for DC01, one for FS01. This is a performance probe that’s not enabled by default. It’s only enabled if you turn on visual synthetic monitoring and then that’s the fifth one that gets allocated.

Vadim Vladimirskiy
Okay, now why did these exist? The reason they exist is because if you want to communicate from the public internet directly to a particular VM, you need a public IP address. Now, adding a public IP address does not mean that the VM is publicly accessible. By default, even if you have a public IP address, unless there is a firewall rule that allows traffic to come in to that public IP address from the internet, you need both, right? So you need the public IP address and then you need the rule that allows the system to come in. Why is that? Because if you look on the LAN, you have this default rule with the lowest priority, which means it’s the last one that gets evaluated that says block all DMZ traffic to LAN. You have a similar rule that says block all other DMZ to LAN. So basically, these deny rules will catch everything that is not explicitly listed as allowed. So again, it’s safe to add an IP address to a particular VM because that doesn’t expose it to the Internet unless you also create a firewall rule for that purpose.

Vadim Vladimirskiy
So okay, these exist, you cannot edit them. What you can do is click on add IP. This is now going to enumerate all of the VMs in the account that do not already have an IP address associated with them. I believe you can associate only one IP address per virtual network card, which is associated with the VM. So here you’ll see primarily desktops are listed, right? Desktops generally sit on the LAN and they don’t have public IP addresses. But let’s go ahead and add an IP address to RDSH01. Okay, so this gets submitted as a task, in a couple of minutes you’ll see it listed here. It’s going to be editable, so you can edit it, you can delete it, you can disassociate it, which means the IP address stays in place, it’s allocated and the customer still being charged for it, but it’s not tied to a particular VM. So you can disassociate or re-associate an IP address.

Vadim Vladimirskiy
Okay, now why would you want to give an IP address to a VM, even if you’re not going to be allowing any Internet traffic to it? And the answer is that if you don’t have a static IP address, for example, on an RDS session host and you’re browsing the internet, the source IP that the Internet is going to see your traffic coming from is going to be coming from a dynamic block within Azure.

Vadim Vladimirskiy
So first of all, if you go to, what is my IP, every time you go there, you may be coming from a completely different IP address. So if you have any applications that require white listing where they want to know the IP address you’re coming from, that’s not going to work because every time you are going to be coming from a different IP address. And adding a static IP address to a particular VM actually makes it so that becomes your source IP for any traffic that gets originated from that VM. Okay? So that’s reason number one. If you have an application that requires some sort of white listing, that that is very useful to be able to assign an IP address to a desktop or an RDS session hosts.

Vadim Vladimirskiy
The other situation is because the Azure dynamic IP blocks are used by anybody and everybody, they’re often or sometimes blocked by certain service providers. So if you’re coming from a dynamic IP address range within Azure, you may not be able to browse a website. Whereas if you log in, let’s say to DC01, which does have a static IP address, you may notice that if you are on the RDSH01 going to a particular website fails, but if you’re on DC01 that’s on the same network, going to that same website succeeds, most likely, that is because of the IP address that it’s coming from. And therefore assigning an IP address to your desktop VM will then allow you to get to that website. So those are the two most common reasons for assigning an IP address to a VM, even if you’re not allowing traffic into it from the Internet on the inbound side.

Vadim Vladimirskiy
Okay, so here’s what we just did. We added an IP address to RDSH01, we assigned this IP. You can see the VM is on the LAN and we have an option of disassociating it, which is something that you have to do before you can delete it. So let’s say we’re going to disassociate. Once it associated, we’ll have an option to either associate it with another VM or delete it and only deleting it prevents you from being built for it further. Otherwise, every hour there is a, 4 cents or 0.4 cents, whatever that number was, charge that accumulates. There’s a meter that’s running for that static IP address.

Vadim Vladimirskiy
Okay, now let’s look at firewall rules. So the way firewall rules work, very much as expected in any type of a firewall. You click add rule, you specify the name of the rule, where the traffic originates, where the traffic is meant to go, and then what you want to do with it either allow or deny. So let’s say test RDP to DC01, right? Let’s say for whatever case, we need a situation where we want to be able to log into DC01 via RDP. So let’s go through that as an example. So test RDP to DC01. First question is direction, right? Are we controlling traffic on inbound side or on the outbound side? So let’s say this is going to be inbound. We want to be able to test RDP from the Internet to DC01.

Vadim Vladimirskiy
Then we want to allow the traffic versus deny, right? We could deny the traffic. Denying an inbound side something like this would be redundant because there is already a rule that denies everything and unless you explicitly allow, that’s going to apply. So in this case we’re doing allow. Then you get to specify a priority. So there’s a little tool tip that comes up that shows you what your current priorities are. The lower the number, the higher the priority. Meaning if I put something that’s, let’s say 99, it is going to take precedence over anything that’s below it. Whereas if I put something that’s 503, it’s going to sit right here in the list. So depending on what you’re doing, this is a list. You decide what priority you’re going to give it, which basically places it in the right sequence.

Vadim Vladimirskiy
So if we’re going to allow RDP traffic into DC01, let’s say that’s going to be, I don’t know, let’s say a thousand right? So it’s going to sit below this rule, which is what? It’s going to actually not be effective because this rule of 502, is going to block the traffic before it ever gets to 1,000 to allow the traffic. So that’s not going to work. So let’s make 500. Now we can’t do 500 because that’s already a priority that’s been assigned. So it’s going to error out. So let’s less than 475. Great.

Vadim Vladimirskiy
Next question is protocol. So you can do either any TCP or UDP. Because we’re doing RDP access. It’s TCP, so we can limit it to just what we need. Then the source can be either any, which means anything on the internet or anywhere else on the network. You can specify a particular server that’s already in the environment. This is useful if you’re creating a fire rule that’s going to go between LAN and DMZ or DMZ and LAN or something that’s already predefined. In our case, we want to allow access from anywhere on the Internet. Or you can alternatively use a CIDR block where you would basically put in your IP address and then you can put in your port range over here.

Vadim Vladimirskiy
So in our case, we’re doing 3389. 3398 is … Well, sorry. Nope, we’re not doing that. So we’re going to do any, and we’re not going to specify any ports or any servers because we want to allow traffic from anyone on the Internet into a particular server. So let’s go to servers. We’re going select DC01 and then we’re going to say we won’t allow only traffic on port 3389. Okay. And that’s it. We hit save, and that is going to create the firewall rule, which will allow me to RDP using DC01’s public IP address from anywhere on the Internet into that VM.

Videos in the series