I am trying to setup an IPsec server that can accept different parameters, because I have found that defaults used by RouterOS are ancient and no longer supported in some more modern software.
E.g. the default phase1 profile uses SHA1 hashing and 3des or aes-128 encryption, the default phase2 proposal has DH modp1024.
Newer software uses at least SHA256 and no longer implements modp1024 as "too insecure".

Of course in RouterOS you can make all kinds of settings, but now I face the problem that some users which use RouterOS already
are using ancient defaults, and new users who want to use e.g. "libreswan" cannot connect using those parameters.

So at first I thought "let's allow some more parameter values so we can deprecate the old ones later".
First problem I encounter is that a phase 1 profile can have only a single hash algorithm (it can have multiple encryption and DH settings).
I tried making two profiles, one with SHA1 and one with SHA256, and then have 2 peers (IKE2) for the ::/0 remote address with these two profiles, but the latter is rejected by an error that the second one is "unreachable". And a single peer cannot have 2 profiles.
Is there no other trick to have two options for the hash algorithm? Other software can have phase1 profiles with different hash/encrypt combos and it is possible to have e.g. aes-sha1 and aes-sha256 in the same profile.
Can that not be done in RouterOS and if so, why?

If you're looking for sympathy, I've run into this. Mainly EoIP's automatic ipsec-secret= since that uses defaults, and in older routers these also used default IPSec configurations.

AFAIK, you have a "static" identity, you can create multiple profiles to avoid the default proposal. But if they are dynamically created identity, there is only one default & suspect that your problem. The dynamic ones will use "default" - and there is only one – so only way is a configured/static identity that explicitly sets a profile/etc. But it's a manual affair, I converted EoIP's automatic ones into static ones, which let me change profile. But this doesn't work unless you know all you know all the peers apriori.

Or at least that the conclusion I came. Possible someone else knows some trick here.

Yes, I know that issue with EoIP (and also GRE and IPIP) with automatic IPsec configuration....
But in this case I am running an IKE2 server using identities for the different clients, and they all come in on the same "peer".
(see the topic "IPsec tunnels without known remote IP")
While that in itself works OK, now there is a similar issue.
Also I found that while I managed to create a server config that works fine with MikroTik routers on the other side, I still have issues with connecting from other software
E.g. from libreswan the initial connection is OK but it fails once the key lifetime is over. Either it shuts down (when rekey=no is configured) and re-connects only when there is new traffic from the client side, or it fails to rekey with the error "no proposal chosen".

So still a lot of work to do...

If you're asking an IPSec question... something must be wrong... I'm here for moral support.

I just know the one "one proposal problem" well. Unlike routing stuff, there isn't a lot of places to control the proposal (i.e. nothing like BGP filters, firewall mangle for IPSec)

Yes. I am hoping for one of the other IPsec experts to chime in, after all that worked well for the other question I recently posted.

Well, Amm0, in that case, I'm also here for moral support!

But considering pe1chl's specific need and the limited documentation on this, I think it'll be pretty tough to figure out how it works behind the scenes. So, MT is probably the only one who can say if it's doable or not (if they even bother to respond at all, that is).

Any particular reason you don’t want to run a better ipsec responder inside a container? After all ipsec is done in the kernel and you shouldn’t suffer too much performance drop, although my use cases are very modest.

Well, I crafted this solution as a replacement for an older implementation that was in a plain Debian Linux VM.
The goal was to use RouterOS to get an installation that would be easier to maintain.
Unfortunately until now that isn't the case, but maybe when I have everything finished it is...

I don't have an answer for you, but I'm curious how often you encounter this? I've built several hundred point-to-point IPSec VPN connections over the years, and 99% of them have been to statically defined peers where it's perfectly reasonable (and desirable) to nail down all of the parameters (well, except lifetime... that's pretty much always negotiated).

With that said, other vendors (like Cisco, for example) definitely do support multiple phase 1 and phase 2 policies to allow for the best chance of connection success, especially during migration to newer encryption protocols and such, so I know it's not impossible.

It isn't an issue for statically defined peers. But those require fixed IP addresses.
In this case I want to setup a service without having to worry about the IP addresses of the clients.
Those regularly change, and it causes a maintenance nightmare. Also, most IPsec implementations do not backoff when the connection fails, so when something goes awry you get thousands of messages in your logs.

When you want to define a peer that is "for any incoming IP address" (address ::/0) this issue arises.
I also remember it from before when I wanted to setup an L2TP/IPsec service that would be usable for Windows and Android.
Android had only support for old hash/encrypt protocols. And it even could not handle multiple settings for some parameters.
It worked with the default MikroTik settings, but once you add more secure options it would fail.
But other implemenations would warn about insecure protocols when connecting to the same configuration.

Now Android has abandoned L2TP/IPsec claiming it is insecure (yeah, in THEIR implementation!), and have changed to IKEv2.
But Windows does not support IKEv2, only L2TP/IPsec.

Fortunately, that is something that can co-exist. But still it would be nice when multiple parameter settings could co-exist, indeed as you write other routers and IPsec implementations e.g. on Linux do support it, so it isn't a protocol restriction.

But Windows does not support IKEv2, only L2TP/IPsec.

That is not true, Windows supports IKEv2.

In my use case I use ikev2 ipsec as back to home in my soho as it requires no client software. And I wanted to support all common platforms out of the box. I went with strongswan as the responder. It supports ikev2 much better than roueros’s hodgepodge that relies on mode-config.

But Windows does not support IKEv2, only L2TP/IPsec.

That is not true, Windows supports IKEv2.

In my use case I use ikev2 ipsec as back to home in my soho as it requires no client software. And I wanted to support all common platforms out of the box. I went with strongswan as the responder. It supports ikev2 much better than roueros’s hodgepodge that relies on mode-config.

It be nice if docs had some table of "supported" OS native client that work with RouterOS VPN. I cannot keep up on exact what OS supports what VPN without a client. I use L2TP for these cases, since I too was under the assumption that Windows did not support RouterOS IKEv2.

But I might be relaying on old info... And I'm not sure what the "modern" best-practice for native OS VPNs with RouterOS.

Indeed I should have been more specific, it was about "Windows 10 without additional client software".
Of course there is software to use IKEv2 with Windows, but when you just go to networking and choose "add a connection to my work or school" (or whatever it is called today) then IKEv2 is not an option, but L2TP/IPsec is.

Windows 10's builtin IKEv2 supports EAP-MSCHAPv2: https://docs.strongswan.org/docs/latest ... pConf.html

Could it be an administrative / licensing restriction in your case?

I tried again today on Windows 11 and now I found (and remembered) what was the problem:
When you configure IKEv2 with username/password in Windows VPN the identity of the connecting router is not set to the username, but to the address of the system.
Thus it is not possible to match the identity when the user is connecting from various addresses.
When setting up a VPN in Android it works OK.