IKEv2 VPN with RADIUS auth not working on Windows

We are looking to move from pfSense/opnSense in our offices; our current routers provide site-to-site tunnels as well as VPN connectivity to Mac/iPhone and WIndows machines using native clients, but we are having problems replicating the end-user VPN functionality on Mikrotik. We can get it working fine with Apple but not Windows.

The problem seems to be that Windows’ native client does not send a remote ID – and can send only the local IP address as the local ID – leaving the Mikrotik unable to determine what identity to use to handle the request. Apple sends the server address as the remote ID, which gives the MT something to match. On the pfSense, it appears any unmatched connections are automatically sent in to the “mobile client” configuration so it works as expected. I expect this is a very common configuration in any enterprise setting, so I’d be surprised if there’s no way to get it working.

Any assistance would be appreciated! We’re on 6.49.8 but are willing to get into v7 if there’s a known issue with the long-term release.

Configuration:

/ip ipsec policy group
add name=VPN
/ip ipsec profile
add dh-group=ecp384 enc-algorithm=aes-256 hash-algorithm=sha384 lifetime=8h name="VPN P1"
/ip ipsec peer
add exchange-mode=ike2 name=VPN passive=yes profile="VPN P1" send-initial-contact=no
/ip ipsec proposal
add auth-algorithms=sha512 enc-algorithms=aes-256-gcm lifetime=1h name="VPN P2" pfs-group=ecp521
/ip pool
add name=vpn_pool ranges=192.168.246.128/25
/ip ipsec mode-config
add address-pool=vpn_pool name=vpn static-dns=192.168.241.3 system-dns=no
/ip ipsec identity
add auth-method=eap-radius certificate=yyz.example.ca generate-policy=port-strict mode-config=vpn \
    my-id=fqdn:yyz.example.ca peer=VPN policy-template-group=VPN remote-id=ignore
/ip ipsec policy
set 0 group=VPN proposal="VPN P2"

iPhone log excerpt:

15:29:34	ipsec	IPSEC::: payload seen: ID_I (23 bytes)	
15:29:34	ipsec	IPSEC::: payload seen: NOTIFY (8 bytes)	
15:29:34	ipsec	IPSEC::: payload seen: ID_R (22 bytes)	
15:29:34	ipsec	IPSEC::: payload seen: CONFIG (40 bytes)	
15:29:34	ipsec	IPSEC::: payload seen: NOTIFY (8 bytes)	
15:29:34	ipsec	IPSEC::: payload seen: NOTIFY (8 bytes)	
15:29:34	ipsec	IPSEC::: payload seen: SA (36 bytes)	
15:29:34	ipsec	IPSEC::: payload seen: TS_I (64 bytes)	
15:29:34	ipsec	IPSEC::: payload seen: TS_R (64 bytes)	
15:29:34	ipsec	IPSEC::: payload seen: NOTIFY (8 bytes)	
15:29:34	ipsec	IPSEC::: payload seen: NOTIFY (8 bytes)	
15:29:34	ipsec	IPSEC::: processing payloads: NOTIFY	
15:29:34	ipsec	IPSEC::: notify: INITIAL_CONTACT	
15:29:34	ipsec	IPSEC::: notify: ESP_TFC_PADDING_NOT_SUPPORTED	
15:29:34	ipsec	IPSEC::: notify: NON_FIRST_FRAGMENTS_ALSO	
15:29:34	ipsec	IPSEC::: notify: MOBIKE_SUPPORTED	
15:29:34	ipsec	IPSEC::: notify: EAP_ONLY_AUTHENTICATION	
15:29:34	ipsec	IPSEC::: ike auth: respond	
15:29:34	ipsec	IPSEC::: processing payload: ID_I	
15:29:34	ipsec	IPSEC::: ID_I (ADDR4): 172.16.23.58	
15:29:34	ipsec	IPSEC::: processing payload: ID_R	
15:29:34	ipsec	IPSEC::: ID_R (FQDN): yyz.example.ca	
15:29:34	ipsec	IPSEC::: processing payload: AUTH (not found)	
15:29:34	ipsec	IPSEC::: requested server id: yyz.example.ca

Windows log excerpt:

15:29:30	ipsec	IPSEC::: payload seen: ID_I (12 bytes)	
15:29:30	ipsec	IPSEC::: payload seen: CERTREQ (1005 bytes)	
15:29:30	ipsec	IPSEC::: payload seen: NOTIFY (8 bytes)	
15:29:30	ipsec	IPSEC::: payload seen: CONFIG (36 bytes)	
15:29:30	ipsec	IPSEC::: payload seen: SA (36 bytes)	
15:29:30	ipsec	IPSEC::: payload seen: TS_I (64 bytes)	
15:29:30	ipsec	IPSEC::: payload seen: TS_R (64 bytes)	
15:29:30	ipsec	IPSEC::: processing payloads: NOTIFY	
15:29:30	ipsec	IPSEC::: notify: MOBIKE_SUPPORTED	
15:29:30	ipsec	IPSEC::: ike auth: respond	
15:29:30	ipsec	IPSEC::: processing payload: ID_I	
15:29:30	ipsec	IPSEC::: ID_I (ADDR4): 10.100.10.24	
15:29:30	ipsec	IPSEC::: processing payload: ID_R (not found)	
15:29:30	ipsec	IPSEC::: processing payload: AUTH (not found)	
15:29:30	ipsec, error	identity not found for peer: ADDR4: 10.100.10.24	
15:29:30	ipsec, error	IPSEC::: identity not found for peer: ADDR4: 10.100.10.24	
15:29:30	ipsec	IPSEC::: reply notify: AUTHENTICATION_FAILED

