0

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 = "user@example.com"
(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[user@example.com]

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?

1 Answers1

1

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.

ecdsa
  • 3,800
  • 12
  • 26