Community discussions

MikroTik App
 
User avatar
Znevna
Forum Guru
Forum Guru
Topic Author
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

IKEv2 between MikroTiks, sides switching, initiator <> responder

Mon Aug 03, 2020 10:42 am

Hello!
As per the topic title, I'm running a few IKEv2 tunnels on a RB4011.
A bunch of Windows clients connect to it, three of my other MikroTiks for now (hAP ac2) and one FreeBSD based router I think (support for some software uses it) which stacks up PH2 count from time to time, but that's not an issue, for now.
All the Tiks are running v6.46.6.
Between the Tiks I have only a simple policy between two IPs over which I run an IPIP Tunnel.
Now, from time to time, when I check the Active Peers, I see one, two, or all three of those Tiks with the sides reversed. (all the clients as initiators).
Checked on the hAP ac2s and they also say "responder".
Everything works though, the IPIP Tunnels never go down, but should I be worried about this?
The RB4011 has the peer configured with passive=yes & send-initial-contact=no.
The hAP ac2s have the peer configured with passive=no & send-initial-contact=yes.
 

/ip ipsec active-peers> print detail
Flags: R - responder, N - natt-peer 
 0 RN id="win-22" side=responder dynamic-address=172.28.248.22 uptime=2w4d1h5m28s last-seen=1m3s ph2-total=1
 1 RN id="win-23" side=responder dynamic-address=172.28.248.23 uptime=2w3d1h7m35s last-seen=1m13s ph2-total=1
 2 RN id="win-21" side=responder dynamic-address=172.28.248.21 uptime=1w3d10s last-seen=1m24s ph2-total=1
 3 RN id="win-25" side=responder dynamic-address=172.28.248.25 uptime=1w2d23h1m6s last-seen=20s
 4    id="ac2-69" side=initiator dynamic-address=172.28.252.69 uptime=6d17h18m25s last-seen=1m5s ph2-total=1
 5 RN id="win-12" side=responder dynamic-address=172.28.248.12 uptime=5d16h21m30s last-seen=1m17s
 6 RN id="win-11" side=responder dynamic-address=172.28.248.11 uptime=3d1h41m20s last-seen=1m13s ph2-total=1
 7    id="ac2-134" side=initiator dynamic-address=172.28.252.134 uptime=3d10m22s last-seen=41s ph2-total=1
 8  N id="ac2-135" side=initiator dynamic-address=172.28.252.135 uptime=2d23h52m30s last-seen=1m11s ph2-total=1
 9 R  id="bsd" side=responder uptime=11h42m24s last-seen=0s ph2-total=2
10 RN id="win-42" side=responder dynamic-address=172.28.248.42 uptime=2h18m38s last-seen=33s ph2-total=1
11 RN id="win-13" side=responder dynamic-address=172.28.248.13 uptime=2h13s last-seen=22s
12 RN id="win-14" side=responder dynamic-address=172.28.248.14 uptime=45m11s last-seen=1m9s ph2-total=1
13 RN id="win-47" side=responder dynamic-address=172.28.248.47 uptime=25m30s last-seen=1m29s ph2-total=1
14 RN id="win-44" side=responder dynamic-address=172.28.248.44 uptime=11m3s last-seen=1m3s ph2-total=1
And while writing this, peer 8 just switched sides again.

8 RN id="ac2-135" side=responder dynamic-address=172.28.252.135 uptime=3d4m20s last-seen=54s ph2-total=1

Thanks.
Last edited by Znevna on Tue Aug 04, 2020 3:11 pm, edited 1 time in total.
 
User avatar
tomaskir
Trainer
Trainer
Posts: 1162
Joined: Sat Sep 24, 2011 2:32 pm
Location: Slovakia

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Mon Aug 03, 2020 9:20 pm

Likely best to contact support in this case.

The side with "passive=yes & send-initial-contact=no" should never be the initiator.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Mon Aug 03, 2020 9:50 pm

