IPSec Identity: a pseudo-address as the client’s identifier

RouterOS General
1

Greetings everyone!

I’ve encountered an issue that, in my opinion, falls within MikroTik’s area of responsibility.

So, we have an RB3011 running firmware 7.20.6 and a ZTE G5B modem purchased from the local operator KCELL, operating behind Carrier-Grade NAT.

This ZTE G5B is not the best device for my task; nevertheless, it is a 5G modem with IPSec support for $30. The configuration options on this modem are minimal:

Service IP: 203.0.113.250
Preshared password: jG7yW8iV3cZ7uO4
Dest. IP Address: 192.168.2.0
Dest. Subnet Mask: 24
Enable advanced configuration: true
IKE Protocol: IKE V2
First stage encryption algorithm: aes
First stage authentication algorithm: sha1
Phase I DH group: 2048 bit
Second stage encryption algorithm: aes
Second stage authentication algorithm: sha1
Auto Connect: false

These are all the available settings!

The local network interface of this modem has the address: 192.168.0.1/24

After configuring it and reviewing the exchange log, we find the following entries:

Dec/05/2025 18:46:30 ipsec processing payload: ID_I
Dec/05/2025 18:46:30 ipsec ID_I (ADDR4): 192.168.0.0
Dec/05/2025 18:46:30 ipsec processing payload: ID_R (not found)
Dec/05/2025 18:46:30 ipsec processing payload: AUTH
Dec/05/2025 18:46:30 ipsec,error identity not found for peer: ADDR4: 192.168.0.0
Dec/05/2025 18:46:30 ipsec reply notify: AUTHENTICATION_FAILED

This is despite the fact that the Identity looks as follows:

/ip/ipsec/identity> export
add generate-policy=port-strict my-id=address:203.0.113.250 peer=ZTE_G5B policy-template-group=ZTE_G5B remote-id=address:192.168.0.0

Why does RouterOS ignore this Identity and refuse the device’s connection?
Does it strictly verify the actual remote IP address against the one specified in the remote-id?

2

I don’t expect 192.168.0.0 to be a valid ID since it’s a whole subnet and a private address on top of that. Why don’t you just leave remote-id to auto and let the router figure out the best matching one?

3

Is the RB3011 using the public IP address or is it behind a NAT gateway.
If behind a NAT it likely won't work.

They no longer like allowing PSK where the Server is behind a NAT and doesn't have the destination IP address the client is connecting too. (They figure this out during NAT T negotiation)

You can double NAT to the RB3011, so it looks like it is coming into the correct IP address and should work. You can do this directly on the RB3011, by giving it the external IP (eg. on Lo) and forwarding the incoming ipsec traffic to itself with a d-nat rule. (May need to forward ESP as well)

Which probably highlights even more why PSK shouldn't be used...