Setting Up L2VPN in VMC on AWS

In VMC on AWS SDDC, you can extend your on-premise network to VMC SDDC via HCX or L2VPN.

In this blog, I will show you how to set up L2VPN in VMC on AWS to extend network VLAN 100 to SDDC.

This blog is for VMC SDDC, running at version 1.9, which is backed by NSX-T 2.5. The SDDC end will work as a L2VPN server and your on-premise NSX autonomous edge will work as a L2VPN client.

Prerequisite

  • UDP 500/4500 and ESP (IP Protocol) are allowed from the On-premise L2VPN client to the VMC SDDC L2VPN Server

Let’s start the setup from the VMC SDDC end.

Section 1: Set up L2VPN at VMC SDDC End

Step 1: Log in to your VMC Console, go to Networking & Security—>Network—>VPN—>Lay2 and click “ADD VPN TUNNEL”.

Select Public IP from the local IP Address drop-down and input the public IP of L2VPN’s remote end. As on-premise NSX Edge is behind a NATed device, the remote private IP is required. In my case, the remote private IP is 10.1.1.240.

Step 2: Create an extended network.

Go to Network—>Segment and add a new segment as below.

  • Segment Name: l2vpn;
  • Connectivity: Extended;
  • VPN Tunnel ID: 100 (please note that the tunnel ID needs to match the on-prem tunnel ID)

After the network segment is created, you will see the below in layer 2 VPN.

Now we can begin to download the AUTONOMOUS EDGE from the highlighted hyperlink above.

While the file is downloading, we can download the peer-code which will be used for authentication between on-premise L2VPN client and SDDC L2VPN server.

The downloaded config is similar to below:

[{"transport_tunnel_path":"/infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/7998a0c0-52b7-11ea-b949-d95049696f90","peer_code":"MCxiNmY2NTg1LHsic2l0ZU5hbWUiOiJMMlZQTiIsInNyY1RhcElwIjoiMTY5LjI1NC4yMC4yIiwiZHxxxxxxxxxxxxxxxxxGgxNCIsImVuY3J5cHRBbmREaWdlc3QiOiJhZXMtZ2NtL3NoYS0yNTYiLCJwc2siOiJOb25lIiwidHVubmVscyI6W3sibG9jYWxJZCI6IjEwLjEuMS4yNDAiLCJwZWVySWQiOiI1Mi4zMy4xMjAuMTk4IiwibG9jYWxWdGlJcCI6IjE2OS4yNTQuMzEuMjU0LzMwIn1dfQ=="}]

Section 2: Deploy and Setup On-premise NSX autonomous edge

Step 1: Prepare Port Groups.

Create 4 port-groups for NSX autonomous Edge.

  • pg-uplink (no vlan tagging)
  • pg-mgmt
  • pg-trunk01 (trunk)
  • pg-ha

We need to change the trunk port-group pg-trunk01 security setting to accept promiscuous mode and forged transmits. This is required for L2VPN.

Step 2: Deploy NSX Autonomous Edge

We follow the standard process to deploy an OVF template from your vCenter. In “Select Network” of the “Deploy OVF Template” wizard, map the right port-group to different networks. Please note Network 0 is always the management network port for the NSX autonomous edge. To make it simpler, I only deployed a single edge here.

The table below shows the interface/network/adapter mapping relationship in different systems/UI under my setup.

Edge CLIEdge VM vNICOVF TemplateEdge GUIPurpose
eth0Network Adapter1Network 0ManagementManagement
fp-eth0Network Adapter2Network 1eth1Uplink
fp-eth1Network Adapter3Network 2eth2Trunk
fp-eth2Network Adapter4Network 3eth3HA

In the “Customize template” section, provide the password for the root, admin and auditor.

Input hostame(l2vpnclient), management IP (10.1.1.241), gateway (10.1.1.1) and network mask (255.255.255.0).

Input DNS and NTP setting:

Provide the input for external port:

  • Port: 0,eth1,10.1.1.240,24.
    • VLAN 0 means no VLAN tagging for this port.
    • eth1 means that the external port will be attached to eth1 which is network 1/pg-uplink port group.
    • IP address: 10.1.1.240
    • Prefix length: 24

There is no need to set up the Internal Port for the autonomous edge deployment. So I left it as blank.

