How to create a VPN between Azure and AWS using only managed solutions

How to create a VPN between Azure and AWS using only managed solutions

This article is contributed. See the original author and article here.

What if you can establish a connection between Azure and AWS using only managed solutions instead to have to use virtual machines? This is exactly what we’ll be covering on this article connecting AWS Virtual Private Gateway with the Azure VPN Gateway directly without worry to manage IaaS resources like virtual machines.


 


Below the draw of our lab:


draw.png


 


Regarding the high availability, please note that on AWS, by default a VPN connection always will have 2 Public IPs, one per tunnel. On Azure it doesn’t happens by default and in this case you will be using Active/Passive from Azure side.


 


This means that we will be setting only one “node” from Azure VPN Gateway to establish two VPN connections with AWS. In case of a failure, the second node from Azure VPN Gateway will connect to AWS in a Active/Passive mode.


 


Configuring Azure


 


1. Crate a resource group on Azure to deploy the resources on that


 


newrg.png


 


create.png


 


Choose the subscription, the name and the region to be deployed:


 


creating.png


 


2. Create a Virtual Network and a subnet


 


createvnet.png


 


createvnetbutton.png


 


Define the subscription, resource group, name and region to be deployed:


 


vnetdefinitions.png


 


Set the address space for the virtual network and for the subnet. Here I’m defining the virtual network address space to 172.10.0.0/16, changing the “default” subnet name to “subnet-01” and defining the subnet address range to 172.10.1.0/24:


 


vnetaddr.png


 


vnetvalidation.png


 


3. Create the VPN Gateway


 


The Azure VPN Gateway is a resource composed of 2 or more VM’s that are deployed to a specific subnet called Gateway Subnet where the recommendation is to use a /27. He contain routing tables and run specific gateway services. Note that you can’t access those VM’s.


To create, go to your Resource Group, then click to + Add


 


addvpngw.png


 


newvpngw.png


 


createvpngw.png


 


Then fill the fields like below:


 


vpngwsummary.png


 


After click to Review + create, in a few minutes the Virtual Network Gateway will be ready:


 


vpnready.png


 


Configuring AWS


 


4. Create the Virtual Private Cloud (VPC)


 


createvpc.png


 


5. Create a subnet inside the VPC (Virtual Network)


 


createsubnetvpc.png


 


6. Create a customer gateway pointing to the public ip address of Azure VPN Gateway


 


The Customer Gateway is an AWS resource with information to AWS about the customer gateway device, which in this case is the Azure VPN Gateway.


 


createcustomergw.png


 


7. Create the Virtual Private Gateway then attach to the VPC


 


createvpg.png


 


attachvpgtovpc.png


 


attachvpgtovpc2.png


 


8. Create a site-to-site VPN Connection


 


createvpnconnection.png


 


Set the routing as static pointing to the azure subnet-01 prefix (172.10.1.0/24)


 


setstaticroute.png


 


After fill the options, click to create.


 


9. Download the configuration file


 


Please note that you need to change the Vendor, Platform and Software to Generic since Azure isn’t a valid option:


 


downloadconfig.png


 


In this configuration file you will note that there are the Shared Keys and the Public Ip Address for each of one of the two IPSec tunnels created by AWS:


 


ipsec1.png


 


ipsec1config.png


 


ipsec2.png


 


ipsec2config.png


 


After the creation, you should have something like this:


 


awsvpnconfig.png


 


Adding the AWS information on Azure Configuration


 


10. Now let’s create the Local Network Gateway


 


The Local Network Gateway is an Azure resource with information to Azure about the customer gateway device, in this case the AWS Virtual Private Gateway


 


newlng.png


 


createnewlng.png


 


Now you need to specify the public ip address from the AWS Virtual Private Gateway and the VPC CIDR prefix.


Please note that the public address from the AWS Virtual Private Gateway is described at the configuration file you have downloaded.


As mentioned earlier, AWS creates two IPSec tunnels to high availability purposes. I’ll use the public ip address from the IPSec Tunnel #1 for now.


 