send-initial-contact=yes is not an instruction to act as initiator; it actually means "replace any already existing connection from my IP address, irrespective of port, by this new one", so it is quite dangerous in some scenarios (multiple initiators coming to the responded from behind the same NAT address). But you're not the only one to get trapped by the name, I had the same wrong understanding for months, and so had others.

Also, passive=no is not an instruction to act as initiator only; it enables the initiator role but doesn't disable the responder one.

So the only actual issue (but a serious one!) is why the 4011 configured with passive=yes ever acts as an initiator.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Tue Aug 04, 2020 12:33 pm

I have the same behavior of changing from initator to responder but then with a VPN provider. Itis only happening with Pure-VPN and not with other providers.

It is happening between 15 and 35 minutes after connect. The only thing that is different is that the Source Address is public instead of private. Activating NAT-T makes no difference.

I use a script to remove connections with responder status.

Only one of them use a private Source Address IP [10.5.45.X]:
PureVPN.JPG
New connect with NAT-T and my own public address is the Local Address:
 Acitve Peers, Remote Address
10  N pointtoserver.com    established        54s                     1 2.58.44.x           (L2)                                                                         
11  N pointtoserver.com    established        54s                     1 188.72.98.x       (R1)                                                                            
12  N pointtoserver.com    established        54s                     1 37.230.131.x     (R2)                                                                             
13  N pointtoserver.com    established        54s                     1 188.72.82.x       (R3)                                                                            
14  N pointtoserver.com    established        37s                     1 178.170.137.4   (L1)

Policies, Source Address:
15   DA  Pure-VPN-L2 yes    10.5.45.x/32                
16   DA  Pure-VPN-R1 yes    188.72.98.x/32               
17   DA  Pure-VPN-R2 yes    37.230.131.x/32              
18   DA  Pure-VPN-R3 yes    188.72.82.x/32               
19   DA  Pure-VPN-L1 yes    178.170.137.x/32    
Update:

I don't think that the public address is the problem because the one having the private address switched to responder:
10 RN pointtoserver.com    established        22m2s                   1 2.58.44.x                                                                                                    
11  N pointtoserver.com    established        22m2s                   1 188.72.98.x                                                                                                    
12  N pointtoserver.com    established        22m2s                   1 37.230.131.x                                                                                                   
13  N pointtoserver.com    established        22m2s                   1 188.72.82.x                                                                                                   
14  N pointtoserver.com    established        21m45s                  1 178.170.137.x
Update 2:
An other three switched to responder around 35 minutes and the last switched around 40 minutes.
You do not have the required permissions to view the files attached to this post.
 
User avatar
Znevna
Forum Guru
Forum Guru
Topic Author
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Tue Aug 04, 2020 2:25 pm

Safe to say that Pure-VPN is using MikroTiks ?
I've set a logging rule for "topics=ipsec,!packet" on one of those hAP ac2 client that sits mostly idle, maybe I can catch a switch in the logs (from initiator to responder) hoping that these may provide anything useful regarding this.
I don't know how can I catch something on the RB4011 since all the other peers are pretty active generating a lot of noise in the logs.
I think it has something to do with Phase2 though, since one of those hAP ac2s sits behind a 4G modem with no public IP on WAN and no ports forwarded to it, so my RB4011 can't be the initiator side in any way, and yet.. there it is, after some time (peer 8 from my initial post).
But as I've said, it doesn't bother me that much since the tunnels don't go down or something, it's just a weird "issue".
 
User avatar
Znevna
Forum Guru
Forum Guru
Topic Author
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Mon Aug 17, 2020 8:45 pm