Step 3: Autonomous Edge Setup

After the edge is deployed and powered on, you can log in to the edge UI via https://10.1.1.241.

Go to L2VPN and add a L2VPN session, input the Local IP (10.1.1.240), Remote IP (SDDC public IP) and Peer Code which I got from the downloaded config in section 1.

Go to Port and add port:

  • Port Name: vlan100
  • Subnet: leave as blank
  • VLAN: 100
  • Exit Interface: eth2 (Note: eth2 is connected to the port-group pg-trunk01).

Then go back to L2VPN and attach the newly created port VLAN100 to the L2VPN session as below. Please note that the Tunnel ID is 100, which is the same tunnel ID as the SDDC end.

After the port is attached successfully, we will see something similar to below.

This is the end of this blog. Thank you very much for reading!

Setting Up Federated Identity Management for VMC on AWS – Authentication with Azure AD

The Federated Identity feature of VMware Cloud on AWS can be integrated with Microsoft Azure AD as well. In this integration model, the customer dedicated vIDM tenant will work as the SAML Service Provider and the Azure AD will work as the IdP.

Disclaimer:

The Azure AD settings in this blog are to demo the integration for vIDM, which may not be the best practise for your environment or meet your business and security requirements.

Note: please complete the vIDM connector installation and the vIDM tenant basic setup as per my first blog of this series (https://davidwzhang.com/2019/07/31/setting-up-federated-identity-management-for-vmc-on-aws-install-and-setup-vidm-connector/) before continuing.

The AD domain name for this blog is davidwzhang.com.

Prerequisite

  • The on-prem domain has been added as a custom domain under your default Azure AD.
  • Azure AD PREMIUM (P1 or P2) feature is enabled.
  • On-prem AD users/groups are synced with Azure AD.

Step 1: Add Azure AD as an IdP

First, login to your Azure Portal https://portal.azure.com and select Azure Active Directory.

Find “Enterprise Applications” in the list under my default Azure Active Directory (vmconaws) and then create a “New Application”. In the “Add your own app” window, select “Non-gallery application” and input the application name “csp-vidm” and click the “Add” button as below.

In the popped up “Enterprise Application” window, select “Set up single sign-on” under “Getting Started”.

In the pop-up “Select a single sign-on method” window, select SAML.

Next, click the Download hyperlink to download the Azure AD federation metadata XML file or copy the App Federation Metadata URL.

Now we have to pause here. You may have noticed that we still have two pending SAML configuration items: Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL). We will come back to complete these items once we get the required SAML Service Provider metadata from the vIDM tenant.

Step 2: Create an Identity Provider in vIDM Tenant

Go to the vIDM tenant administrator console and click “Add Identity Provider” and select “Create Third Party IDP” within the “Identity & Access Management” tab.

Input the parameters as below:

  • Identity Provider Name: AzureAD
  • SAML AuthN Request Binding: HTTP Redirect

In the SAML Metadata section, copy the content of downloaded Azure AD federation metadata XML file to the text box of Identity Provider Metadata(URL or XML) then click the button “Process IdP Metadata”.

Next, add two Name ID format mappings as the below:

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress = emails
  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified = uerName

Then from the dropdown of the “Name ID policy in SAML request (Optional)”, select “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”

The rest of the settings are as below:

  • Just-in-Time User Provisioning: Disabled
  • Users: davidwzhang.com
  • Network: ALL Ranges
  • Authentication Methods
    • Authentication Methods: AzureADPassword
    • SAML Context: urn:oasis:names:tc:SAML:2.0:ac:classes:Password 
  • Single Sign-Out Configuration: Disabled

Then click the hyperlink of “Service Provider (SP) Metadata” to open the SAML Service Provider metadata in a browser. Then you can find the Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL) which are required to complete the Azure AD IdP SAML setup.

Now, click the “Save” button to save the IdP setup.

Step 3: Add SAML Information for Azure AD

Go back to Azure Portal and continue the Single Sign-on SAML setup.

Edit the basic SAML configuration.

Copy the Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL) which we got in the last step, to the corresponding text box and save the configuration.

Next, add user groups which are granted access to the VMware Cloud service console to this newly created application. Here two groups (sddc-admins and sddc-operators) are added.

Now we have finished the configuration of Azure AD IdP.

Step 4: Update Authentication Policy

