Problem

I’ve run into an issue when a customer was using a Cisco ASA 5515 to connect into our WAP deployment. Cisco is a big player in the networking market and one would think that connecting a device such as this to a Windows Server Gateway (WSG) WAP S2SVPN would be straight forward.

Reason

There are a few key implementation differences with how the WSG and Cisco ASA implement IKEv2. As WSG uses RRAS under the hood, we have to look at how RRAS works. Currently RRAS is configured to send an IKEv2 tunnel with a Traffic Selector of “*”/any. This to me was kind of a surprise as these settings are configured during the WAP S2SVPN IKEv2 configuration. The Cisco ASA is not such a lenient device and denies the request of using the “*”.

More details about the Traffic Selector can be found here: http://blogs.technet.com/b/networking/archive/2014/12/26/vpn-interoperability-guide-for-windows-server-2012-r2.aspx

Now this is only happens if the RRAS dials out to the Cisco ASA endpoint. There are no problems if the Cisco ASA initiates the tunnel as RRAS will accept the Traffic Selectors sent by Cisco.

Solution

How do we fix this? Well to do that, we have to tell the WSG to only listen for VPN connections for this S2SVPN configuration. We require the Cisco to initiate connections. Just the other day, I received confirmation from Microsoft that a hotfix is available. Even though it is available, I think I will show the long way of working around the issue and digging under the hood a little bit. To do this, we have to rely on our great friend, PowerShell!

Solution 1

Using the PowerShell method to dig into the S2SVPN configuration and update it.

Retrieve the Current S2SVPN Configuration

$routingdomain = "CustomerCiscoS2SVPN"
$vpn = Get-VpnS2SInterface -RoutingDomain $routingdomain
$vpn | fl

Now if you run the above commands you’ll get back the VPN configuration. Now unfortunately the properties we require to validate are not outputted by the default $vpn |fl output. To see all properties for any given PowerShell object, use “fl *”. This will output all properties and their values:

$vpn | fl *

 The three properties that we’re concerned with are (https://msdn.microsoft.com/en-us/library/hh833292(v=vs.85).aspx):

  1. Persistent
  2. IPv4Subnet
  3. PostConnectionIPv4Subnet

To view the PowerShell run:

$vpn.IPv4Subnet
$vpn.Persistent
$vpn.PostConnectionIPv4Subnet 
 

Default values:

  1. You’ll notice that Persistent is True
  2. IPv4Subnet is the subnet(s) configured for subnets on the remote end of the tunnel
  3. PostConnectionIPv4Subnet is blank.

The goal here is to reconfigure the VPN configuration so that the WSG does not dial the Cisco ASA. If you’ve read the msdn link I have posted above you might already have keyed into what we’re going to do. We are going to set the IPv4Subnet to blank. What this does is removes the network trigger that tells RRAS to open the tunnel if it’s disconnected and it has to send outgoing traffic to any of the subnets listed in the IPv4Subnet property. If it finds a matching subnet, it will try to open the tunnel. Because we’re setting this to a blank value, it will never find a match. Once the Cisco ASA creates the tunnel, we need to update our routing table so that WSG knows to route specific tenant subnets across that tunnel. This is where the PostConnectionIPv4Subnet setting comes in. We’re basically going to move all the subnets from the IPv4Subnet property to the PostConnectionIPv4Subnet property.

Update the S2SVPN Configuration

Get-VpnS2SInterface -RoutingDomain $routingdomain | Set-VpnS2SInterface
 -Persistent:$false -PostConnectionIPv4Subnet "10.1.0.0/24:900" -IPv4Subnet @() -Force
$vpn = Get-VpnS2SInterface -RoutingDomain $routingdomain
$vpn | fl *

 

Now if you look at the three values, they’ll have the updated configuration.

$vpn.IPv4Subnet
$vpn.Persistent
$vpn.PostConnectionIPv4Subnet

Solution 2

As mentioned in solution 1, that was the original way and you can see how some of the WSG/RRAS troubleshooting was done. Microsoft has just released the hotfix yesterday, October 13, 2015. I have yet to test the hotfix to confirm if it fixes the problem above.

https://support.microsoft.com/en-us/kb/3091402