Ok, so I'm pretty sure that during this (captured from the client / initiator) the sides switched (initiator -> responder).
I'll also try to capture a switch back to initiator. I don't know if it provides anything useful.
20:20:54 ipsec,debug ===== received 572 bytes from SERVER.IP[4500] to CLIENT.IP[4500] 
20:20:54 ipsec -> ike2 request, exchange: CREATE_CHILD_SA:652 SERVER.IP[4500] cd6c9547697d300f:62848846dee423c0 
20:20:54 ipsec payload seen: ENC (544 bytes) 
20:20:54 ipsec processing payload: ENC 
20:20:54 ipsec,debug => iv (size 0x10) 
20:20:54 ipsec,debug c0fa451f 73228ef1 f14c675e fb472b10 
20:20:54 ipsec,debug => plain payload (trimmed) (first 0x100 of 0x15c) 
[...]
20:20:54 ipsec,debug decrypted 
20:20:54 ipsec payload seen: SA (56 bytes) 
20:20:54 ipsec payload seen: KE (264 bytes) 
20:20:54 ipsec payload seen: NONCE (28 bytes) 
20:20:54 ipsec create child: respond 
20:20:54 ipsec processing payloads: NOTIFY (none found) 
20:20:54 ipsec IKE SA rekey 
20:20:54 ipsec processing payload: SA 
20:20:54 ipsec IKE Protocol: IKE 
20:20:54 ipsec  proposal #1 
20:20:54 ipsec   enc: aes256-cbc 
20:20:54 ipsec   prf: hmac-sha1 
20:20:54 ipsec   auth: sha1 
20:20:54 ipsec   dh: modp2048 
20:20:54 ipsec matched proposal: 
20:20:54 ipsec  proposal #1 
20:20:54 ipsec   enc: aes256-cbc 
20:20:54 ipsec   prf: hmac-sha1 
20:20:54 ipsec   auth: sha1 
20:20:54 ipsec   dh: modp2048 
20:20:54 ipsec processing payload: KE 
20:20:54 ipsec processing payload: NONCE 
20:20:55 ipsec,debug => shared secret (size 0x100) 
[...]
20:20:55 ipsec adding payload: SA 
20:20:55 ipsec,debug => (size 0x38) 
[...]
20:20:55 ipsec adding payload: KE 
20:20:55 ipsec,debug => (first 0x100 of 0x108) 
[...]
20:20:55 ipsec adding payload: NONCE 
20:20:55 ipsec,debug => (size 0x1c) 
20:20:55 ipsec,debug 0000001c 429690c6 8fac4d1b 62886a6c 550bbbfb 975d3caa a04d081d 
20:20:55 ipsec <- ike2 reply, exchange: CREATE_CHILD_SA:652 SERVER.IP[4500] cd6c9547697d300f:62848846dee423c0 
20:20:55 ipsec,debug ===== sending 604 bytes from CLIENT.IP[4500] to SERVER.IP[4500] 
20:20:55 ipsec,debug 1 times of 608 bytes message will be sent to SERVER.IP[4500] 
20:20:55 ipsec,debug => skeyseed (size 0x14) 
20:20:55 ipsec,debug 44c97490 7ade50cd 39b2eb9c c3e0ef70 352dc6a8 
20:20:55 ipsec,debug => keymat (size 0x14) 
20:20:55 ipsec,debug e5521a7a b9e60133 47ea344e eb23a4a0 7898098b 
20:20:55 ipsec,debug => SK_ai (size 0x14) 
20:20:55 ipsec,debug 4b25f7a9 7bf251ee 51550e5b 4754feee 883e1314 
20:20:55 ipsec,debug => SK_ar (size 0x14) 
20:20:55 ipsec,debug 9cf2258b cbea40bd 69e3d15b e8aace02 89aac332 
20:20:55 ipsec,debug => SK_ei (size 0x20) 
20:20:55 ipsec,debug 241a97d0 0b5715f3 879f50da 215c542d 22b7b919 ea759854 98cc7d90 1dfb9cbb 
20:20:55 ipsec,debug => SK_er (size 0x20) 
20:20:55 ipsec,debug 1fbe224e 37be1c95 86d867d4 311ee753 3c04f145 bd8132f1 52177478 5a5cb2c7 
20:20:55 ipsec,debug => SK_pi (size 0x14) 
20:20:55 ipsec,debug 17b360f0 4f448904 6b62ccb5 7691d409 1d1cea65 
20:20:55 ipsec,debug => SK_pr (size 0x14) 
20:20:55 ipsec,debug cd9f7d3c 972a6cb5 e86d56eb cbcd38ab 0ae210e9 
20:20:55 ipsec,debug ===== received 236 bytes from SERVER.IP[4500] to CLIENT.IP[4500] 
20:20:55 ipsec -> ike2 request, exchange: INFORMATIONAL:653 SERVER.IP[4500] cd6c9547697d300f:62848846dee423c0 
20:20:55 ipsec payload seen: ENC (208 bytes) 
20:20:55 ipsec processing payload: ENC 
20:20:55 ipsec,debug => iv (size 0x10) 
20:20:55 ipsec,debug e3ecfcda eccb7ebc 937b1493 7775fea4 
20:20:55 ipsec,debug => plain payload (trimmed) (size 0x8) 
20:20:55 ipsec,debug 00000008 01000000 
20:20:55 ipsec,debug decrypted 
20:20:55 ipsec payload seen: DELETE (8 bytes) 
20:20:55 ipsec respond: info 
20:20:55 ipsec processing payloads: NOTIFY (none found) 
20:20:55 ipsec processing payloads: DELETE 
20:20:55 ipsec delete IKE SA 
20:20:55 ipsec <- ike2 reply, exchange: INFORMATIONAL:653 SERVER.IP[4500] cd6c9547697d300f:62848846dee423c0 
20:20:55 ipsec,debug ===== sending 108 bytes from CLIENT.IP[4500] to SERVER.IP[4500] 
20:20:55 ipsec,debug 1 times of 112 bytes message will be sent to SERVER.IP[4500] 
20:20:55 ipsec rekey done 
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Tue Aug 18, 2020 12:19 am

