Azure Gateway Subnet Size for VPN

Microsoft Azure

If you have ever tried searching for how big your Azure Gateway Subnet needs to be you will find conflicting posts about it’s minimum size, you will also find posts stating that the size depends on the features you chose, but they never actually give you a table of what features require what size. For example on github Microsoft recommends that you use a minimum of /27 if you are going to use Expressroute and Siste-Site VPN, while in other articles state that you need /28 as a minimum.

If you are going for ExpressRoute with or without BGP it’s best to contact Microsoft for exact Subnet Ip requirements.

If you are going for the normal Dynamic Routing (route-based) VPN there is an easy way to work out how big your VPN Subnet needs to be. The basic rule is that for every VPN you create one ip address is used from the Subnet. So if you are going to use a “HIGH PERFORMANCE VPN GATEWAY” which has a limit of 30 connection and you want to use all 30 you will need a /26 Subnet, this is because a /27 subnet will only give you ironically 27 free Ip addresses.

Add/Set/Remove NSG rules in ARM mode Azure Powershell

Microsoft Azure

So i ran into a little bit of an issue today, i was trying to find out how i can add more network security rules to a network security group (NSG) in the Azure Resource Manager (ARM) mode under Powershell. Now the old trick under the classic mode of using SET wasn’t working (where the rule will be created if it doesn’t exists) as it was giving me an error that the rule didn’t exists, fair enough ADD would be used for new rules and SET to modify existing once, so i tried that but my rules weren’t saving. After some investigating i found out that you also need to SET (by using the pipeline) the Azure Network Security Group in order for the rules to be saved and since i couldn’t find this information anywhere online here is a blog about it with some examples below.

For Azure Powershell 1.0

Using the Add command to add an additional rule to An Azure ARM NSG:


Using the Set command to change the Rule (change the above rule to UDP):


Using the Remove command to remove a rule:


For Azure Powershell 0.9.8

Using the Add command to add an additional rule to An Azure ARM NSG:


Using the Set command to change the Rule (change the above rule to UDP):


Using the Remove command to remove a rule:

Control VMware ESXI (free hypervisor) with Powershell and SSH

Powershell, VMware

Some time ago i wanted to to run some build scripts in my home lab which needed to power off and on a virtual machine running Independent Non-Persistent disks in order for the VM to be in a clean state before each build. However i was running the free hypervisor version of ESXI so the api was not available, then i figured that i could do this via SSH and Powershell. In order for the example script below to work you will need to do a couple of things to the esxi server and the machine executing the script.


You will first need to make sure you have the powershell ssh module copied to the following locations on the machine executing the script:



You can download the file from here: SSH-Sessions

*Note i am not the creator of the SSH-Module and the original is located at


Then you will need to generate a public/private key for the SSH user you are going to use and load the public key into ESXI. VMware has made a nice set of instruction on how to do it here.
Keep the private key as you will need it when running the script. You will also need to enable SSH and allow it thru the firewall on the ESXI server.


The below script is an example of what you can do with powershell and ssh on an ESXI server. The script will look for a vm on a specific ESXI server you have specified, it will then check if it’s powered on, if so it will power it off, then it will power it on and wait for VMware tools to be up before finishing:


Azure Domain Controller (dc) to On-Premise Domain Controller (dc) One-way trust ports for Azure NSG (firewall)

Microsoft Azure

Here is a quick post about what ports you need to open, there direction and protocol if you want to establish a one way trust between an Azure domain and your On-Premise domain. Please note that as of writing this post Azure AD Domain Services does not offer the ability of creating a Domain or Forest trust so you will need to spin up an IAAS virtual machine and create a domain on it. I will also go over some tips if you want to limit the communication between Azure AD subnet (where your domain controllers reside) to only one or two domain controllers in your On-Premise environment, as well as what needs to be configure in order to get Kerberos working. The below ports will need to be opened on the Azure subnet hosting your domain controller and on the On-premise firewall (but in reverse obviously):

NamePriority Source IP Source Port Destination IP Destination Port Protocol Access
Inbound Rules
AD DNS from On-Premise AD100On-Premise AD site Subnet*Local Subnet Range53*Allow
AD Kerberos from On-Premise AD101On-Premise AD site Subnet*Local Subnet Range88*Allow
AD LDAP from On-Premise AD102On-Premise AD site Subnet*Local Subnet Range389*Allow
AD RPC from On-Premise AD103On-Premise AD site Subnet*Local Subnet Range135TCPAllow
Outbound Rules
AD DNS to On-Premise AD100Local Subnet Range*On-Premise AD site Subnet53*Allow
AD Kerberos to On-Premise AD101Local Subnet Range*On-Premise AD site Subnet88*Allow
AD LDAP to On-Premise AD102Local Subnet Range*On-Premise AD site Subnet389*Allow
AD SMB to On-Premise AD103Local Subnet Range*On-Premise AD site Subnet445TCPAllow
AD RPC to On-Premise AD104Local Subnet Range*On-Premise AD site Subnet135TCPAllow
AD dynamic range to On-Premise AD105Local Subnet Range*On-Premise AD site Subnet49152-65535TCPAllow

*If you are using LDAP SSL you need to open port 636 as well

The above ports and solution will give you a strong and secure environment with the following advantages:

  • No password hashes are kept in the cloud making it more secure
  • Single sign on with On-Premise account
  • Easier user management
  • DNS replication
  • And if you chose to not set up Kerberos which i recommend:
    • Only the Azure domain controllers have access to On-Premise domain controllers (it uses NTLM authentication to proxy requests)

As mentioned above i strongly recommend that you  don’t set up Kerberos authentication between the azure computers and the On-Premise domain and there is a very good reason for that. The lesser of two evils. So for you whats more dangerous using NTLM authentication or opening Kerberos ports from every computer in Azure to your On-Premise domain controllers. For me personally it’s safer to use NTLM and this way the Azure domain controller can proxy requests to the On-Premise domains. However if you want to enable Kerberos you are more than welcome you just need to make sure you open port 88 and 464 from the azure servers to the On-Premise domain controllers.

To make things more secure we can also limit which domain controllers are used for DNS and for LDAP authentication. Before we get into this please read this great article as it will be vital for restricting LDAP authentication. Obviously limiting which dns server we want to use is pretty easy we can just use conditional forwarders instead of stub zones but for LDAP it’s more tricky. For LDAP once you have created an empty zone (with the same names as the Azure zone) you need to go into DNS and modify the SRV records for that zone, usually what you want to do is leave the SRV records for the domain controllers you want to use as they are but set all other domain controllers SRV records with a priority of 10 for the empty zone. This will ensure that the lower priority domain controllers are only contacted unless they are all down in which case you will probably need a disaster recovery plan in which you open the rules to all other domain controllers. Also any new domain controllers you promote will need there SRV priority value adjusted.