Radius authentication does not work in Strongswan, when comming from a Windows VPN client?

My strongswan VPN server is authenticating VPN clients against a local Freeradius server.

All user logings is proxied to remote radius server, that validates users against a Samba Active Directory server.

However I have runned into a bit of a problem.

The following section works for Android users using Strongswan VPN client:

connections
{
  rw-eap {
    local_addrs = SERVER_PUBLIC_IPV4, SERVER_PUBLIC_IPV6

    local {
      auth = pubkey
      certs = example-ecdsa.cer
      id = vpn.example.com
    }
    remote-android {
      auth = eap-radius
      id = *@example.com
    }
  }
}

Monitoring output from Freeradius reveals stuff like:

(5) Received Access-Request Id 135 from 192.168.200.1:47851 to 192.168.200.1:1812 length 193
(5)   User-Name = "[email protected]"
(5)   NAS-Port-Type = Virtual
(5)   Service-Type = Framed-User
(5)   NAS-Port = 4
(5)   NAS-Port-Id = "rw-eap"
(5)   NAS-IP-Address = SERVER_PUBLIC_IPV4
(5)   Called-Station-Id = "SERVER_PUBLIC_IPV4[4500]"
(5)   Calling-Station-Id = "CLIENT_IPV4[3988]"

And log from Strongswan gives:

06[IKE] IKE_SA rw-eap[6] established between SERVER_PUBLIC_IPV4[vpn.example.com]...CLIENT_IPV4[[email protected]]

However when trying to connect to the server from a Windows client it is pretty much dead in the water unless I use the following configuration in Strongswan:

connections
{
  rw-windows {
    local_addrs = SERVER_PUBLIC_IPV4, SERVER_PUBLIC_IPV6

    local {
      auth = pubkey
      certs = example-ecdsa.cer
      id = vpn.example.com
    }

    remote-windows {
      auth = eap-radius

      # Don't use *@example.com here - as windows does not pass username as id, 
      # so this config will not match in that case.
      id = %any
    }
  }
}

Using this configuration I can at least get Strongswan to initiate Radius authentication, but I dont get much further than this.

Output from Freeradius gives me stuff like:

(21) Received Access-Request Id 151 from 192.168.200.1:47851 to 192.168.200.1:1812 length 306
(21)   User-Name = "\300\250\000d"
(21)   NAS-Port-Type = Virtual
(21)   Service-Type = Framed-User
(21)   NAS-Port = 7
(21)   NAS-Port-Id = "rw-windows"
(21)   NAS-IP-Address = SERVER_PUBLIC_IPV4
(21)   Called-Station-Id = "SERVER_PUBLIC_IPV4[4500]"
(21)   Calling-Station-Id = "CLIENT_PUBLIC_IPV4[3989]"

And this result in the following entry in Strongswan log:

06[CFG] looking for peer configs matching SERVER_PUBLIC_IPV4[%any]...CLIENT_PUBLIC_IPV4[CLIENT_PRIVATE_IPV4]

This leads my a few questions like:

• First: Why does Windows VPN client not pass username as its ID like Strongswan do?

• Second: Why is the username passed from Strongswan to Freeradius "\300\250\000d"?

A little more debugging on Windows client:

The example above is generated when using EAP-TTLS on client side with MS-CHAP v2.

When using MS-CHAP instead Freeradius do get invoked with correct username, but when the request is proxied then the username / password authentication fails.

I guess the MS-CHAP login needs to be encapsulated or something since the encoding of the authentication request is not the same as when Android users connects?

The answer to both your questions is the same: Windows sends its IP address as IKE identity (which is then forwarded verbatim as User-Name attribute in the RADIUS message).

Instead, you should either configure your RADIUS server to do an EAP-Identity exchange (if you configured eap_start = yes in strongswan.conf), or let strongSwan do that by enabling the eap-identity plugin and configuring eap_id = %any in the remote... sections.