send-initial-contact=yes is not an instruction to act as initiator; it actually means "replace any already existing connection from my IP address, irrespective of port, by this new one", so it is quite dangerous in some scenarios (multiple initiators coming to the responded from behind the same NAT address). But you're not the only one to get trapped by the name, I had the same wrong understanding for months, and so had others.
I guess I am a victim of this as well... Thanks for the hint and explanation, sindy!
 
User avatar
Znevna
Forum Guru
Forum Guru
Topic Author
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Tue Aug 18, 2020 8:44 pm

On the clock, now it's back to initiator (1 day).
So, it has a chance to switch every 24 hours, which equals to the lifetime set in the ipsec profile, phase 1 ?
I've set a script to check for sides switching and if any switch occurs to notify me over Telegram. That's how I pinned it down. (that Telegram script will be useful in the future too, for other purposes, glad I got it set, and the one watching over value changes ^^).
Now, both sides have the phase 1 lifetime set to 24 hours, and from what I can gather from the logs, whichever side initiates the rekey first, gets to be the initiator. Correct me if I'm wrong.
Log for the switch back to initiator, captured also from the client:
20:21:44 ipsec IKE SA lifetime expired, rekeying 
20:21:44 ipsec adding payload: SA 
20:21:44 ipsec,debug => (size 0x38) 
[...]
20:21:44 ipsec adding payload: KE 
20:21:44 ipsec,debug => (first 0x100 of 0x108) 
[...]
20:21:44 ipsec adding payload: NONCE 
20:21:44 ipsec,debug => (size 0x1c) 
20:21:44 ipsec,debug 0000001c 9b5df9e7 04f0b6a4 c5f7d44d 5d21fc5c b4de8314 ff3e563e 
20:21:44 ipsec <- ike2 request, exchange: CREATE_CHILD_SA:604 SERVER.IP[4500] 14701140c6f2c116:606ed9b3fc7a9c76 
20:21:44 ipsec,debug ===== sending 556 bytes from CLIENT.IP[4500] to SERVER.IP[4500] 
20:21:44 ipsec,debug 1 times of 560 bytes message will be sent to SERVER.IP[4500] 
20:21:44 ipsec,debug ===== received 540 bytes from SERVER.IP[4500] to CLIENT.IP[4500] 
20:21:44 ipsec -> ike2 reply, exchange: CREATE_CHILD_SA:604 SERVER.IP[4500] 14701140c6f2c116:606ed9b3fc7a9c76 
20:21:44 ipsec payload seen: ENC (512 bytes) 
20:21:44 ipsec processing payload: ENC 
20:21:44 ipsec,debug => iv (size 0x10) 
20:21:44 ipsec,debug 41096c51 414381d8 fc2cbfb2 7d1185fb 
20:21:44 ipsec,debug => plain payload (trimmed) (first 0x100 of 0x15c) 
[...]
20:21:44 ipsec,debug decrypted 
20:21:44 ipsec payload seen: SA (56 bytes) 
20:21:44 ipsec payload seen: KE (264 bytes) 
20:21:44 ipsec payload seen: NONCE (28 bytes) 
20:21:44 ipsec rekey: finish 
20:21:44 ipsec processing payloads: NOTIFY (none found) 
20:21:44 ipsec processing payload: NONCE 
20:21:44 ipsec processing payload: SA 
20:21:44 ipsec IKE Protocol: IKE 
20:21:44 ipsec  proposal #1 
20:21:44 ipsec   enc: aes256-cbc 
20:21:44 ipsec   prf: hmac-sha1 
20:21:44 ipsec   auth: sha1 
20:21:44 ipsec   dh: modp2048 
20:21:44 ipsec matched proposal: 
20:21:44 ipsec  proposal #1 
20:21:44 ipsec   enc: aes256-cbc 
20:21:44 ipsec   prf: hmac-sha1 
20:21:44 ipsec   auth: sha1 
20:21:44 ipsec   dh: modp2048 
20:21:44 ipsec processing payload: KE 
20:21:45 ipsec,debug => shared secret (size 0x100) 
[...]
20:21:45 ipsec adding payload: DELETE 
20:21:45 ipsec,debug => (size 0x8) 
20:21:45 ipsec,debug 00000008 01000000 
20:21:45 ipsec <- ike2 request, exchange: INFORMATIONAL:605 SERVER.IP[4500] 14701140c6f2c116:606ed9b3fc7a9c76 
20:21:45 ipsec,debug ===== sending 236 bytes from CLIENT.IP[4500] to SERVER.IP[4500] 
20:21:45 ipsec,debug 1 times of 240 bytes message will be sent to SERVER.IP[4500] 
20:21:45 ipsec,debug => skeyseed (size 0x14) 
20:21:45 ipsec,debug 001d6686 3f0cbf85 9f63d9e6 ebf1af80 cda557c4 
20:21:45 ipsec,debug => keymat (size 0x14) 
20:21:45 ipsec,debug 95989951 4758a7ba e3b8fe59 1f914d65 24c127f2 
20:21:45 ipsec,debug => SK_ai (size 0x14) 
20:21:45 ipsec,debug 261422d2 9f8ec4a2 00abe6bd db0444c5 4a4b2379 
20:21:45 ipsec,debug => SK_ar (size 0x14) 
20:21:45 ipsec,debug 2e30e9fb e232e416 0706e58b 0bddde5a 42485794 
20:21:45 ipsec,debug => SK_ei (size 0x20) 
20:21:45 ipsec,debug f1cc2394 a3761bcf b3238d53 aa5b6fd8 8f2f3c81 0a467038 3bd12356 6564cb0d 
20:21:45 ipsec,debug => SK_er (size 0x20) 
20:21:45 ipsec,debug ff019301 739cd5bb 655de74e b70ad81b f86bab60 7b047600 6d2d79a9 09b0ae93 
20:21:45 ipsec,debug => SK_pi (size 0x14) 
20:21:45 ipsec,debug 8b177554 7fccdbc3 7b5978e3 605f17ae f2c6342e 
20:21:45 ipsec,debug => SK_pr (size 0x14) 
20:21:45 ipsec,debug 76144050 4a4180de 3ff275d4 2691af62 9029689e 
20:21:45 ipsec,debug ===== received 156 bytes from SERVER.IP[4500] to CLIENT.IP[4500] 
20:21:45 ipsec -> ike2 reply, exchange: INFORMATIONAL:605 SERVER.IP[4500] 14701140c6f2c116:606ed9b3fc7a9c76 
20:21:45 ipsec payload seen: ENC (128 bytes) 
20:21:45 ipsec processing payload: ENC 
20:21:45 ipsec,debug => iv (size 0x10) 
20:21:45 ipsec,debug 957bcbf1 bb57d0d5 c3426ab7 0151d314 
20:21:45 ipsec,debug => plain payload (trimmed) (size 0x0) 
20:21:45 ipsec,debug decrypted 
20:21:45 ipsec respond: info 
20:21:45 ipsec got reply 
20:21:45 ipsec rekey done 
20:21:50 script,info ike2peer: MONITORED.PEER.NAME switched side to: initiator 
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Tue Aug 18, 2020 10:07 pm

