Expose the Azure Stack Portal through NAT

 Intro

Mark Scholman already published an excellent blog about exposing the portal with a new public FQDN for new Azure Stack deployments. However, this requires a fresh install and takes some time and functionality to get all the settings right. But, what about exposing the portal if you already deployed Azure Stack? Believe it or not, it is in fact quite easy if you use my script. It configures the MAS-BGPNAT-01 NAT network adapter to expose and map the Portal, API,  ACS, SQL/MySQL RP and AppService ports on four new external addresses you have to reserve in the network that your Host is in. The NAT network adapter has the same network configured as the host, thats because the Azure Stack deployment scripts extended the host network to a virtual ‘public switch’ and connected the NAT adapter of the BGPNAT-01 to it. This way internal virtual machines are able to route their internet traffic through NAT but also allows us to map static ports to internal Azure Stack services. The deployment scripts automatically configured the NAT network adapter for DHCP, unless you specified the NAT parameters (NatIPv4Address etc), then a  static IP address is configured. More information can be found at  https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-run-powershell-script

This script only facilitates in exposing the portal outside the internal Azure Stack environment, you have to make sure your clients can reach the network your Host and the NAT adapter is in by routing their networks (internet/internal) to it, if you haven’t done that already. Also be sure to check and configure firewalls if you plan to use public addresses.

Script

You need to reserve and supply two IP addresses for basic portal functionality and two more if you deployed the App Service.  Download the script from the TechNet gallery, unblock it and execute it under the ‘AzureStackAdmin’ user account on the Azure Stack Host. Supply the reserved IP addresses to the script using the ‘PortalExternalIP’ and ‘ACSExternalIP’ parameter and specify AppServiceAPIExternalIP and AppServiceExternalIP parameters when you deployed App Service.

screenshot_9

The script creates a remote PowerShell session to the MAS-BGPNAT01 and executes the PowerShell NAT commands. These commands will automatically add the external IP addresses to the NAT interface and to the ‘NAT’ network adapter where it also creates the static port mappings. Then it exits the PowerShell session and copies the Azure Stack root certificate file for your convenience to the clipboard. Paste the certificate file in a folder and import the certificate file to the ‘Trusted Root certification Authorities’ store.

screenshot_10

If for some reason you specified the wrong IP addresses and want to roll back then execute the script with the ‘-ClearNATConfig’ parameter, it will clear all  NAT configuration set by the script.

screenshot_11

Certificate and DNS

You need to install the Azure Stack root certificate on clients outside the Azure Stack environment to trust *.azurestack.local and have a functional portal. Distribute the certificate using a GPO when you want to access Azure Stack for domain joined clients.

And last but not least, DNS. You have to configure your DNS server or your local ‘hosts’ file to point the local ‘azurestack.local’ subdomains to the right IP address. There are a lot of azurestack.local subdomains and some of them are dynamically generated and based on your storage account or application. So, ideally you want to use a DNS server  instead of a hosts file and set DNS wildcard records. All storage related FQDN’s go to the IP you supplied for the ‘-ACSExternalIP’ parameter and all other go to the ‘-PortalExternalIP’ IP. App Service API calls for portal functionality go to the AppServiceAPIExternalIP and access to Apps and deployment tools FQDN’s go to the AppServiceExternalIP. Below an example with the port mappings made and the host names you have to set in DNS.
screenshot_42

You can also use the hosts file on your client, however, it does not support wildcards. You have to specify each dynamically generated FQDN (storage account or App) , otherwise,  some storage or app related functionality might not function correctly. For example; you have to specify three FQDN’s for every storage account you create. Like ‘yourstorageaccount’.blob.azurestack.local’, ‘yourstorageaccount’.table.azurestack.local’ and ‘yourstorageaccount’.queue.azurestack.local’. I captured all URL’s the browser queries and worked them out in the hosts file example below, replace them with your own external IP’s.

Now you’re ready to access the Portal and API’s (PowerShell/VisualStudio) from outside the Azure Stack deployment without using VPN or RDP. Happy Stacking!

Ruud

Spread the word. Share this post!

Ruud Borst

About the author

Ruud Borst works as a Cloud Architect at 'KPN - internedservices', the biggest telecom and ICT company of the Netherlands. With over more then 15+ years experience in the Microsoft Cloud business he can be seen as an old but lively veteran. Started with MPS as his first Microsoft provisioning platform for hosting services and having built several (PowerShell) provisioning systems, he now works on the next generation Cloud platform, Azure Stack. He's very enthusiastic about Microsoft's Hybrid Cloud proposition, the challenges it solves and how it will affect customers and IT in general.

Contact:
Email: ruud@ruudborst.nl
Twitter: @ruud_borst
LinkedIn: https://nl.linkedin.com/in/ruudborst
Technet: https://social.technet.microsoft.com/profile/ruud%20borst/