Loading ...

Month: February 2017

Setup Azure to Unifi USG IPSec VPN

Had another tech firm that needed some Tier 3 assistance as they were having trouble with their VPN connection. I helped them setup Azure to Unifi USG IPSec VPN to connect their headquarters to the hosted RemoteApps server. This tutorial will go into detail about the creation of this tunnel starting with the Microsoft Azure side first using Resource Manager. It will be using the following parameters:

  • VNet Name: TestNetwork
  • Address Space: 10.10.0.0/16
  • Subnets:
    • Primary: 10.10.10.0/24
    • GatewaySubnet: 10.10.0.0/24
  • Resource Group: TestResourceGroup
  • Location: West US
  • DNS Server: Azure Default
  • Gateway Name: TestVPNGateway
  • Public IP: TestVPNGatewayIP
  • VPN Type: Route-based
  • Connection Type: Site-to-site (IPsec)
  • Gateway Type: VPN
  • Local Network Gateway Name: TestSite
  • Local Subnet: 10.20.20.0/24
  • Connection Name: VPNtoTestSite

Configure an Azure VPN gateway

This part takes the longest, so it should be done first:

  • Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Virtual Network Gateway” and click on the “Create” button.
    Azure Virtual Network Gateway
  • Give the Virtual Network Gateway a name
  • Select matching Region to where Azure resources are located
  • Leave Gateway & VPN type the defaults
  • Choose a SKU <- These have changed since the article was created, so my “standard” now is WpnGw1 with Active / Active turned off (this is a good balance of performance and cost)
  • Choose or create a local network (not covered here) that matches internal resources
  • Choose or create a Public IP Address
  • Leave the remaining values as their defaults and then click the “Create” button. (Please note the reminder that this takes 45 minutes to create!)
    Azure Virtual Network Gateway Setup

Configure an Azure Local Network Gateway

This is a reference to your on-premise network so that subnets can pass traffic:

  • Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Local Network Gateway” and click on the “Create” button.
    Azure Local Network Gateway
  • Give the Local Network Gateway a name
  • Select matching Region to where Azure resources are located
  • Specify the external IP address of the local on-premise site
  • Specify the on-premise address space (subnet)
  • Leave the remaining values as their defaults and then click the “Create” button.
    Azure Local Network Gateway Setup

Configure an Azure VPN Connection

This will create the tunnel from Azure to the on-premise site:

  • Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Connection” and click on the “Create” button.
    Azure VPN Connection
  • Choose “Site-to-site (IPSec)” as the connection type
  • Give the Connection a name
  • Select matching Region to where Azure resources are located
  • Leave the remaining values as their defaults and then click the “OK” button. On the summary screen click on the “OK” button to create the connection.
    Azure VPN Connection Setup #1
  • Choose the newly created Virtual Network Gateway
  • Choose the newly created Local Network Gateway
  • Specify a shared key
  • Leave the remaining values as their defaults and click the “Create” button.
    Azure VPN Connection Setup #2

This completes the setup of the Azure side of the VPN tunnel. Now to work on the Ubiquiti USG side.

Configuring an Ubiquiti USG VPN Network

This is a fairly simple process but it has to be precise:

  • Choose the Current Site from the top right hand side of the portal.
  • Click on the Settings gears down on the bottom left side of the portal.
  • Click on Networks then on the “Create New Network” button.
  • Give the connection a name, choose “Site-to-Site VPN” as the Purpose
  • Choose “IPSec VPN” as the VPN Type
  • Choose to Enable this Site-to-Site VPN
  • Add the Azure subnet under Remote Subnets
  • Get the newly created Virtual Network Gateway IP address from Azure for the Peer IP
  • Enter the on-premise external IP address for Local WAN IP
  • Enter the same shared key as used in the Azure VPN Connection for the Pre-Shared Key
  • Choose “Azure Dynamic Routing” as the IPSec Profile
  • Expand Advanced Options
  • Leave Key Exchange Version, Encryption, Hash & DH Group as default and uncheck the PFS & Dynamic Routing boxes.
    Ubiquiti USG VPN Connection Setup

That is all there is to it. If you have any difficulties with connection then delete and re-create the Ubiquiti USG side first (those two check boxes at the bottom of the Advanced Options will check themselves again, but don’t be fooled by this quirk in the software). If your company is currently using either Microsoft Azure or Ubiquiti USG routers and would like a VPN created, then contact us for assistance.

Using External Certificate for RemoteApps in .Local Domain

Recently did some Tier 3 support work for another technology company that was trying to setup a Windows Server 2016 RemoteApps server in Azure that would allow connectivity to remote users for their on-premise software. The process started with creating a VPN tunnel between on-premise and Azure, but that is a discussion for a future set of blog posts. Once this connection  was in place, the company tried to use an external certificate for RemoteApps setup on the server. This would have been fine if the internal domain had not been a “.local”  address scheme. This tutorial assumes that you have already installed Remote Desktop Services on a server and configured it to use the CA provided external certificate.

Change Remote Computer Name