lngovwerview.png


 


11. Then let’s create the connection on the Virtual Network Gateway


 


createconnection.png


 


createconnection2.png


 


You should fill the fields according below. Please note that the Shared key was obtained at the configuration file downloaded earlier and In this case, I’m using the Shared Key for the Ipsec tunnel #1 created by AWS and described at the configuration file.


 


createconnection3.png


 


After a few minutes, you can see the connection established:


 


connectionstablished.png


 


In the same way, we can check on AWS that the 1st tunnel is up:


 


awsconnectionstablished.png


 


Now let’s edit the route table associated with our VPC


 


editawsroute.png


 


And add the route to Azure subnet through the Virtual Private Gateway:


 


saveawsroute.png


 


12. Adding high availability


 


Now we can create a 2nd connection to ensure high availability. To do this let’s create another Local Network Gateway which we will point to the public ip address of the IPSec tunnel #2 on the AWS


 


createlngstandby.png


 


Then we can create the 2nd connection on the Virtual Network Gateway:


 


createconnectionstandby.png


 


And in a few moments we’ll have:


 


azuretunnels.png


 


awstunnels.png


 


With this, our VPN connection is established on both sides and the work is done.


 


13. Let’s test!


 


First, let’s add an Internet Gateway to our VPC at AWS. The Internet Gateway is a logical connection between an Amazon VPN and the Internet. This resource will allow us to connect through the test VM from their public ip through internet. This is not required for the VPN connection, is just for our test:


 


createigw.png


 


After create, let’s attach to the VPC:


 


attachigw.png


 


attachigw2.png


 


Now we can create a route to allow connections to 0.0.0.0/0 (Internet) through the Internet Gateway:


 


allowinternetigw.png


 


On Azure the route was automatically created. You can check selecting the Azure VM > Networking > Network Interface > Effective routes. Note that we have 2 (1 per connection):


 


azureeffectiveroutes.png


 


Now I’ve created a Linux VM on Azure and our environment looks like this:


 


azoverview.png


 


And I did the same VM creation on AWS that looks like this:


 


awsoverview.png


 


Then we can test the connectivity betweeen Azure and AWS through our VPN connection:


 


azureping.png


 


awsping.png


 

Multi-tenant Data for ISVs

This article is contributed. See the original author and article here.

permalink: https://aka.ms/FTAISVmultitenant-data


 


reference links permalink:  https://aka.ms/FTAISVmultitenant-data-resources


 


The very nature of an ISV’s business model is to provide a solution applicable to many customers. These multi-tenant solutions require multi-tenant database services as well. But how do you implement multitenancy in a database securely and at scale? How will I balance performance and cost?


 


In this video we’ll introduce you to the design considerations that impact multi-tenant architectures. We’ll then review some of the core design patterns used to implement multi-tenant solutions. For each pattern, we’ll discuss the pros, cons and tradeoffs you will need to consider when choosing a design pattern. Finally, we’ll review some of the tooling that is frequently used to support multi-tenant solutions.


 


Changes to driver signing for Windows 7, Windows Server 2008 R2, and Windows Server 2008

This article is contributed. See the original author and article here.

Effective June 17, 2021, Microsoft partners should utilize the process below to sign drivers for Windows 7, Windows Server 2008, and Windows Server 2008 R2 through the Partner Center for Windows Hardware.



  1. Remove existing signatures from driver binaries.

  2. Generate new catalog files using INF2CAT.

  3. Sign the security catalog files using the IHV/OEM certificate registered with the Partner Center for Windows Hardware.

  4. Add the driver to your HCK file.

  5. Sign the HCK file using the IHV/OEM certificate registered with the Partner Center for Windows Hardware.

  6. Submit the driver package to the Partner Center for Windows Hardware for signing.

  7. Download the signed driver bundle from the Partner Center for Windows Hardware.


