Hi,
seems to me that current RouterOS versions are ignoring the IPsec phase2 (Proposals) PFS-Group setting.
Mixing this setting on client/server-side with different values (i.e. modp-1024 and none) has no actual effect on the connection. I guess the weakest setting wins.
Do you have a hint on how to debug the actual chosen phase2 PFS-Group on active SAs?
I think you see the mismatch only if session key is about to expire and rekeying fails. So did you test for more than just session startup?
L2TP IPsec tunnels configured with mismatching PFS-Group settings in phase2 are running seamlessly without noticeable interruptions.
At least combinations with PFS-Group none and another selection on the remote device.
So I guess that configured PFS-Group settings in phase2 are ignored if the remote end does not support it which is not the expected behavior.
In my experience with traditional IPSec site-to-site tunnels, when PFS group doesn’t match on both peers, the tunnel can be brought up in only one direction. The reverse direction will always fail. I don’t recall which condition was which though. I imagine the side with better PFS would downgrade to match the weaker PFS of the other side, but I don’t know that.
Now, with L2TP clients, it is always only 1 direction. So you might be getting lucky and the server side is configured in such a way to allow the clients to connect. Since the server never initiates the connection, you won’t see the one-way failure.
But apparently the IPsec connection comes up for both combinations: i.e. server-side PFS-group 1024 and client-side none or vice versa.
So maybe this setting is ignored at all at IPsec phase 2.