On Tue, Jun 16, 2020 at 05:08:47PM -0400, Daniel Ouellet wrote: > > 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.
What I see is that the initial message is received but ignored, so this side here probably runs into some kind of error. To find out what exactly causes this, a more verbose log would help. You could manually start iked with -dvv and share the log for an incoming IKE_SA_INIT request from 72.83.103.147:500 (best without the grep because the following lines may contain the actual error messages). Another thing i notice is that this log seems to be from an older iked version. Could you give me a hint what iked version we're looking at so i can try to reproduce the problem? > > 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. >
