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:

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules

C:\Windows\System32\WindowsPowerShell\v1.0\Modules

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 http://www.powershelladmin.com

 

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.

Client/Server to Domain Controller (dc) ports for Azure NSG (firewall)

Microsoft Azure

As most of you know trying to find what domain controller ports you need to open between a server/pc and a DC can be a nightmare. Especially if you want to be more specific and include traffic direction. Most of the posts out there give you a bunch of ports and that’s it, no explanation on direction and which once you really need. With this post i am aiming to help anyone one out there who is lost or confused.

With the introduction of Network Security Groups in Azure more and more organization are using them to secure the communications between there Azure subnets, this is a very good practice but can sometimes prove difficult when it comes to complex applications like Active Directory (AD) and it’s port requirements. The firewall rules below will give clients the ability to communicate with a domain controller and fulfill all the required AD functions like login in, joining a computer to the domain, obtaining group policy and so on. Note that these rules are all one way outbound rules from Client to DC, this is always the case with active directory as the client connects to the DC and not the other way around. While these rules are for Azure NSG you can modify and use them with any firewall. Also please note that you would also need to created identical inbound rules on the Domain Controller subnet if you have NSG enabled, it’s also worth noting that azure NSG are stateful.

NamePriority Source IP Source Port Destination IP Destination Port Protocol Access
Outbound Rules
NTP Sync Primary Domain Controller100Local Subnet Range*Primary AD site Subnet123UDPAllow
AD RPC Primary DC101Local Subnet Range*Primary AD site Subnet135TCPAllow
AD Kerberos change Primary DC102Local Subnet Range*Primary AD site Subnet464*Allow
AD LDAP Primary DC103Local Subnet Range*Primary AD site Subnet389*Allow
AD LDAP GC Primary DC104Local Subnet Range*Primary AD site Subnet3268TCPAllow
AD DNS Primary DC105Local Subnet Range*Primary AD site Subnet53*Allow
AD Kerberos Primary DC106Local Subnet Range*Primary AD site Subnet88*Allow
AD SMB Primary DC107Local Subnet Range*Primary AD site Subnet445TCPAllow
AD DYN Primary DC108Local Subnet Range*Primary AD site Subnet49152-65535TCPAllow

I have set my Domain controllers as NTP servers as per the article here : http://setspn.blogspot.co.uk/2015/06/synchronizing-time-on-azure-virtual.html. If you have not done this step you will need to open a port to what ever NTP server you are using and omit the first rule above.

If you are using SSL for your AD you will also need to add two more rules to the table the LDAP GC SSL on TCP 3269 and LDAP SSL TCP 636. If you are not using SSL you don’t need to include them.

If you are looking to make things more secure and easier to manage you could also restrict RPC traffic to a single port. there is an article on the Microsoft support website https://support.microsoft.com/en-us/kb/224196. Please note that this needs to be applied on all domain controllers, it applies both to replication and client communication. Once implemented you will need to modify the last rule port range from 49152-65535 to what ever port you have chosen like “51515”.

Accessing GPO and ADUC interface for Azure AD Domain Services (AADDS)

Microsoft Azure

Since Microsoft released a preview version for the Azure AD Domain Services there have been a number of posts asking how to actually manage it and how to access things like GPO and ADUC. Since it’s a very new service there isn’t any how to’s (or i haven’t been able to find them) so here is a quick one:

You first need to deploy the AADDS, but please keep in mind that as of writing this post it’s only available in the US. I am not going to repeat this part as there is a nice post on technet:

http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx#pi168980=3

*Please note that if you are creating a test environment you probably are not going to configure password replication so your username will not work. Easiest way to fix this is to create a “New user in your organization” and add them to the “aad dc administrators” group.

Once you have a AADDC (Azure Active Directory Domain Controller), you will need a virtual machine in the same network or a network which has vnet to vnet VPN with it. Once the VM is up you need to join it to the domain with an account from the “aad dc administrators” group. Once joined you should have Administrators access with the same account you joined it to the domain with. If not please log in with the local account and run “gpupdate /force”. This is because in the AADDS your are not part of Domain Admins, so there is a default GPO which adds “aad dc administrators” as administrators on all domain joined computers.

To use the two features mentioned below you need to log in with a member of the “aad dc administrators” group.

GPO Administration:

To administer GPOs you need to add the Group Policy Management Feature to the machine above:

gpfea

Once installed you can open the tool and you will see the below default GPOs. Please note that currently you can only edit the two GPOs highlighted in yellow, you also can’t add any filtering to the GPOs or create additional once. You will also not be able to add additional ADMX templates (the 2012  R2 defaults are available)

gpo

 

ADUC Administration:

Please note that you have very limited rights in the ADUC. Currently you can only modify certain things in the “AADDC Computers” OU like Adding , Disabling, Resetting, Deleting computer objects.

To administer ADUC you need to add the ADUC Feature to the machine above:

aducadd

 

As mentioned above currently you are very limited to what you can actually do but as a side note any groups or users you add from the Azure management portal to the Directory will appear in the “AADDC Users” OU.

azureaduc

Virtual machine as nfs (ISO) server for host esxi server

VMware

 

This is an old post i made on the VMware communities earlier this year, i am re-posting it as i don’t want it to get buried, given the amount of post they get in a day :D.

So I decided to post an observation i made during a non standard ESXI setup (couldn’t find anything about it so i am making a post).

This is not a fault or a question more of a discussion.

The circumstance below are due to the limitation of having only one server in a remote site.

What i noticed and i am pretty sure this is not supported or recommended, is that when you have a virtual machine on an esxi host that presents (as a datastore) a NFS full of ISO to VMWare (the esxi host) the machine hosting the NFS cannot use the ISO.

What i mean by the above is if you try and mount an ISO from the NFS datastore on the virtual machine hosting them it will lock up. Now if you try and mount it on any other Virtual machine it’s fine no problem.

The bellow diagram show our setup.

I assume it has something to do with the reconfiguration of the virtual machine when you mount the ISO, maybe a microsecond downtime for it to mount and due to this downtime the ISO presented becomes unavailable and in turn locks up the mount, it’s worth noting when i say it locks up the entire virtual machine locks up. Eventually vmware does pop up a message and ask if i should cancel the mount as it noticed that it’s causing problems. Maybe someone with better understating than me can explain why this behavior occurs.

 

Now i know there are other ways of doing this like putting the images directly on the datastore but our situation requires that ISO s are synced on regular bases so we use DFS to sync from main site and NFS(usually located on different server) to present to ESXI servers.

 

VMware virtual nfs to same esxi