As noted in our post on Changes to driver publication for Windows 7 SP1, Windows Server 2008 R2, and Windows Server 2008, Microsoft will discontinue the publication of drivers to Windows Update for Windows 7 SP1, Windows Server 2008, and Windows Server 2008 R2; however, signed drivers will continue to be made available to ensure optimal driver reliability for Volume Licensing customers who have elected to participate in an Extended Security Update (ESU) program. Windows 7, Windows Server 2008, and Windows Server 2008 R2 driver submissions for the Windows Hardware Compatibility Program (WHCP) will continue to be available through January 2023.


 

Changes to driver publication for Windows 7 SP1, Windows Server 2008 R2, and Windows Server 2008

This article is contributed. See the original author and article here.

On June 17, 2021, Microsoft will discontinue the publication of drivers to Windows Update for Windows 7 SP1, Windows Server 2008, and Windows Server 2008 R2. If your organization utilizes the Extended Security Updates (ESU) program, you will continue to have the ability to deploy drivers to your managed devices using Windows Server Update Services (WSUS_ and other supported methods.


As previously communicated, the SHA-1 Trusted Root Certificate Authority expired for Windows 7 SP1, Windows Server 2008, Windows Server 2008 R2 on May 9, 2021 and is no longer used by Microsoft. Due to the discontinuation and expiration of SHA-1 certificates, partners utilizing the Microsoft Trusted Root Program could publish incompatible SHA-2 signed drivers to unpatched Windows client and Windows Server devices. This, in turn, had the potential to cause degraded functionality or to cause devices to longer boot. This occurs because unpatched systems will have code integrity failures when presented with a SHA-2 signed driver.


To minimize the potential impact of these incompatibilities, Microsoft will discontinue publishing of SHA-2 signed drivers to Windows Update that target Windows 7 SP1, Windows Server 2008, Windows Server 2008 R2 devices on June 17, 2021. While these Windows versions reached the end of support on January 14, 2020, we are making this change to diminish disruptions for users who still remain on these versions of Windows. This includes:



  • Any driver package submitted for multi-targeting for currently supported versions of Windows and Windows Server

  • Any driver package targeting versions of Windows or Windows Server that have reached the end of support.


When this change occurs, a notification will be sent to the submitter and they will need to resubmit the shipping label for publishing after they have removed the unsupported versions.









Note: SHA-1 certificates are expired and are already no longer a publishing option for Windows Update.



Continuation of driver signing


Windows 7, Windows Server 2008, and Windows Server 2008 R2 driver submissions for the Windows Hardware Compatibility Program (WHCP) will continue to be available through January 2023. These submissions will continue to be made available to ensure optimal driver reliability for Volume Licensing customers who have elected to participate in the Extended Security Update (ESU) program.


We’re here to help


To test and certify hardware devices for Windows, we recommend that you utilize the Windows Hardware Certification Kit (Windows HCK) and follow the updated driver signing process for Windows 7, Windows Server 2008 and Windows Server 2008 R2 when submitting a driver package for signing via the Partner Center for Windows Hardware.


For more information on ESUs for Windows 7, see the Windows 7 end of support FAQ or the Window Server 2008 and 2008 R2 end of support FAQ. Partners seeking additional assistance are encouraged to reach out to their Microsoft account representatives.


 

Microsoft Viva Insights | Improve productivity and wellbeing | Demo and tutorial, including set-up

Microsoft Viva Insights | Improve productivity and wellbeing | Demo and tutorial, including set-up

This article is contributed. See the original author and article here.

See how Microsoft Viva Insights delivers data-driven privacy, protected insights, and recommended actions to help individuals and teams improve productivity and wellbeing. Engineering leader, Kamal Janardhan, joins Jeremy Chapman for a deep dive and a view of your options for configuration.


 


Screen Shot 2021-06-17 at 1.52.18 PM.png


 














QUICK LINKS:











Link References:



 


Unfamiliar with Microsoft Mechanics?




 


Keep getting this insider knowledge, join us on social:










Video Transcript: