Issue with using Windows Server 2012 RRAS as a local VPN device with Microsoft Azure when WAN interface has DHCP assigned IP address

In my personal lab I use a Windows Server 2012 R2 VM running on a local Hyper-V server as my VPN device to connect to a Microsoft Azure Virtual Network gateway. This setup has been working fine for quite some time, and is indeed a supported configuration. Recently though I could not make it connect. Come hear the story…

My ISP (Telenor) here in Norway is gracious enough to provide me with 2 dynamically assigned official IPv4 addresses. I use one for my home network and the other for the Azure gateway. I hadn’t used the lab for some time so the S2S VPN had been down. When I tried to reconnect it wouldn’t work.I knew Microsoft had made some changes recently, these were announced during Build 2014, so I figured I would reset the RRAS configuration and run the VPN setup from scratch. So I disabled the RRAS service and downloaded a fresh VpnDeviceScript.cfg file from the portal an redid everything. This didn’t take more than a couple of minutes, but still I could not connect. I noticed that when the RRAS service started I lost all connectivity on my WAN (Internet) interface. I could ping an address on the Interne, but the ping immediately stopped when RRAS started. I fired up Wireshark and did a trace of the WAN interface during RRAS startup and discovered that when the service starts several DHCP Discover messages were sent out on the WAN interface:

image

Since my ISP only allows 2 IPs this made the original address I had received on the WAN interface invalid. But why did it happen?

Also during RRAS startup I got this warning in the System log:

image

When RRAS is running as a remote access service, which it does when providing Site-2-Site VPN tunneling, it also supports incoming VPN requests from clients. These clients need an IP address to be able to communicate on the local network. They get this address either from the RRAS server itself and a static IP pool, or from a DHCP server on the local network where the RRAS reserves IP addresses in blocks of 10. In my case I had DHCP selected and thus no static IP pool configured. If the RRAS server is multi-homed, which it usually is, you can select which interface RRAS looks for a local DHCP server on.This settings is configured through the RRAS server properties:

image

The default setting is Allow RAS to select adapter. This was the cause of my problem. The RRAS service selected my WAN interface and send out a bunch of DHCP Discover messages to allocated IP addresses for incoming clients. This invalidated my existing DHCP lease and stopped all communication on the Internet. Once I selected the internal (LAN) Interface I could connect fine.

I guess this problem can occur in any S2S or RAS scenario where the WAN IP address is dynamically assigned.

Get-ADUser quirkiness

So I was trying to find all the users in an Active Directory domain that had a manager. Naturally I turned to PowerShell and the Get-ADUser cmdlet.

First I tried this:

Get-ADUser -Properties Manager -Filter { manager -like “*” }

That threw this error:

Get-ADUser : Operator(s): The following: ”Eq’, ‘Ne” are the only operator(s) supported for searching on extended
attribute: ‘Manager’.

OK, so we can only use the operators eq (equals) and ne (not equals) when working with what the Active Directory PowerShell module defines as extended properties. But these only work if you are interested in specific values. I wanted to find any user that had a manager defined, regardless of who it was. So I could not use eq or ne.

So then I did this:

Get-ADUser -Properties Manager -Filter * | where { $_.manager -ne $null }

Which works, but returns every user from Active Directory and then PowerShell does the filtering. Not optimal code. I could have left if there, but you know…

This is what I ended up with:

Get-ADUser -Properties Manager -LDAPFilter “(manager=*)”

This uses the power of filtering within the directory service.