As earlier written by me I have the same behaviour but then after between 15 and 35 minutes.

Like you I made a log but that did not show anything sticking out. It only happens with one VPN provider. It happens on my on my 4011 and hEX-S so platform independable.
 
User avatar
Znevna
Forum Guru
Forum Guru
Topic Author
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Wed Aug 19, 2020 8:42 pm

On the clock again.
Now since I've established that phase1 rekeying is the culprit (I think? right?) if I disable DPD on the server side (as per the documentation DPD is the one forcing phase 1 rekey) how will that affect my other connected clients to it? Do Windows clients care about the DPD set on the server ? I have little to no knowledge about this.
Is anyone from MikroTik watching this? I'd file a bug report but i'm not very eager to switch my gear from 6.46 to 6.47 with all them changes involved, if this gets fixed in the .47 branch or higher that is.
Probably I'll switch to the next Long-Term release if it gets to 6.46.x and stay on that one for a looooong time.
Thanks.
20:22:12 ipsec,debug ===== received 588 bytes from SERVER.IP[4500] to CLIENT.IP[4500] 
20:22:12 ipsec -> ike2 request, exchange: CREATE_CHILD_SA:647 SERVER.IP[4500] 0cb9f8b572ccd9d2:671d673072bb45dc 
20:22:12 ipsec payload seen: ENC (560 bytes) 
20:22:12 ipsec processing payload: ENC 
20:22:12 ipsec,debug => iv (size 0x10) 
20:22:12 ipsec,debug 8f200ffd 066a266d 2fde2b2e 65e8fe75 
20:22:12 ipsec,debug => plain payload (trimmed) (first 0x100 of 0x15c) 
[...]
20:22:12 ipsec,debug decrypted 
20:22:12 ipsec payload seen: SA (56 bytes) 
20:22:12 ipsec payload seen: KE (264 bytes) 
20:22:12 ipsec payload seen: NONCE (28 bytes) 
20:22:12 ipsec create child: respond 
20:22:12 ipsec processing payloads: NOTIFY (none found) 
20:22:12 ipsec IKE SA rekey 
20:22:12 ipsec processing payload: SA 
20:22:12 ipsec IKE Protocol: IKE 
20:22:12 ipsec  proposal #1 
20:22:12 ipsec   enc: aes256-cbc 
20:22:12 ipsec   prf: hmac-sha1 
20:22:12 ipsec   auth: sha1 
20:22:12 ipsec   dh: modp2048 
20:22:12 ipsec matched proposal: 
20:22:12 ipsec  proposal #1 
20:22:12 ipsec   enc: aes256-cbc 
20:22:12 ipsec   prf: hmac-sha1 
20:22:12 ipsec   auth: sha1 
20:22:12 ipsec   dh: modp2048 
20:22:12 ipsec processing payload: KE 
20:22:12 ipsec processing payload: NONCE 
20:22:12 ipsec,debug => shared secret (size 0x100) 
[...]
20:22:12 ipsec adding payload: SA 
20:22:12 ipsec,debug => (size 0x38) 
20:22:12 ipsec,debug 00000038 00000034 01010804 2221e39a 3505ead6 0300000c 0100000c 800e0100 
20:22:12 ipsec,debug 03000008 02000002 03000008 03000002 00000008 0400000e 
20:22:12 ipsec adding payload: KE 
20:22:12 ipsec,debug => (first 0x100 of 0x108) 
[...]
20:22:12 ipsec adding payload: NONCE 
20:22:12 ipsec,debug => (size 0x1c) 
20:22:12 ipsec,debug 0000001c 203e646b 82b4313d 8245e5dd 127c06b8 5616ffd4 2809567b 
20:22:12 ipsec <- ike2 reply, exchange: CREATE_CHILD_SA:647 SERVER.IP[4500] 0cb9f8b572ccd9d2:671d673072bb45dc 
20:22:12 ipsec,debug ===== sending 588 bytes from CLIENT.IP[4500] to SERVER.IP[4500] 
20:22:12 ipsec,debug 1 times of 592 bytes message will be sent to SERVER.IP[4500] 
20:22:12 ipsec,debug => skeyseed (size 0x14) 
20:22:12 ipsec,debug e4e91dda d9655739 3da8eef1 58801b9e 34eb426a 
20:22:12 ipsec,debug => keymat (size 0x14) 
20:22:12 ipsec,debug fee01920 53827f84 88158f25 84f3d0e9 707e5359 
20:22:12 ipsec,debug => SK_ai (size 0x14) 
20:22:12 ipsec,debug 937273ae b00fb076 8f236545 62187208 af1b8e53 
20:22:12 ipsec,debug => SK_ar (size 0x14) 
20:22:12 ipsec,debug 1b00b816 e35b7ecc 34db5064 cfe02c11 164d8412 
20:22:12 ipsec,debug => SK_ei (size 0x20) 
20:22:12 ipsec,debug 34b5b506 029ec827 6bdfd883 b4f30bdc 8e742509 b9cf7d4f 4bd8f83d 1cf73936 
20:22:12 ipsec,debug => SK_er (size 0x20) 
20:22:12 ipsec,debug 693beda2 7a2499e3 2bfd4a8c cdcf554b 3267e481 e7fab2b5 8e29a07f 7402bd29 
20:22:12 ipsec,debug => SK_pi (size 0x14) 
20:22:12 ipsec,debug b1e71807 36c423a7 0ea99c40 b3fa92a8 b251e0f8 
20:22:12 ipsec,debug => SK_pr (size 0x14) 
20:22:12 ipsec,debug 768a9e69 c7a55820 c31c1637 a82bf988 9af98cfb 
20:22:12 ipsec,debug ===== received 220 bytes from SERVER.IP[4500] to CLIENT.IP[4500] 
20:22:12 ipsec -> ike2 request, exchange: INFORMATIONAL:648 SERVER.IP[4500] 0cb9f8b572ccd9d2:671d673072bb45dc 
20:22:12 ipsec payload seen: ENC (192 bytes) 
20:22:12 ipsec processing payload: ENC 
20:22:12 ipsec,debug => iv (size 0x10) 
20:22:12 ipsec,debug febd58d4 ff331e3f 59e75b7f f8d84588 
20:22:12 ipsec,debug => plain payload (trimmed) (size 0x8) 
20:22:12 ipsec,debug 00000008 01000000 
20:22:12 ipsec,debug decrypted 
20:22:12 ipsec payload seen: DELETE (8 bytes) 
20:22:12 ipsec respond: info 
20:22:12 ipsec processing payloads: NOTIFY (none found) 
20:22:12 ipsec processing payloads: DELETE 
20:22:12 ipsec delete IKE SA 
20:22:12 ipsec <- ike2 reply, exchange: INFORMATIONAL:648 SERVER.IP[4500] 0cb9f8b572ccd9d2:671d673072bb45dc 
20:22:12 ipsec,debug ===== sending 92 bytes from CLIENT.IP[4500] to SERVER.IP[4500] 
20:22:12 ipsec,debug 1 times of 96 bytes message will be sent to SERVER.IP[4500] 
20:22:12 ipsec rekey done 
20:22:20 script,info ike2peer: MONITORED.PEER switched side to: responder 
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Wed Aug 19, 2020 10:39 pm