Could you share the pfSense config that worked?

Not very easily, and it’s not really relevant here.

Hi,
I don’t know what RADIUS you are using but it eap-radius works with NPS, look at this presentation (second part as BONUS) - https://mbum.pl/archive/mbum5/Profilowanie%20Sesji%20VPN.pdf (sorry, but it’s only available in Polish)

Thanks, my Mikrotik configuration looks same as that one except for stronger algorithms, too bad there’s nothing in there about the client configuration. (Which RADIUS server doesn’t matter right now, since it doesn’t even get through phase 1 negotiation, also I know the RADIUS is fine for other clients.)

Yep, I forgot that :/, the default IKEv2 settings in Windows 10 try to use ciphers as in the screenshots below (although the MS documentation only shows the proposal #1 )

Phase 1
Win10 IKEv2 Phase1 default ciphers.PNG
Phase 2
Win10 IKEv2 Phase2 default ciphers.PNG
If you want to change the settings, you have to do it through PowerShell commands (https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/vpn/how-to-configure-diffie-hellman-protocol-over-ikev2-vpn-connections#ikev2-vpn-client)

I assume that their clients were properly provisioned. As I understood current RouterOS config is merely a migration of their pfSense. It’s just that behavior of pfSense for matching identities is different from RouterOS.

I wish I knew what (and how) Radius attributes RouterOS uses for the IPsec subsystem, but I don’t. I filed a request back in June (SUP-118267) requesting an improvement but it’s still open . I encourage you to do the same on help.mikrotik.com

Perhaps, if you enable debug logging for radius it will give you some insight regarding what attributes are being queried? Might lead it to a solution.

To my knowledge MikroTik doesn’t have any dedicated Radius VSA (Vendor-Specific-Attributes) for IPsec settings , which is very lame :confused: (their RADIUS dictionary is not very extensive). A VSA that allows you to choose a dedicated “Mode-configs” profile would be very helpful (like Mikrotik-Group for PPP profiles) . Therefore, in this presentation only standard radius attributes are used when we want to inject a dedicated IP pool for a specific user group of IPsec connections

This is the Windows config:

Add-VpnConnection -Name "Toronto VPN" `
    -ServerAddress "yyz.example.ca" `
    –TunnelType IKEv2 `
    -AuthenticationMethod EAP `
    -EncryptionLevel Required `
    -RememberCredential

Set-VpnConnectionIPsecConfiguration -ConnectionName "Toronto VPN" `
    -EncryptionMethod AES256 `
    -IntegrityCheckMethod SHA384 `
    -DHGroup ECP384 `
    -AuthenticationTransformConstants GCMAES256 `
    -CipherTransformConstants GCMAES256 `
    -PfsGroup ECP384 `
    -Force

Which, as you say, is the same config that was working fine with pfSense, aside from AES-GCM encryption in phase 1, which I had to downgrade for the MT.

The MT can’t even select the right identity so the question of authentication or anything to do with RADIUS is premature. And, as I said, it works fine for non-Windows clients.

What does Mikrotik’s Technical support say?

Is running a container with strongSwan or alike solution feasible?

I have not contacted them yet; I had hoped this was a fairly simple setup and I was overlooking something obvious!

You may have found a bug in a particular cipher suite (radius debug on MT shows which proposal # you get from the client). Additionally, you should avoid sha384 if you want to achieve hardware acceleration for IPsec - https://help.mikrotik.com/docs/display/ROS/IPsec#IPsec-Hardwareacceleration (the indicator H / Hardware AEAD next to the IPsec SA data in the ‘Installed SAs’ tab)

IMO their IPsec is primarily suited for site-to-site RouterOS <-> RouterOS connectivity, not roadwarriors.

Yeah we have site-to-site tunnels set up between this unit and other Mikrotiks, pfSense, opnSense, and Cisco ASA boxes no problem. But if we have to start thinking about containers of other VPN servers, we'll likely just stick with opnSense.

FWIW I migrated my IPsec to a container (on a dedicated machine, not RouterOS) with strongSwan and very happy. Overall capabilities are just on a whole different level.

Again, I do recommend contacting their technical support and filing a feature request if necessary. IPsec and IPsec radius does need improvement.