> The retransmits tell us that the peer doesn't answer. Or, to be more
> precise, it doesn't receive *any* message from the peer. Can you have
> a look at the peer's logs? Does the peer see these packets but chooses
> not to reply? Is the peer also an OpenBSD? 6.6? 6.7?
Not a big deal, but yes the remote received and send reply back. I
pointed it out in my reply as well.
"Now if I put the iked 6.7 binary instead, I see the traffic going out,
enter the remote tunnel, getting out of the tunnel to come back, but
never coming in the gateway unit."
Here is the logs from the remote device. I filter by the source IP to
reduce the logs as there is a lots of different clients on that box.
And you can see the reply as well at Jun 16 16:39:48 below.
# tail -f /var/log/daemon | grep 72.83.103.147
Jun 16 16:36:27 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:36:27 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:36:43 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:36:43 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:37:15 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:37:15 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:05 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:05 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:11 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:11 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:19 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:19 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:35 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:35 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:39:48 tunnel iked[5075]: ikev2_msg_send: CREATE_CHILD_SA
request from 66.63.5.250:500 to 72.83.103.147:500 msgid 0, 256 bytes
Jun 16 16:40:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
Jun 16 16:40:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from
initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0,
278 bytes
> If you can't look at the looks, you could tcpdump on both sides port 500
> and check if a) the packet arrives at the peer b) the peer tries to
> respond.
Here with the 6.7 binary:
gateway$ doas tcpdump -nnttti re0 host 66.63.5.250 and udp port 500
tcpdump: listening on re0, link-type EN10MB
Jun 16 16:51:53.161393 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0
exchange IKE_SA_INIT
cookie: 5910d1be1404a0fb->0000000000000000 msgid: 00000000 len: 278
Jun 16 16:51:53.178950 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0
exchange IKE_SA_INIT
cookie: 1c613d84d5a295ac->0000000000000000 msgid: 00000000 len: 278
Jun 16 16:51:55.183540 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0
exchange IKE_SA_INIT
cookie: 5910d1be1404a0fb->0000000000000000 msgid: 00000000 len: 278
Jun 16 16:51:55.183697 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0
exchange IKE_SA_INIT
cookie: 1c613d84d5a295ac->0000000000000000 msgid: 00000000 len: 278
Jun 16 16:51:59.193888 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0
exchange IKE_SA_INIT
cookie: 5910d1be1404a0fb->0000000000000000 msgid: 00000000 len: 278
Jun 16 16:51:59.194092 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0
exchange IKE_SA_INIT
cookie: 1c613d84d5a295ac->0000000000000000 msgid: 00000000 len: 278
^C
11496 packets received by filter
0 packets dropped by kernel
gateway$ doas ipsecctl -sa
FLOWS:
No flows
SAD:
No entries
gateway$
And here with the 6.6 binary
gateway$ doas tcpdump -nnttti re0 host 66.63.5.250 and udp port 500
tcpdump: listening on re0, link-type EN10MB
Jun 16 16:55:15.385546 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0
exchange IKE_SA_INIT
cookie: b4dfb8b6f7b33c1b->0000000000000000 msgid: 00000000 len: 454
Jun 16 16:55:15.415187 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0
exchange IKE_SA_INIT
cookie: 959f77ed75e4b7c1->0000000000000000 msgid: 00000000 len: 454
Jun 16 16:55:15.417793 66.63.5.250.500 > 72.83.103.147.500: isakmp v2.0
exchange IKE_SA_INIT
cookie: b4dfb8b6f7b33c1b->3ad701e36ad01315 msgid: 00000000 len: 395
Jun 16 16:55:15.445981 66.63.5.250.500 > 72.83.103.147.500: isakmp v2.0
exchange IKE_SA_INIT
cookie: 959f77ed75e4b7c1->1a51595cd83fa60c msgid: 00000000 len: 395
Jun 16 16:55:15.510138 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0
exchange IKE_AUTH
cookie: b4dfb8b6f7b33c1b->3ad701e36ad01315 msgid: 00000001 len: 784
Jun 16 16:55:15.510876 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0
exchange IKE_AUTH
cookie: 959f77ed75e4b7c1->1a51595cd83fa60c msgid: 00000001 len: 1168
Jun 16 16:55:15.523336 66.63.5.250.500 > 72.83.103.147.500: isakmp v2.0
exchange IKE_AUTH
cookie: b4dfb8b6f7b33c1b->3ad701e36ad01315 msgid: 00000001 len: 752
Jun 16 16:55:15.528667 66.63.5.250.500 > 72.83.103.147.500: isakmp v2.0
exchange IKE_AUTH
cookie: 959f77ed75e4b7c1->1a51595cd83fa60c msgid: 00000001 len: 752
^C
All works.
As you can see in both example, he reply is drop as show above on the
local device for the version 6.7, but not for 6.6.
1. It send the request.
2. The remove received it.
3. The remote send the reply.
4. Local device drop it.
My issue is I can't figure out what needs to be changed to actually get
it back to work as it was before or the new way and the
https://www.openbsd.org/faq/upgrade67.html
point the changes from use to required, but my problem is that I lack
what actually needs to be changed to work with the new way.
> So yeah, maybe the peer doesn't want to respond due to some changes.
> This is a different problem to what the other people have, since you
> cannot even get an answer to your IKE_SA_INIT message.
Again here I get all working well with the 6.6 binary version on the
local device (no change what so ever on the remote) and with the 6.7
binary on the local device, and again nothing else change, the 6.7
doesn't. No changes done other then using either binary, 6.6 or 6.7 on
the local device only everything else stay the same as you can see above.
