IPSec identity problem

RouterOS General
1

Good day!

I have the router at central office (CO) and some routers at remote offices (TM-2, TM-3), which are IPSec peers authenticated with secret on CO. On security reason I want to use separate secret for each peer. I try achieve this using multiple ipsec identities. But it seems that only first of not disabled identities is used by OS. So peer TM-2 can be authenticated, and peer TM-3 can not. For peer TM-3 I see message in log “14:06:49 ipsec,error identity not found for server:TM-CO peer: KEYID: TM-3”. When I disable identity for TM-2, TM-3 succeeds in authentication. So playing with disable/enable I even can reach situation when both of peers authenticated and IPSec tunnels installed.

Is this a bug, or I am wrong?

Config for CO follows:

# RouterOS 6.45.7

/ip ipsec mode-config add name=MODE-CFG-TM system-dns=no

/ip ipsec policy group add name=GROUP-TM

/ip ipsec profile add dh-group=modp1024 dpd-interval=1m enc-algorithm=aes-256 name=CO-PROFILE

/ip ipsec peer add exchange-mode=ike2 name=TM-PEER passive=yes profile=CO-PROFILE send-initial-contact=no

/ip ipsec proposal add enc-algorithms=aes-256-cbc lifetime=1d name=CO-PROPOSAL

/ip ipsec identity
add generate-policy=port-strict mode-config=MODE-CFG-TM peer=TM-PEER policy-template-group=GROUP-TM remote-id=key-id:TM-2 secret=XXXXXX
add generate-policy=port-strict mode-config=MODE-CFG-TM peer=TM-PEER policy-template-group=GROUP-TM remote-id=key-id:TM-3 secret=YYYYYY

/ip ipsec policy add dst-address=0.0.0.0/0 group=GROUP-TM proposal=CO-PROPOSAL src-address=0.0.0.0/0 template=yes
2

I am using the very same method on the same 6.45.7, the two remote initiators are even coming from behind the same remote IP, and it works for me. However, there is a difference, I’m using ID type fqdn, not key-id. So maybe try that way to check whether it is related and to maybe make your life easier.

3

Update: It doesn’t seem to be the reason. I’ve switched the ID type from fqdn to key-id at both my initiators, disabled and re-enabled the responder peer, and both initiators came happily up again.

So I have a dark suspicion - make your initiators’ IDs differ in more than the last character and see what happens when you keep both identity rows enabled and let the initiators re-establish the connections.

4

Yes, I tried “remote-id=fqdn:” and it didn’t work too.
Now I’ve tried to change names to AAAA and BBBB - no success :frowning:
Now I’ve tried to change names to lowercase - no success :frowning:

Here is my client’s config. Does it look similar to yours one?

# RouterOS 6.45.7
/ip ipsec profile add dh-group=modp1024 dpd-interval=1m enc-algorithm=aes-256 name=CO-PROFILE
/ip ipsec peer add address=1.1.1.1/32 exchange-mode=ike2 name=TM-CO profile=CO-PROFILE
/ip ipsec proposal add enc-algorithms=aes-256-cbc lifetime=1d name=CO-PROPOSAL

/ip ipsec identity
add my-id=key-id:TM-2 peer=TM-CO remote-id=key-id:TM-CO secret=XXXXXX

/ip ipsec policy add comment=data-main dst-address=1.1.1.1/32 level=unique peer=TM-CO proposal=CO-PROPOSAL sa-dst-address=1.1.1.1 sa-src-address=0.0.0.0 src-address=198.18.0.2/32 tunnel=yes
5

It seems I found my mistake.

I’ve omitted parameter “my-id=key-id:TM-CO” in identity descriptions.
When it was added everything went as it should.

So, thank you, Sindy. You made me sure the problem is mine :slight_smile:

6

Funny enough, I don’t set my-id in identity rows representing the individual initiators at responder side and it works anyway; however, I also do not set remote-id at initiator side.

7

Oops, I haven’t noticed at first reading that you’ve manually set remote-id at initiators to TM-CO; it is then even more surprising that it worked at all, given that the initiators should have terminated the connection once they’ve seen an unexpected ID of the responder (as you haven’t specified any my-id at the responder, it probably wasn’t matching the remote-id value set at the initiators, I don’t remember what the IPsec stack automatically chooses as its local ID when none is specified “manually”).

So for me, the actual bug is that the connections did establish by means of your rain spell.

8

I think by default peer claims itself as it’s hostname.
There is such string in config:

/system identity set name=TM-CO