Azure VPN Deployment
Azure VPN Deployment
Azure VPN Deployment
_________________
"The best way to predict the future is to create it."
— Peter Drucker
"The best way to predict the future is to create it."
— Peter Drucker
"The best way to predict the future is to create it."
— Peter Drucker
Project Introduction: Azure VPN Deployment for Remote Access Integration
This project details the implementation of an Azure Point-to-Site (P2S) VPN to enable secure remote access to an internal homelab environment.
The setup allows external machines to connect seamlessly to resources within the local network, providing both security and scalability for remote
administration and user workflows.
The process involves:
Creating a Free Azure Account: Utilizing preloaded credit for resource allocation.
Configuring Azure Network Resources: Setting up Virtual Network Gateways, Subnets, and necessary connectors.
User and Group Management: Leveraging Microsoft Entra ID (formerly Azure AD) for identity and access management, including assigning VPN permissions.
Deploying and Testing the VPN: Establishing secure connectivity to homelab resources, such as a file server hosted on the VMHOST machine.
This project demonstrates the ability to integrate enterprise-level tools and concepts into a functional remote access solution, emphasizing cloud
security, identity management, and hybrid IT infrastructure.
Azure Account and Resource Setup
We'll start by creating an Azure account with trial/free credit for use within a subscription. After setting up the personal details, we should be able to continue through the process and create our first resource group.
The name of this ResourceGroup will be "SethLab" to house all Hyper-V and hybrid cloud components necessary for deploying our P2S VPN connection.
We'll start by creating an Azure account with trial/free credit for use within a subscription. After setting up the personal details, we should be able to continue through the process and create our first resource group.
The name of this ResourceGroup will be "SethLab" to house all Hyper-V and hybrid cloud components necessary for deploying our P2S VPN connection.
Now that we have a Resource Group that has been created, the next step will be to create a Virtual Network within Azure under the name of "ProjNetwork" and configure the network to have an address space of 10.1.0.0/16 with my current active subscription and within the previously created resource group
Now that we have a Resource Group that has been created, the next step will be to create a Virtual Network within Azure under the name of "ProjNetwork" and configure the network to have an address space of 10.1.0.0/16 with my current active subscription and within the previously created resource group
We'll now need to add a subnet for the Virtual Network to operate within. We'll define the subnet at 10.1.10.0/24 (while our homely operates at 10.0.0.0/28) and label it "Gateway Subnet" This configuration will reference NIST SP 800-53 concerning Information Flow Enforcement by restricting traffic within a defined address space
We'll now need to add a subnet for the Virtual Network to operate within. We'll define the subnet at 10.1.10.0/24 (while our homely operates at 10.0.0.0/28) and label it "Gateway Subnet" This configuration will reference NIST SP 800-53 concerning Information Flow Enforcement by restricting traffic within a defined address space
II. Site-to-Site (S2S) VPN Configuration
Next, we'll need to create a "Virtual Network Gateway". This will act as the gateway between my local devices and Azure. We'll configure the VNG to my existing VNet, choose VPN for the Gateway Type, select "Route-based" (this is because I want to make sure the VNG supports both S2S and P2S functionality), specify VpnGw2 for the SKU, and create a new public IP address.
Next, we'll need to create a "Virtual Network Gateway". This will act as the gateway between my local devices and Azure. We'll configure the VNG to my existing VNet, choose VPN for the Gateway Type, select "Route-based" (this is because I want to make sure the VNG supports both S2S and P2S functionality), specify VpnGw2 for the SKU, and create a new public IP address.
We'll now navigate back to the Azure main portal and select "Create a resource". The next resource that we will create is a Local Network Gateway to complete the link between on-prem and Azure devices. We will name this resource "VPNSMMDEVICENG" and enter the public IP address of the on-premises VPN device, setting the address spaces as for both the internal, and external networks of 10.0.0.0/28 (Internally hosted homely subnet), and 192.168.1.0/24 (External subnet which my externally facing gateway resides) respectively.
We'll now navigate back to the Azure main portal and select "Create a resource". The next resource that we will create is a Local Network Gateway to complete the link between on-prem and Azure devices. We will name this resource "VPNSMMDEVICENG" and enter the public IP address of the on-premises VPN device, setting the address spaces as for both the internal, and external networks of 10.0.0.0/28 (Internally hosted homely subnet), and 192.168.1.0/24 (External subnet which my externally facing gateway resides) respectively.
We'll now need to add a new connection to make the bridge between the vNetGW and the LocalNetGW. We'll return to our Virtual Network Gateway and navigate to "Connections" and "+ Add" where we will add a new connection with the name S2SConnection, configured to the connection type of "Site-to-Site" , Local Network Gateway as the previously created "VPNSMMDEVICELNG", as well as setting a PSK for the connector
We'll now need to add a new connection to make the bridge between the vNetGW and the LocalNetGW. We'll return to our Virtual Network Gateway and navigate to "Connections" and "+ Add" where we will add a new connection with the name S2SConnection, configured to the connection type of "Site-to-Site" , Local Network Gateway as the previously created "VPNSMMDEVICELNG", as well as setting a PSK for the connector
III. On-Premises Device Configuration
Next, we'll need to begin the configurations at our on-premises devices starting at the external gateway where we will set port forwarding rules for the ISAKMP (udp/500), NAT-T (udp/4500), and L2TP (udp/1701). We will set that traffic over these ports is to be forwarded along to our internal Gateway01 vGW.
Next, we'll need to begin the configurations at our on-premises devices starting at the external gateway where we will set port forwarding rules for the ISAKMP (udp/500), NAT-T (udp/4500), and L2TP (udp/1701). We will set that traffic over these ports is to be forwarded along to our internal Gateway01 vGW.
With these configurations in place, our virtual gateway should now be able to effectively serve as the egress point of the lab, and route traffic in, or out of the homelab environment correctly.
We will now return to our vGW (Gateway01) and begin creating a Demand-dial interface through the General tab on the Gateway properties. We'll name this interface "AzureVPN" chose "Connect using VPN', enter the public IP address of the Azure VPN gateway in the destination address field, and select the "IPSec Tunnel Type". Then, we'll define a static route within the interface of a Destination address of 10.1.0.0 as that any traffic destined for any IP address within this range (10.1.x.x) should be routed through the Azure VPN connection, as well as the corresponding subnet mask of 255.255.0.0 class-B address. The creation of a Demand-Dial interface as well as creating a default static route adheres to NIST SP 800-77 on VPN Tunneling Best Practices. Finally, we'll specify the interface of the AzureVPN. For dial-out credentials. Azure does not consider these details for authentication, so we'll leave placeholders here.
We will now return to our vGW (Gateway01) and begin creating a Demand-dial interface through the General tab on the Gateway properties. We'll name this interface "AzureVPN" chose "Connect using VPN', enter the public IP address of the Azure VPN gateway in the destination address field, and select the "IPSec Tunnel Type". Then, we'll define a static route within the interface of a Destination address of 10.1.0.0 as that any traffic destined for any IP address within this range (10.1.x.x) should be routed through the Azure VPN connection, as well as the corresponding subnet mask of 255.255.0.0 class-B address. The creation of a Demand-Dial interface as well as creating a default static route adheres to NIST SP 800-77 on VPN Tunneling Best Practices. Finally, we'll specify the interface of the AzureVPN. For dial-out credentials. Azure does not consider these details for authentication, so we'll leave placeholders here.
Verified this was working by checking that the S2S-Connection was showing a status of "Connected"
Verified this was working by checking that the S2S-Connection was showing a status of "Connected"
IV. Point-to-Site (P2S) VPN Configuration
IV. Point-to-Site (P2S) VPN Configuration
In addition to this S2S connection, we can begin configuring our P2S connector to allow for VPN connection from any non-domain joined machine. To begin, we'll start by installing the Microsoft Entra Connect Sync agent on our dedicated DC server. This will allow us to streamline the provisioning of RBAC for P2S connections. The action of restricting access based on user identity and group membership as well as creating Entra to enforce IAM is a utilization of NIST SP 800-53, Enforcing Strong Identity Management.
In addition to this S2S connection, we can begin configuring our P2S connector to allow for VPN connection from any non-domain joined machine. To begin, we'll start by installing the Microsoft Entra Connect Sync agent on our dedicated DC server. This will allow us to streamline the provisioning of RBAC for P2S connections. The action of restricting access based on user identity and group membership as well as creating Entra to enforce IAM is a utilization of NIST SP 800-53, Enforcing Strong Identity Management.
We'll next need to open Active Directory Domains and Trusts to set an alternative UPN suffix to make the domain routable. That UPN suffix will be smmdevice.com
We'll next need to open Active Directory Domains and Trusts to set an alternative UPN suffix to make the domain routable. That UPN suffix will be smmdevice.com
I ran the following registry commands in order to enable TLS 1.2 cryptography on my DC, which is required for secure Azure Entra Connect communication, and rebooted the machine
I ran the following registry commands in order to enable TLS 1.2 cryptography on my DC, which is required for secure Azure Entra Connect communication, and rebooted the machine
To begin using RBAC as an authentication method for connecting to Azure VPN, we'll create a default set account named "VPN user"
To begin using RBAC as an authentication method for connecting to Azure VPN, we'll create a default set account named "VPN user"
Next, we'll conclude the configuration for Microsoft Azure Entra Connect.
Next, we'll conclude the configuration for Microsoft Azure Entra Connect.
Once configuration has concluded, we can verify that Entra Connect is working by navigating back to Azure, and seeing that our previously created "Vpn User" account has been created
Once configuration has concluded, we can verify that Entra Connect is working by navigating back to Azure, and seeing that our previously created "Vpn User" account has been created
Next, we'll need to utilize the URL https://login.microsoftonline.com/Tenant_ID/ to enable Admin consent for Azure VPN. This was completed by logging in, and confirming that the "Azure VPN" app was present in Entra's Enterprise Applications
Next, we'll need to utilize the URL https://login.microsoftonline.com/Tenant_ID/ to enable Admin consent for Azure VPN. This was completed by logging in, and confirming that the "Azure VPN" app was present in Entra's Enterprise Applications
Now that this has been set, we are free to begin configuring our P2S VPN connection. We'll navigate back to our virtual network gateway, and access "Point-to-site configuration" in the left-hand navigation menu. After accessing, we'll configure the connection as follows:
Address pool: 10.2.0.0/24
Tunnel Type: OpenVPN(SSL) (NIST SP 800-113 recommends OpenVPN for secure client access)
Authentication Type: Azure Active Directory
Tenant Supplied Tenant ID
Audience: '41b23e61-6c1e-4545-b367-cd054e0ed4b4
Now that this has been set, we are free to begin configuring our P2S VPN connection. We'll navigate back to our virtual network gateway, and access "Point-to-site configuration" in the left-hand navigation menu. After accessing, we'll configure the connection as follows:
Address pool: 10.2.0.0/24
Tunnel Type: OpenVPN(SSL) (NIST SP 800-113 recommends OpenVPN for secure client access)
Authentication Type: Azure Active Directory
Tenant Supplied Tenant ID
Audience: '41b23e61-6c1e-4545-b367-cd054e0ed4b4
We'll now setup the VPN client by selecting "Download VPN Client" and downloading "Azure VPN" from the Microsoft Store. We'll import the Azure config file within the client into the "Azure VPN" app, and connected with Domain credentials, with an MFA prompt to the Microsoft Authenticator app on my mobile device, which satisfies NIST SP 800-53's requirement of Multi-Factor authentication for secure access.
We'll now setup the VPN client by selecting "Download VPN Client" and downloading "Azure VPN" from the Microsoft Store. We'll import the Azure config file within the client into the "Azure VPN" app, and connected with Domain credentials, with an MFA prompt to the Microsoft Authenticator app on my mobile device, which satisfies NIST SP 800-53's requirement of Multi-Factor authentication for secure access.
V. File Server Deployment
V. File Server Deployment
VM Creation: To test internal access, we'll create a Gen 2 VM in the Hypervisor on VMHOST named "FS1".
Disk space: 300gb
Memory: 8gb
Network: Internal vSwitch
We'll then set the administrator password, logon, run updates, set the network settings appropriately to the lab (10.0.0.8/28) and domain-join the machine
VM Creation: To test internal access, we'll create a Gen 2 VM in the Hypervisor on VMHOST named "FS1".
Disk space: 300gb
Memory: 8gb
Network: Internal vSwitch
We'll then set the administrator password, logon, run updates, set the network settings appropriately to the lab (10.0.0.8/28) and domain-join the machine
We'll then reboot the FS1 VM and assign it the needed File server roles from Server Manager.
We'll then reboot the FS1 VM and assign it the needed File server roles from Server Manager.
We'll then need to create an external share that can be accessed by our Vpn User account. We'll create this share under "Shares" by the name of "ExtranetShare", and assign Read/Write access to the Extranet group. Restriction to this group is an example of Least Privilege Access and is adherent to NIST SP 800-53
We'll then need to create an external share that can be accessed by our Vpn User account. We'll create this share under "Shares" by the name of "ExtranetShare", and assign Read/Write access to the Extranet group. Restriction to this group is an example of Least Privilege Access and is adherent to NIST SP 800-53
Next we'll navigate back to the Azure portal and navigate to Enterprise Applications > Azure VPN > Properties and turn on the toggle for Assignment Required
Next we'll navigate back to the Azure portal and navigate to Enterprise Applications > Azure VPN > Properties and turn on the toggle for Assignment Required
About this time, it appeared that group assignments were unavailable for my subscription due to payment plan. So instead, I assigned individual SMMDEVICE/vpnuser access, and set explicit permissions for the user for read/write access to the file share.
After this was concluded, and VPN connection still active, I was able to find the server by hostname
About this time, it appeared that group assignments were unavailable for my subscription due to payment plan. So instead, I assigned individual SMMDEVICE/vpnuser access, and set explicit permissions for the user for read/write access to the file share.
After this was concluded, and VPN connection still active, I was able to find the server by hostname
Conclusion
This small showcase was the series of steps I had taken to allow VPN connectivity through Azure VPN deployment into my internal homely resources using a P2S connection and enabling S2S functionality.
Though there were a few hurdles and issues encountered during deployment, after deploying, connection to the internal file server (FS1) was successful!
Conclusion
This small showcase was the series of steps I had taken to allow VPN connectivity through Azure VPN deployment into my internal homely resources using a P2S connection and enabling S2S functionality.
Though there were a few hurdles and issues encountered during deployment, after deploying, connection to the internal file server (FS1) was successful!