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.
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 )
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 (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
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.
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)
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.