Well... I've never heard that DPD (Dead Peer Detection) was responsible for Phase 1 rekey - it tears down the current Phase 1 session if the remote peer stops responding and starts a new one if the local peer has the initiator behavior enabled.

But after the Phase 1's lifetime expires, it gets re-established even id DPD says everything is allright, but I don't think you have a chance to affect which peer will start the process, i.e. if the remote non-Mikrotik device initiates a new Phase 1, the Mikrotik one will act as a responder. The UDP pinhole in the firewall (the tracked connection) is up at that time, created and maintained by the previous session, so the negotiation will pass through and succeed even if the Mikrotik is behind a NAT.

What's so bad about the Tik running as a responder?
 
User avatar
Znevna
Forum Guru
Forum Guru
Topic Author
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Wed Aug 19, 2020 10:53 pm

In the manual there's a warning
Warning: Phase 1 is not re-keyed if DPD is disabled when lifetime expires, only phase 2 is re-keyed. To force phase 1 re-key, enable DPD.
This switch only happens when both sides are Tiks. Or so I've noticed until now.
That's why I thought that setting DPD to disabled on the server/responder will prevent it from requesting a rekey and by doing that, becoming the initiator.
It's not a real problem.. for now. As I've said in the first post.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Wed Aug 19, 2020 11:02 pm