Update the vIDM tenant’s default access policy to include AzureADPassword as the first authentication method.

Now, when you try to log into the VMware Cloud service console with your AD account, your login session will be redirected to the Azure AD as below, which authenticates your session.

Setting Up Federated Identity Management for VMC on AWS – Authentication with ADFS

The Federated Identity feature of VMware Cloud on AWS can be integrated with Microsoft Active Directory Federation Services (ADFS). In this integration model, the customer dedicated vIDM tenant will work as the SAML Service Provider and the ADFS will work as the IdP.

Disclaimer:

The ADFS settings in this blog are to demo the integration for vIDM, which may not be the best practise for your environment or meet your business and security requirements.

Note: please complete the vIDM connector installation and the vIDM tenant basic setup as per my first blog of this series (https://davidwzhang.com/2019/07/31/setting-up-federated-identity-management-for-vmc-on-aws-install-and-setup-vidm-connector/) before continuing.

The AD domain name for this blog is davidwzhang.com.

The ADFS is installed on a Windows 2016 standard server. The DNS name for ADFS service is adfs1.davidwzhang.com.

Step 1: Get the ADFS Metadata Information.

The URL to this ADFS metadata is https://adfs1.davidwzhang.com/FederationMetadata/2007-06/FederationMetadata.xml. Click the URL to download the metadata XML file.

Step 2: Create an Identity Provider in vIDM Tenant

Go to the vIDM tenant administrator console and click “Add Identity Provider” and select “Create Third Party IDP” within the “Identity & Access Management” tab.

Input the parameters as below:

  • Identity Provider Name: ADFS01
  • SAML AuthN Request Binding: HTTP Redirect

In the SAML Metadata section, copy the content of XML file FederationMetadata.xml to the text box of the Identity Provider Metadata (URL or XML) then click the button “Process IdP Metadata”. The Name ID Format section will have 3 entries popped up.

Now, click the green plus icon to add a new mapping as the below:

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified – userName.

Then from the dropdown of the “Name ID policy in SAML request (Optional)”, select “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”

The rest of the settings are as below:

  • Just-in-Time User Provisioning: Disabled
  • Users: davidwzhang.com
  • Network: ALL Ranges
  • Authentication Methods
    • Authentication Methods: ADFS Password
    • SAML Context: urn:oasis:names:tc:SAML:2.0:ac:classes:Password 
  • Single Sign-Out Configuration: Disabled

Then click the hyperlink of “Service Provider (SP) Metadata” to download the Service Provider metadata and upload it to the ADFS server.

Step 3: Update Authentication Policy

Update the vIDM tenant’s default access policy to include ADFS as the first authentication method.

Step 4: Configure ADFS Relying Party

Now it is time to setup the ADFS. First, start the ADFS Management tool from Server Manager and add a Relying Party Trust as the below.

In the welcome screen of “Add Relying Party Trust” wizard, select “Claim aware” and click the Start button.

Select the uploaded sp.xml file in step 2 to import data about the relying party and then click the Next button.

Input “vmccsa-demo” as the relying party display name, then click the Next button.

Choose “Permit everyone” as the Access Control Policy and click the Next button. Note: please select different access control policies for your use case.

Click the Next button.

Now, click the Close button to finish the wizard.

Step 5: Create ADFS Relying Party Claim Rules

Select the newly created relying party, right click and select “Edit Claim Issue Policy…”.

Click the “Add Rule…” button to add a new Transform rule.

In the “Choose Rule Type” step of the “Add Transform Claim Rule” wizard, select “Select LDAP Attributes as Claims” and click the Next button.

Input the following parameters:

  • Claim rule name: Get Attribute Email Address
  • Attribute store: Active Directory
  • Mapping of LDAP attributes to outgoing claim types:
    • LDAP Attribute: E-Mail-Addresses
    • Outgoing Claim Type: E-Mail Addresses

Click the Finish button. Then add the second new rule. The new rule will use “Send Claims Using a Custom Rule” as its rule template.

Next, input the name and custom rule:

The content of the “Custom rule” is as below. Please replace “xxxxx.vidmreview.com” with your own vIDM tenant URL.

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "xxxxx.vidmreview.com");

Now, when you try to log into the VMware Cloud service console with your AD account, your login session will be redirected to the ADFS as below, which authenticates your session.