One of the main sticking points that caused issues with security warnings for clients connecting is they would see the warning – “The remote computer could not be authenticated due to problems with its security certificate.” The fix for this has been graciously scripted in PowerShell by someone with the handle “TP” on Technet. The script is called Set-RDPublihedName.ps1 and is used as follows:

Set-RDPublishedName "remote.domain.com"

Proper Active Directory Group

There were then issues with the login process that caused the following error:

Remote Desktop can’t connect to the remote computer “<End Resource Name>” for one of these reasons:

1) Your user account is not authorized to access the RD Gateway “<RD Gateway Server Name>”
2) Your computer is not authorized to access the RD Gateway “<RD Gateway Server Name>”
3) You are using an incompatible authentication method (for example, the RD Gateway might be expecting a smart card but you provided a password)

This was coupled with Security Log messages – “The Network Policy Server was unable to connect to a domain controller in the domain where the account is located. Because of this, authentication and authorization for the RADIUS request could not be performed.” All this turned out to be the RD Gateway was not in the proper Active Directory Group, so added the server to the RAS and IAS Servers group.

Add URL to IIS

There was then an error about not being able to find the computer name, which turned out to be a setting in IIS. Looking under Sites > Default Web Site > RDWeb > Pages click on Application Settings and change the DefaultTSGateway to the URL of the CA external certificate for RemoteApps.

Fixing RS CAP & RAP

Last error that was received was the following:

Remote Desktop can’t connect to the remote computer “computername” for one of these reasons:

1) Your user account is not listed in the RD Gateway’s permission list
2) You might have specified the remote computer in NetBIOS format (for example, computer1), but the RD Gateway is expecting an FQDN or IP address format (for example computer1.fabrikam.com or 157.60.0.1).

This turned out to be related to the RD Client Access Policy (CAP) & Remote Access Policy (RAP) under the RD Gateway Manager tool and DNS. For RD CAP, make sure that Domain Users is listed, and that Client Computer Group membership is blank. FTor RD RAP, make sure that Domain Users is listed, and that it is set to allow connection to Any Network Resource (This allows remote access). For DNS, make sure it contains a Forward Lookup Zone that points to the URL of the CA external certificate for RemoteApps and has an A record for the internal IP address of the RD server.

If your company is currently moving some of your resources to the Azure cloud or wanting to properly setup your RemoteApps server, then contact us for assistance.

Cisco Meraki Ticking Time Bomb

A series of recent security bulletins from Cisco, on February 2nd, detail an issue that has been discovered in several of their devices. Here is a summation:

Cisco ASA Security Appliances

FN-64228 : ASA 5506, ASA 5506W, ASA 5506H, ASA 5508, and ASA 5516 – these models all use the same clock signal part from the same vendor which has been found to degrade over time. After 18 months of continued operation this component will fail and cause the device to stop functioning, no longer boot, and will not be recoverable.

“Customers with affected products that are under warranty or covered by any valid service contract as of November 16, 2016 should go to the Clock Signal Component Issue page and follow the instructions in order to request replacements.” These replacements will be prioritized based on time in operation.

Meraki Router & Wireless APs

Meraki Notification – MX 84 & MS350 Series – these models all use the same clock signal part from the same vendor which has been found to degrade over time. After 18 months of continued operation this component will fail and cause the device to stop functioning, no longer boot, and will not be recoverable.

” Meraki will reach out to customers via email and on the dashboard to arrange replacement and the return of affected units.”

If your company is currently using one of the affected devices and have not heard from your current IT services provider about the replacement schedule, then contact us for assistance.

Information Security while Traveling

The SANS Institute has been putting out the OUCH! newsletter for some time now in a project called Securing the Human. In the most recent Issue, they discuss some best practices and practical advice for traveling. Here are some highlights:

Minimize Possible Losses

Here are a few tips to protect information from the hazards of traveling and possible theft:

  • Remove any data that is not needed on the device
  • Use full disk encryption & strong passwords
  • Perform a complete backup before leaving
  • Install tracking software on the device
  • Update OSes and Antivirus

Lost/Stolen Devices

Although crime is more of a factor in some third world nations or those in active conflict, the human element of losing the device is 100x more likely. Keep inventory of your devices before, during and after transporting from one location to another. Do not leave your device in the hotel room, have the hotel front desk put it in their safe or locked administrative offices.

Public WiFi

If you have to connect to the internet in public spaces and/or cannot afford mobile data on your trip, then make sure to do the following:

  • Never use public computers for sensitive information, especially banking sites
  • When on public wifi, only surf to sites with HTTPS:// secure connections
  • Consider connecting to a VPN service to further encrypt communications

If your company is requires traveling or you are planning to remotely work while on vacation, then contact us for assistance. We would be happy to walk you through the full disk encryption process, update / secure your devices and configure a company VPN service to connect to on the go.

Archives

Categories

Plant a Seed @ 541-761-9549
233 Rogue River Hwy #873 Grants Pass, OR 97527
Mon-Fri: 9:00am-5:00pm
support@farmhousenetworking.com
© 2016-2023- Farmhouse Networking. All rights reserved
Terms and Conditions Privacy Policy

Evaluation Signup

[contact-form-7 id="452" title="Free Network Evaluation"]