In the manual there's a warning
Warning: Phase 1 is not re-keyed if DPD is disabled when lifetime expires, only phase 2 is re-keyed. To force phase 1 re-key, enable DPD.
Hm, missed that, but as it is presented as a warning, I'd rather suspect that when DPD is disabled, the phase 1 doesn't automatically re-establish after its lifetime expires and you have to you pushstart it manually.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Thu Aug 20, 2020 12:14 am

So I switched off my DPD on the client-side (I am using VPN a provider) and that worked, the Side is now staying initiator.

I saw the renew of the connection and the state column in Active Peers stated something like: message 1 renew and it stayed about 15 seconds that way and then it stated established.

Update:


Not nice! It looked all good and I even could post this posting however, no traffic was flowing over the IKEv2 tunnels so I will enable DPD again.
 
tdw
Forum Guru
Forum Guru
Posts: 1843
Joined: Sat May 05, 2018 11:55 am

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Sun May 22, 2022 7:47 pm

I have recently discovered this whilst looking at replacing IKE with IKE2 and thought I was doing something wrong. It doesn't affect the current use case, but what happens if you are using mode-config?

And what appears to be another error in the documentation - for peer exchange-mode it says "Parameters that are ignored by IKEv2 proposal-check, compatibility-options, lifebytes, dpd-maximum-failures, nat-traversal.", and whilst a connection can sucessfully made with the profile having nat-traversal=no from a client behind NAT subsequent phase2 rekeying breaks.
 
User avatar
Znevna
Forum Guru
Forum Guru
Topic Author
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: IKEv2 between MikroTiks, sides switching, initiator <> responder

Sun May 22, 2022 9:35 pm

I've stopped looking into this, I don't remember if those peers had mode-config set or not but i'm pretty sure they had, but the tunnel does not go down during that side switching so it's not rebuilt from scratch(? don't quote me on this, just a guess) and mode-conf isn't affected by this, I didn't notice any problems anyway.
I'll check these days.

Who is online

Users browsing this forum: eworm and 37 guests