Cloud

Azure Site-to-Site VPN with PFSense

Posted on Updated on

Reading Time: 5 minutes

(Edit: I’ve also now posted about how to do this with a Palo Alto Firewall as well, you can see that post here: https://hansencloud.com/2020/11/18/azure-site-to-site-vpn-with-palo-alto-firewall/  )

If you’re like me, you like to have a little bit more control over your network (home or business) than is available with the ISP-provided router – enter PFSense. The Netgate Appliances work very well and I’ve worked with plenty of home networks, as well as small and medium businesses that have used them as their cost-effective Router/Firewall/VPN appliance combination.

Now, how do we setup a Site-to-Site VPN with our infrastructure hosted in Azure with PFSense. It’s actually pretty easy! Let’s jump into it.

The first thing we need to do in Azure is setup a virtual network (or vnet). A virtual network is a regional construct, meaning that it cannot span multiple regions. I’m going to choose the “West US” region for now since that’s where i’ll be building my resources after this is configured.

In this particular setup I’m using 10.2.0.0/16 as my virtual network address space and have designated two subnets for a later project.

After the virtual network is configured, we’ll need to create a “Gateway Subnet” which is a specific prerequisite to deploying a VPN Gateway into the virtual network.

Alright, the network and subnets are all setup in Azure. Now let’s go create a Virtual Network Gateway to act as our PaaS VPN appliance. I’m going to be using a route-based VPN, so I’ll use that VPN type and choose the virtual network that we just created. You’ll notice that it also selects the special GatewaySubnet that was created for the VPN Gateway. I’m going to create a new public IP address to be associated with the VPN Gateway, and won’t be using active-active or BGP for this lab so I’ll leave those disabled.

The VPN Gateway takes about 20-30 minutes to deploy so go ahead and go stretch and grab a cup of coffee. Once it’s done we’ll go in and create a “connection”, which we’ll designate as “site-to-site IPSec”, then set the PSK that will be used here and on the on-premises appliance.

You’ll need to also create a local network gateway which is an Azure resource that represents the information about the on-premises VPN appliance and IP ranges. You’ll want to enter the public IP of the PFSense appliance on-premises and whatever address space you’d like to add to the route table of the virtual network so it knows to route those addresses across the VPN through the gateway.

Once that’s done we’ll go grab the public IP of the VPN Gateway from the overview page so we can go setup the PFSense side of the VPN.

Alright, now let’s go setup an IPSec VPN in PFSense. Open the IPSec VPN settings page and let’s create a Phase 1 configuration.

I will want to select the Authentication Method of Mutual PSK and enter the PSK we setup on the Connection on the VPN Gateway in the “Pre-Shared Key” field. I’m going to be connecting to some other resources with this setting so I am using both AES 128 and 256 with relative SHA 256 hashes and both DH groups 2 and 14. I recommend reviewing the documentation on cryptographic requirements and Azure VPN gateways though for reference.

Next let’s create a Phase 2 configuration for the IPSec VPN. I’m designating 10.0.0.0/8 to the VPN assuming that I may expand my Azure environment at some later point. If we wanted to be exact this would be the 10.2.0.0/16 address space that we configured in our virtual network. For the Encryption Algorithms required, please see the cryptographic requirements documentation noted above. If you wanted to automatically ping a host in Azure to bring up/keep up the tunnel you can configure that here as well.

Now that we’ve created both the Phase 1 and Phase 2 configurations we can “apply changes” to add those changes to the running configuration.

After the settings have saved the tunnel will take a minute to come up, you may take this time to spin up a quick VM in your Azure virtual network to use for testing connectivity. Once that tunnel comes up you can see the connection statistics on the IPSec Status page. Similarly if you look at the overview page of the site-to-site connection we created on the VPN Gateway on Azure you can see the tunnel status and connection statistics.

For troubleshooting purposes, there is a “VPN Troubleshoot” functionality that’s a part of Azure Network Watcher that’s built into the view of the VPN Gateway. You can select the gateway on which you’d like to run diagnostics, select a storage account where it will store the sampled data, and let it run. If there are any issues with the connection this will list them out for you. It will also list some specifics of the connection itself so if you want to dig into those you can go look at the files written to the blob storage account after the troubleshooting action is complete to get information like packets, bytes, current bandwidth, peak bandwidth, last connected time, and CPU utilization of the gateway. For further troubleshooting tips you can also visit the documentation on troubleshooting site-to-site VPNs with Azure VPN Gateways.

That’s it, all done! The site-to-site VPN is all setup. The VPN gateway in Azure really makes this process very easy, and the PFSense side is fairly easy to setup as well.

If you have any questions or suggestions for future blog posts feel free to comment below, or reach out to me via email, twitter, or LinkedIn. I hope I’ve made your day at least a little bit easier!

Thanks!

Custom “Virtual Network Operator” Role in Azure

Posted on Updated on

Reading Time: 4 minutes

*Edit* 6/9/20: At the time of writing this blog custom roles were not available in the Azure Portal. Since that feature now exists, I’ve added how to create this role through the portal to the end of this blog.

We all know that cloud environments are different than on premises. Development environments can be even more difficult, the right cross between giving freedom to produce business value and enough security and controls to maintain a good security posture. Recently I came across a scenario where the design was that the networking components (Virtual Network, S2S VPN, Peerings, Service Endpoints, UDRs, Subnets, etc.) were all under the control of a Networking team so that the Azure environment would be an extension of their local network. From a permissions standpoint though this caused some problems. The goal would be to empower developers to build whatever they need and just attach it to the vNet when connectivity was needed, with the caveat that they shouldn’t be able to modify any of the network settings or configurations in the shared vNet. This however, turned out not to be possible with default IAM roles.

In my testing, even though you’re not “modifying” anything per se in the vNet – when attaching a network interface card to a Subnet it does require write access. Reader access will give the user this error.

After looking through the default IAM roles, there aren’t any that do what I need them to do. Alas, a custom role is needed. For reference, please checkout this docs page for custom roles – https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles.

First, I need to see what actions are available to pack into the custom role so I run the following command in Azure Powershell and get these results.

Get-AzProviderOperation “Microsoft.Network/virtualNetworks/*” | FT OperationName, Operation, Description -AutoSize

Great, now I can see what is available. It looks like the actions that I need are the /subnet/join/action and /subnet/joinViaServiceEndpoint/Action. Based on the descriptions these two will essentially give “operator” role to the vnet. The assignee will be able to use the subnet(s) but not able to modify them.

Next, you can use one of the template references in the Microsoft Docs link (https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles-powershell#create-a-custom-role-with-json-template) and modify the actions.

{
  “Name”: “Custom – Network Operator Role”,
  “Id”: null,
  “IsCustom”: true,
  “Description”: “Allows for read access to Azure network and join actions for service endpoints and subnets.”,
  “Actions”: [
  “Microsoft.Network/virtualNetworks/subnets/join/action”,
  “Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action”,
  “Microsoft.Network/virtualNetworks/read”
   ],
  “NotActions”: [],
  “AssignableScopes”: [
  “/subscriptions/00000000-0000-0000-0000-000000000000”,
  “/subscriptions/11111111-1111-1111-1111-111111111111”
  ]
}

After modifying the assignable subscription IDs, save that as a .json file and use it in the following command to import the custom role.

New-AzRoleDefinition -InputFile “C:\FileFolderLocationPath\CustomNetworkOperatorRole.json”

After a portal refresh you get the custom role available as an IAM role assignment.

There you go, after assigning this role the user was able to create VMs and attach them to the Virtual Network while still leaving control of the Network configuration to the Networking Team.

————————————————————————-

————————————————————————-

EDIT 6/9/20: Now that custom roles are available in the portal I’ve added how to create this role that way below. 

Using the documentation on how to create custom IAM roles in the Azure portal you can clone any role, but I’m just going to use the “Network Contributor” role to clone. 

I am going to just “start from scratch”, though you can easily use this page to modify the permissions set of a certain role that already exists. Additionally, if you have the JSON (like we generated before with powershell) you can just upload that here.

Now go ahead and add new permissions by going to the “Microsoft Network” Category and selecting the same permissions we wrote in the JSON and used with the powershell command above.

After adding those the next page will show you the permission that you’ve added, let’s double check those and make sure we have what we need.

Looks good, now we can set a scope where this role can be applied. I have this one scoped to the whole subscription, but you can use the interface to easily change that on this page.

Alright, that’s about it – let’s take a quick look at the summary pages. You can see that the portal actually generates the JSON, which is nice if you want to assign roles using Azure Policy or any other automation tooling.

Nice! Now we can see that users can use the four above actions which will allow them to interact with, and use a shared hub-style virtual network while now allowing full contributor access.

I hope I’ve made your day at least a little bit easier!

If you have any questions or suggestions for future blog posts feel free to comment below, or reach out to me via email, twitter, or LinkedIn.

Thanks!

Isolated Virtual Machines in Azure

Posted on

Reading Time: 2 minutesIn a recent design session, I had someone mention how they wish that Azure had dedicated and/or isolated IaaS VMs like some of the other cloud providers. They were shocked with I said – they do! Azure has a number of isolated VM types that you can provision and leverage just the same as any other IaaS VM.

The link to Microsoft documentation below states that “Azure Compute offers virtual machine sizes that are Isolated to a specific hardware type and dedicated to a single customer. These virtual machine sizes are best suited for workloads that require a high degree of isolation from other customers for workloads involving elements like compliance and regulatory requirements.”

https://docs.microsoft.com/en-us/azure/security/azure-isolation#isolated-virtual-machine-sizes

Yup, you read that right, dedicated hardware. This means that using one of the isolated VM types (listed below) will guarantee that your virtual machine will be the only one running on that server instance (as of Nov. 1, 2018).

  • Standard_E64is_v3
  • Standard_E64i_v3
  • Standard_M128ms
  • Standard_GS5
  • Standard_G5
  • Standard_DS15_v2
  • Standard_D15_v2

 

If VM isolation is what you’re after, you can also consider Nested Virtualization in Azure (link below). A few VM types in Azure support Nested Hyper-V (not suitable for production, mind you) and Hyper-V Containers using Docker.

https://azure.microsoft.com/en-us/blog/nested-virtualization-in-azure/

https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container

 

Lastly, there is a new feature that recently went GA that’s sort of in-line with VM isolation – Confidential Compute. While this isn’t VM isolation, it is an isolated enclave for executing code in TEEs (Trusted Execution Environments) using Intel’s SGX capabilities. This allows for code to be executed in an environment that, while it’s being executed, can not be accessed by any source outside of the enclave (see diagrams in the links below).

https://azure.microsoft.com/en-us/blog/introducing-azure-confidential-computing/

https://azure.microsoft.com/en-us/blog/azure-confidential-computing/

 

Using physical isolation techniques in the cloud can be very different than the way we’re used to doing it on-prem. Hopefully, though, this post and its associated links will get you thinking about different ways you can design for isolation in Azure. Feel free to comment, or reach out on Twitter @MattHansen0.

Thanks, and I hope I’ve made your day at least a little bit easier.

Azure Point-to-Site VPN with RADIUS Authentication

Posted on Updated on

Reading Time: 4 minutesFor the money, it’s hard to beat the Azure VPN Gateway. Until recently though, Point-to-Site VPNs were a bit clunky because they needed mutual certificate authentication. It wasn’t bad, but it certainly wasn’t good. Thankfully, Microsoft now allows RADIUS backed authentication. This post is how you impliment said configuration.

 

To start off, here is my environment information I’m using to setup this configuration.

Virtual Network: “raidus-vnet”

Virtual Network Address Space: 10.1.0.0/24

Virtual Network VM Subnet: 10.1.0.0/28

Virtual Network Gateway Subnet: 10.1.0.16/28

VPN Gateway SKU: VpnGW1

VPN Client Address Pool: 172.28.10.0/24

Domain Controler/NPS Server Static IP: 10.1.0.10

 

 

Virtual Network (VNET) Setup:

You most likely already have a VNET where you will be configuring this setup, but if you don’t you need to create one with two subnets. One subnet for infrastructure, and one “Gateway Subnet”. The Gateway Subnet will be used automatically, and is required,  when you configure the VPN Gateway.

 

VPN Gateway Setup:

The Azure VPN Gateway is just about as easy as it gets to configure and to managed (sometimes to a fault). The only caveat you need to be aware of in this scenerio, is that RADIUS Point-to-Site authentication is only available on the SKU “VPNGW1” and above. You’ll then need to choose the vnet where you have created the VPN Gateway, and create a Public IP Address resource.

 

This will take anywhere from 20-45 minutes to provision, as noted. While that’s running, you can provision your NPS (Network Policy Server) VM. This being a test environment, I provisioned a VM to be both the domain controler and the NPS box. Make sure to set a static IP on the NPS box’s NIC in Azure, you’ll need a static for your VPN configuration. I used 10.1.0.10.

After complete,  you will need to configure the VPN Gateway’s Point-to-Site configuration. Choose “RADIUS authentication”, enter in the static IP of the will-be NPS server, and set a Server Secret. This being a test environment, my password is obviously not as secure as I hope yours would be.

 

Configure NPS:

Now, go back into that VM that was created earlier and install the NPS role.

 

After it’s installed, you need to create a Network Policy with a condiational access clause (I used a group in AD) and tell it what security type you want to allow.

 

 

 

 

Next, you’ll need to create a Client Access Policy. Here you need the IP of the VPN Gateway you created, and the shared secret. Here is the interesting bit, you can’t view the IP of your VPN Gateway in the Gateway Subnet. If you looked at “Connected Devices” in the VNET the VPN Gateway doesn’t show any IP. I know that the VPN Gateway is deployed (behind the scenes) as an H/A pair, but I would assume they’re using a floating IP that they could surface. Anyways, there is no real way to find it – but it looks like (after testing with a dozen different deployments) it uses the 4th available IP in the subnet. This subnet being a 10.1.0.16/28, the 4th IP is 10.1.0.21. This is the IP that goes in the address of the RADIUS Client.

 

 

Next, I configure NPS Accounting. You don’t have to do this, but I think it helps for the sake of connection logging and for troubleshooting. You can log a few different ways, and choose here just to use a text file to a subfolder I created called “AzureVPN”.

 

 

 

Generate VPN Client Package:

Now that everything is set, you need to generate a VPN Client Package to distribute to your users.

 

After it is installed, you can see the VPN Connection in the VPN list and users can logon using their domain credentials.

 

 

 

After logging in, we can go back and look at the accounting log which shows us the successfull authentication of that user.

 

 

There we go, connecting to an Azure VPN Gateway with RADIUS authentication using domain credentials. I think we can all thank Microsoft for this one, and not having to do cert management anymore.

I hope I’ve made your day at least a little bit easier.

Configure Azure Blob Archive Storage

Posted on Updated on

Reading Time: 4 minutesAzure storage is great. Good thought to open on right? Of course! This year Azure graced us with the ability to (preview) the new Azure Archive Storage. Obviously this is enticing, especially at it’s  (current) $0.0018/GB price point. For more cost informaiton on Azure Archive Storage you can visit the link below.

https://azure.microsoft.com/en-us/pricing/details/storage/blobs/

Now this is nice, but I found myself a bit perplexed. How do I configure a storage account as an “archive” storage account? As it turns out, you don’t. Let’s walk though configuring an archive blob tier.

First, obiously you need a storage account. The Archive access tier is currently available on either “Blob” or “General Purpose v2”.  General Purpose v2 will work the same way, you’ll just also have the ability to host non-blob storage (File, Queue, Table). I’m going to just choose Blob though for this purpose.

Account kind selected, I’ll create the storage account. You can choose whatever Access Tier you’d like, that’s the access tier all of your objects will inheret by default. I choose “Cool” here because you will have to upload data before you can archive it and the cool tier saves money initially.

Alright storage account created, let’s go open it up.

If you go to the “Configuration” tab you can see the default acces tier you selected durring creation. Here is where I was a bit confused, why don’t I have the ability to select archive? You’ll see in a bit.

Go ahead and create a container, and upload a file. I created a container with the very complex name of “container1”, and have uploaded my very important image file that I want to archive.

Can see above that the inhereted access tier is “Cool” which was set at the storage account level. If you go into the blob properties you can see at the bottom there is an option to select the access tier for that specific file. Ah! There is it, Archive!

I’ll go ahead and select Archive, and see the the following message.

Please be cognizant of this, they aren’t kidding when they say that rehydration can take a long time. We can now refresh and see that the file is set to an access tier of “archive”.

Fantastic, we’ve archived the file! Now here is where you have to be careful, while the file is in archive the only data you’re able to access is the file metadata. The file itself is NOT ACCESSABLE until rehydrated. If you try and download the file while archived you can see the following message.

Archive storage is designed to be very long-term storage that you don’t need to access immediately, thus the low cost point. If you do need to access your file, you simply go back to that object and change it’s access tier to either Cool or Hot. It will then go through the “rehydration” process to move the file back into an accessable access tier.

I urge you to take that message seriously, in this example it took about 8 hours for my 48k image file to be rehyrated. They say it takes longer for larger files, and I’m going to test that next. Though in the mean time, assume it will take quite some time to be accessable again. After which time, WHEW! I recovered my very, very important file.

There you go, how to configure Azure Blob Archive Storage.

I hope I’ve made your day at least a little bit easier.

Changing Azure Recovery Services Vault to LRS Storage

Posted on

Reading Time: 2 minutesBack in the classic portal with backup services it was an easy fix. Simply change the settings value of storage replication type. I’ve recently started moving my workloads to recovery serveries vaults in ARM, and noticed something peculiar. By default, the storage replication type of the vault is GRS.

 

If your needs require geographically redundant storage, that that’s perfectly fine. I however don’t have such needs, and trust in Microsoft’s ability to keep data generally available in a LRS replication topology. It should be just like it was in classic, as an option anyways, right? Strangely, the option to change the replication type for the storage configuration on the vault is grayed out.

 

 

Odd, right? I thought so, until I found this.

 

Okay, well it’s not optimal but it looks like I need to remove the backup data from the vault to change the storage replication types right? Well, I gave that a shot and no go. I had the same issue, the option was still grayed out.

I ultimately had to completely delete, and create a new recovery services vault. Once it’s initially created you can change the replication type.

 

 

Ah, finally! Then register the VM(s), run some backup jobs and voila! Confirmation that the vault is using LRS storage.

 

I hope this makes your day at least a little bit easier.

Thanks,

How to move SCVMM VMs into a Cloud

Posted on

Reading Time: 2 minutesIf you’ve ever added hosts to an SCVMM instance you’ll know that there’s seeminly no easy way to move the newly imported VMs from those hosts into SCVMM clouds. I’ve found the best way to do this is by using the SCVMM command-line interface, which unfortunately has a few quirks.

Set-SCVirtualMachine is the command you’ll need to use, with the flag “-Cloud” like in the example below.

Set-SCVirtualMachine -VM “NewVM1” -Cloud “Cloud1”

Unfortunately, every time I’ve tried this I’ve gotten an error saying it can’t convert the value type correctly like as shown below.

setscvm-failure

 

For whatever reason, I’ve found that the work around here is to set both the VM and the Cloud as variables and run the command again.

$VM = Get-SCVirtualMachine “NewVM1”

$Cloud = Get-SCCloud “Cloud1” 

Set-SCVirtualMachine -VM $VM -Cloud $Cloud

setscvm-success

 

Then we have success!

 

sccloud-success

 

I’ve yet to figure out why this is, but at least it works.

I hope this makes your day at least a little bit easier.

Thanks,

SCVMM Error 2912 “The configuration registry database is corrupt (0x800703F1)”

Posted on

Reading Time: < 1 minuteI recently spun up a new SCVMM environment, created my first VM, and attempted to create a template only to be faced with a job error.

Error (2912)
An internal error has occurred trying to contact the Host01 server: : .

WinRM: URL: [http://Host01.lab.local:5985], Verb: [INVOKE], Method: [LoadSubkey], Resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/scvmm/P2VSourceFixup?RegFileName=C:\Users\SVC_VMM\AppData\Local\Temp\tmp6AB5.tmp]

The configuration registry database is corrupt (0x800703F1)

Recommended Action
Check that WS-Management service is installed and running on server host01.lab.local. For more information use the command “winrm helpmsg hresult”. If host01.lab.local is a host/library/update server or a PXE server role then ensure that VMM agent is installed and running. Refer to http://support.microsoft.com/kb/2742275 for more details.

 

I’ve seen this issue before and typically it’s because I go on auto-pilot and sysprep the VM by hand. That will cause an issue, go ahead and start the VM and login, shutdown and let VMM do the sysprep.

Unfortunately this time that wasn’t the problem, though it was similar. When I shut the VM down I accidentally hit “Turn Off” and it hard powered the VM down. A simple boot, login, and retry fixed the problems here.

 

I hope this makes your day at least a little bit easier.

Thanks,

Domain Controllers “Grayed out” in SCOM 2012

Posted on Updated on

Reading Time: 2 minutesI did a few new SCOM 2012 installs recently and noticed that after pushing the agent to the DCs, they showed up grayed out in Ops Manager. Here’s a quick tip on how to fix that.

Logon to the DC(s), and with an administrative comand prompt run the HSLockdown tool, and add the local system account to the allowed group.

C:\Program Files\System Center Operations Manager\Agent:

*NOTE* In newer version, this is now stored in “C:\Program Files\Microsoft Monitoring Agent\Agent”

agent

 

Run the command “HSLockdown /L” to show what accounts are being allowed or denied. In this case, my local system isn’t even populated.

 

L

 

 

Now run the HSLockdown tool again with the add switch to allow local system.

“HSLockdown /A “NT AUTHORITY\SYSTEM”

add

 

Restart the agent with “net stop heathservice && net start healthservice” and give it 5 minutes or so then it should be all green in your dashboard.

 

Hope this made your day at least a little easier!

 

How to mount your OneDrive as a local mapped drive: Part 2

Posted on Updated on

Reading Time: 2 minutesA while back I wrote a blog post about how to map your OneDrive as a local drive (network drive) and it has been hugely popular (contrary to anything I could have imagined)

How to mount your OneDrive as a local mapped drive

 

 

I’ve even seen it referred to in the Microsoft Community Forums. So I decided to share something that I played with, starting to write a tool to automate this otherwise lengthy process. Granted at this point it’s still at something of a Version 0.1, but I’ll share it anyways.

 

There are three things you need to have to make this tool do it’s magic.

  1. Your Microsoft CID
  2. Your Email
  3. Your Password

As long as you have those things the tool will do the rest!

 

The only thing here that you need to do is have your Microsoft CID, which isn’t too hard to do. Let’s help you grab that real quick!

First

 

  • Copy the CID in the top URL bar

Second

 

 

 

 

 

Once you have this ID copied, you’re all set! You can download the poweshell script here. Right click, and run with powershell! *Note* Accessing OneDrive this way is NOT supported and may act sluggish at times.

 

In some free time I’ll be working on using the Windows Live APIs to automatically pull the CID in the next version of this application. I hope I’ve made your day a little bit easier!