IKE2: can't agree on IKE proposal - RouterOS choosing wrong proposal!

RouterOS General
1

Hi

/ip/ipsec/profile
name="roadwarrior" hash-algorithm=sha384 prf-algorithm=sha384 enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d proposal-check=strict nat-traversal=no dpd-interval=1m 
     dpd-maximum-failures=5
name="site1" hash-algorithm=sha384 enc-algorithm=aes-256 dh-group=modp1536 lifetime=8h proposal-check=strict nat-traversal=yes dpd-interval=1m dpd-maximum-failures=5

/ip/ipsec/peer
name="roadwarrior" passive=yes profile=roadwarrior exchange-mode=ike2 send-initial-contact=yes
name="site1" local-address=1.2.3.4 passive=yes profile=site1 exchange-mode=ike2 send-initial-contact=yes

When a roadwarrior tries to connect, this is giving me the error

can’t agree on IKE proposal, my config:
enc: aes256-cbc
auth: sha384
dh: modp1536
prf: hmac-sha384

So RouterOS is choosing the proposal of site1, instead of roadwarrior, although site1 has a remote id matcher configured. Both tunnels are IKE2.
If I disable site1, connection for the road warrior works immediately.

Why doesn’t Router OS choose the correct proposal? Can’t I have multiple peers without remote peer address with RouterOS? I have been doing this successfully for like 12 years with other vendors…

Thanks for any advice.

2

I don’t see it in your config. You need to have an /ip/ipsec/identity configuration.

3

I have identities, sorry for not posting them earlier.

/ip/ipsec/identity
peer=IKE2-Dialup auth-method=eap-radius mode-config=roadwarrior certificate=certificate-request.cer_0 generate-policy=port-strict policy-template-group=roadwarrior 
peer=IKE2-Dialup auth-method=pre-shared-key remote-id=fqdn:site1 secret="mysecret" generate-policy=port-strict policy-template-group=site1

I now changed the rest of the config to:

/ip/ipsec/profile
name="IKE2-Dialup" hash-algorithm=sha384 enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d proposal-check=strict nat-traversal=yes dpd-interval=1m dpd-maximum-failures=5

/ip/ipsec/peer
name="IKE2-Dialup" local-address=1.2.3.4 passive=yes profile=IKE2-Dialup exchange-mode=ike2 send-initial-contact=yes

So this is working now, I have multiple identities who are using the same peer and profile. I think this is how Mikrotik intends it to be, although it is sad that I can’t have different settings for my various dialup clients: Luckily, I was able to adapt them to match but in a different case that might not have been possible.

4

It is always difficult to follow other people’s fragmented config and claimed problems, but on my router it works OK using “ip ipsec policy group”, different settings per group, and linking of the identity to the group.
It looks like you already have that, however.
The order of the rules may make some difference.

5

Yes, I understand that, sorry. I thought too much of the config could be confusing since it is quite extensive.
I think that should be all, regarding IPSEC. Order of which rules do you mean? Of course, I have firewall filter rules in place but they simply allow udp 500, 4500 and protocol 50 ipsec-esp.
Phase 2 settings can be different but phase 1 seem to have to be identical…?

/ip ipsec mode-config
add address-pool=roadwarrior name=roadwarrior split-dns=192.168.25.1 static-dns=192.168.25.1 system-dns=no
/ip ipsec policy group
add name=roadwarrior
add name=site1
/ip ipsec profile
add dh-group=modp2048 dpd-interval=1m enc-algorithm=aes-256 hash-algorithm=sha384 name=IKE2-Dialup proposal-check=strict
/ip ipsec peer
add exchange-mode=ike2 local-address=1.2.3.4 name=IKE2-Dialup passive=yes profile=IKE2-Dialup
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=roadwarrior pfs-group=modp2048
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=site1 pfs-group=modp1536
/ip ipsec identity
add auth-method=eap-radius certificate=certificate-request.cer_0 generate-policy=port-strict mode-config=roadwarrior peer=IKE2-Dialup policy-template-group=roadwarrior
add generate-policy=port-strict peer=IKE2-Dialup policy-template-group=site1 remote-id=fqdn:site1
/ip ipsec policy
add dst-address=10.20.30.0/24 group=roadwarrior proposal=roadwarrior src-address=0.0.0.0/0 template=yes
add dst-address=192.168.3.0/24 group=site1 proposal=site1 src-address=0.0.0.0/0 template=yes
/ip ipsec settings
set xauth-use-radius=yes
6

Yes, phase 1 at least has to be compatible for all. There is a chicken-egg problem because the server cannot know the identity of the client before starting phase 1 (especially when you cannot tie that to remote address).
In general I would suggest that, however cute it may be to have all kinds of very modern algorithms and CIA-grade encryption, stay closer to the default.

7

ok thanks for confirming that.

I don’t know how Fortigate with its FortiOS is doing it but there it was working perfectly, having different phase 1 settings in this scenario.
anyways, it is what it is and I’m happy it is working now at least the way it is.