Re: IKEv2 difference with 6.7
Hi Tobias, > So the error message is probably in the other side's logs but here is > a guess: 5.6 doesn't know curve25519. > > Try adding the following to your iked.conf: > > ikesa group modp2048 Many thanks!!! That was the issue and you saved me from pulling what I have left of hairs. Thank you! Daniel
Re: IKEv2 difference with 6.7
On 2020-06-16 12:32, Tobias Heider wrote: On Fri, Jun 12, 2020 at 09:27:18PM +0200, Tobias Heider wrote: On Fri, Jun 12, 2020 at 03:31:56PM +0200, Patrik Ragnarsson wrote: Hi, We have two OpenBSD machines acting as gateways for our network using CARP and IPsec (IKEv2). When the machines were running OpenBSD 6.6, from an IPSec client, you were able to reach the passive gateway while being connected to the active gateway. On OpenBSD 6.7, it seems this is no longer possible. The setup looks like this: - The two servers share using CARP (carp10 (carpdev trunk1)) - The two servers share 10.200.200.1 using CARP (carp20 (carpdev vlan2000)) - The active (MASTER) gateway has 10.200.200.2 (vlan2000 (parent trunk0)) - The passive (BACKUP) gateway has 10.200.200.3 (vlan2000 (parent trunk0)) iked.conf looks like this on both machines: $ cat /etc/iked.conf local_endpoint = "" roadwarrior_net = "10.100.100.0/24" ikev2 "roadwarrior-psk" ipcomp esp \ from 10.200.200.0/24 to 0.0.0.0/0 \ peer any local $local_endpoint \ srcid $local_endpoint \ psk "" \ config address $roadwarrior_net \ config netmask 255.255.255.0\ tag "$name-$id" sasyncd.conf from the active gateway: $ cat /etc/sasyncd.conf interface carp10 listen on 10.200.200.2 peer 10.200.200.3 control iked sharedkey sasyncd.conf from the passive gateway: $ cat /etc/sasyncd.conf interface carp10 listen on 10.200.200.3 peer 10.200.200.2 control iked sharedkey The PF rules on both gateways looks like this: block drop log all pass on vlan2000 proto carp all keep state (no-sync) pass on trunk1 proto carp all keep state (no-sync) pass on vlan2000 all no state pass out on trunk1 all flags S/SA pass in on trunk1 inet proto tcp from any to (trunk1:0) port = 22 flags S/SA keep state (no-sync) pass in on trunk1 inet proto udp from any to (trunk1:0) port 6:61000 keep state (no-sync) pass out on trunk1:0 all flags S/SA keep state (no-sync) pass in on trunk1 inet proto icmp all block return in on trunk1 proto udp from any to any port 33434:33534 pass out on trunk1 from (vlan2000:network) to any flags S/SA nat-to (carp10:0) pass in on trunk1 inet proto udp from any to port = 500 pass in on trunk1 inet proto udp from any to port = 4500 pass out on trunk1 inet proto udp from to any port = 500 pass out on trunk1 inet proto udp from to any port = 4500 pass in on trunk1 inet proto esp from any to pass out on trunk1 inet proto esp from to any pass in on enc0 inet from 10.100.100.0/24 to 10.200.200.0/24 flags S/SA keep state (if-bound) pass in on enc0 inet proto ipencap from any to keep state (if-bound) pass out on enc0 inet from 10.200.200.0/24 to 10.100.100.0/24 flags S/SA keep state (if-bound) pass out on enc0 inet proto ipencap from to any keep state (if-bound) On both gateways, I can see that the same flows and SAs have been created after the client have connected to the VPN. (ipsecctl -s all) A client (macOS) can reach 10.200.200.1 and 10.200.200.2 (and other servers in 10.200.200.0/24) but not 10.200.200.3: $ ping -c5 10.200.200.3 PING 10.200.200.3 (10.200.200.3): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 --- 10.200.200.3 ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss I can see the ICMP echo requests reach the vlan2000 interface on the passive gateway (tcpdump -netti vlan2000 icmp) 1591718254.738903 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request 1591718255.740275 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request 1591718256.740455 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request 1591718257.743593 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request Running iked in the foreground (iked -dv) on the passive gateway, I can see the following when I try to ping 10.200.200.3 from the client: pfkey_process: acquire request (peer ) pfkey_process: flow in from 10.200.200.0/255.255.255.0 to 10.100.100.173/255.255.255.255 via ikev2_acquire_sa: flow wasn't found I've also tried disabling PF on the passive gateway, I still couldn't reach 10.200.200.3. Appreciate it if anyone has any ideas of what's going on. Thanks! Probably related to the following change documented in https://www.openbsd.org/faq/upgrade67.html: iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by iked(8) or isakmpd(8) was changed from "use" to "require". This means unencrypted traffic matching
Re: IKEv2 difference with 6.7
On Tue, Jun 16, 2020 at 08:20:59PM -0400, Daniel Ouellet wrote: > Hi, > > > 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). > > gateway# iked -dvv > set_policy_auth_method: using rsa for peer > /etc/iked/pubkeys/ipv4/66.63.5.250 > set_policy: found pubkey for /etc/iked/pubkeys/ipv4/66.63.5.250 > ikev2 "VPN" active tunnel esp inet from 72.83.103.147 to 66.63.5.250 > local 72.83.103.147 peer 66.63.5.250 ikesa enc > aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth > hmac-sha2-256,hmac-sha1 group > curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 > childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 > esn,noesn lifetime 10800 bytes 536870912 rsa > set_policy_auth_method: using rsa for peer > /etc/iked/pubkeys/ipv4/66.63.5.250 > set_policy: found pubkey for /etc/iked/pubkeys/ipv4/66.63.5.250 > ikev2 "Flow" active tunnel esp inet from 66.63.44.66 to 0.0.0.0/0 from > 66.63.44.90 to 0.0.0.0/0 from 66.63.44.96/28 to 0.0.0.0/0 from > 66.63.44.67 to 66.63.0.0/18 from 66.63.44.79 to 45.7.36.0/22 from > 66.63.44.79 to 185.40.64.0/22 from 66.63.44.79 to 43.229.64.0/22 from > 66.63.44.79 to 162.249.72.0/21 from 66.63.44.79 to 104.160.128.0/19 from > 66.63.44.79 to 192.64.168.0/21 from 66.63.44.79 to 103.240.224.0/22 from > 66.63.44.65 to 66.63.5.245 from 66.63.44.65 to 66.63.5.250 local any > peer 66.63.5.250 ikesa enc aes-256,aes-192,aes-128,3des prf > hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group > curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 > childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 > esn,noesn lifetime 10800 bytes 536870912 rsa > /etc/iked.conf: loaded 2 configuration rules > ca_privkey_serialize: type RSA_KEY length 1191 > ca_pubkey_serialize: type RSA_KEY length 270 > ca_privkey_to_method: type RSA_KEY method RSA_SIG > ca_getkey: received private key type RSA_KEY length 1191 > ca_getkey: received public key type RSA_KEY length 270 > ca_dispatch_parent: config reset > config_getpolicy: received policy > ca_reload: local cert type RSA_KEY > config_getocsp: ocsp_url none > config_getpolicy: received policy > ikev2_dispatch_cert: updated local CERTREQ type RSA_KEY length 0 > config_getpfkey: received pfkey fd 3 > config_getcompile: compilation done > config_getsocket: received socket fd 4 > config_getsocket: received socket fd 5 > config_getsocket: received socket fd 6 > config_getsocket: received socket fd 7 > config_getmobike: mobike > config_getfragmentation: no fragmentation > config_getnattport: nattport 4500 > ikev2_init_ike_sa: initiating "VPN" > ikev2_policy2id: srcid FQDN/gateway.ouellet.us length 22 > ikev2_add_proposals: length 156 > ikev2_next_payload: length 160 nextpayload KE > ikev2_next_payload: length 40 nextpayload NONCE > ikev2_next_payload: length 36 nextpayload NOTIFY > ikev2_nat_detection: local source 0xe6b00a86abde210d 0x > 72.83.103.147:500 > ikev2_next_payload: length 28 nextpayload NOTIFY > ikev2_nat_detection: local destination 0xe6b00a86abde210d > 0x 66.63.5.250:500 > ikev2_next_payload: length 28 nextpayload NOTIFY > ikev2_next_payload: length 14 nextpayload NONE > ikev2_pld_parse: header ispi 0xe6b00a86abde210d rspi 0x > nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 > length 334 response 0 > ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 160 > ikev2_pld_sa: more 0 reserved 0 length 156 proposal #1 protoid IKE > spisize 0 xforms 17 spi 0 > ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC > ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4 > ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC > ikev2_pld_attr: attribute type KEY_LENGTH length 192 total 4 > ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC > ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 > ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES > ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256 > ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1 > ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128 > ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id CURVE25519 > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_521 > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_384 > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_256 > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_4096 >
Re: IKEv2 difference with 6.7
Hi, > 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). gateway# iked -dvv set_policy_auth_method: using rsa for peer /etc/iked/pubkeys/ipv4/66.63.5.250 set_policy: found pubkey for /etc/iked/pubkeys/ipv4/66.63.5.250 ikev2 "VPN" active tunnel esp inet from 72.83.103.147 to 66.63.5.250 local 72.83.103.147 peer 66.63.5.250 ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 esn,noesn lifetime 10800 bytes 536870912 rsa set_policy_auth_method: using rsa for peer /etc/iked/pubkeys/ipv4/66.63.5.250 set_policy: found pubkey for /etc/iked/pubkeys/ipv4/66.63.5.250 ikev2 "Flow" active tunnel esp inet from 66.63.44.66 to 0.0.0.0/0 from 66.63.44.90 to 0.0.0.0/0 from 66.63.44.96/28 to 0.0.0.0/0 from 66.63.44.67 to 66.63.0.0/18 from 66.63.44.79 to 45.7.36.0/22 from 66.63.44.79 to 185.40.64.0/22 from 66.63.44.79 to 43.229.64.0/22 from 66.63.44.79 to 162.249.72.0/21 from 66.63.44.79 to 104.160.128.0/19 from 66.63.44.79 to 192.64.168.0/21 from 66.63.44.79 to 103.240.224.0/22 from 66.63.44.65 to 66.63.5.245 from 66.63.44.65 to 66.63.5.250 local any peer 66.63.5.250 ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 esn,noesn lifetime 10800 bytes 536870912 rsa /etc/iked.conf: loaded 2 configuration rules ca_privkey_serialize: type RSA_KEY length 1191 ca_pubkey_serialize: type RSA_KEY length 270 ca_privkey_to_method: type RSA_KEY method RSA_SIG ca_getkey: received private key type RSA_KEY length 1191 ca_getkey: received public key type RSA_KEY length 270 ca_dispatch_parent: config reset config_getpolicy: received policy ca_reload: local cert type RSA_KEY config_getocsp: ocsp_url none config_getpolicy: received policy ikev2_dispatch_cert: updated local CERTREQ type RSA_KEY length 0 config_getpfkey: received pfkey fd 3 config_getcompile: compilation done config_getsocket: received socket fd 4 config_getsocket: received socket fd 5 config_getsocket: received socket fd 6 config_getsocket: received socket fd 7 config_getmobike: mobike config_getfragmentation: no fragmentation config_getnattport: nattport 4500 ikev2_init_ike_sa: initiating "VPN" ikev2_policy2id: srcid FQDN/gateway.ouellet.us length 22 ikev2_add_proposals: length 156 ikev2_next_payload: length 160 nextpayload KE ikev2_next_payload: length 40 nextpayload NONCE ikev2_next_payload: length 36 nextpayload NOTIFY ikev2_nat_detection: local source 0xe6b00a86abde210d 0x 72.83.103.147:500 ikev2_next_payload: length 28 nextpayload NOTIFY ikev2_nat_detection: local destination 0xe6b00a86abde210d 0x 66.63.5.250:500 ikev2_next_payload: length 28 nextpayload NOTIFY ikev2_next_payload: length 14 nextpayload NONE ikev2_pld_parse: header ispi 0xe6b00a86abde210d rspi 0x nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 334 response 0 ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 160 ikev2_pld_sa: more 0 reserved 0 length 156 proposal #1 protoid IKE spisize 0 xforms 17 spi 0 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 192 total 4 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256 ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id CURVE25519 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_521 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_384 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_256 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_4096 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_3072 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_1536 ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_1024
Re: IKEv2 difference with 6.7
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-> msgid:
Re: IKEv2 difference with 6.7
On 2020-06-12, Tobias Heider wrote: > Probably related to the following change documented in > https://www.openbsd.org/faq/upgrade67.html: > > iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by iked(8) > or > isakmpd(8) was changed from "use" to "require". This means unencrypted traffic > matching the flows will no longer be accepted. Flows of type "use" can still > be > set up manually in ipsec.conf(5). > > The problem is that the incoming packet on 10.200.200.3 matches the installed > IPsec flow which only accepts encrypted packets. > > Just leaving this for the list archive, if anyone needs it this is how you can reverse that change: Index: pfkey.c === RCS file: /cvs/src/sbin/iked/pfkey.c,v retrieving revision 1.65 diff -u -p -r1.65 pfkey.c --- pfkey.c 13 May 2020 18:28:51 - 1.65 +++ pfkey.c 16 Jun 2020 22:47:54 - @@ -280,7 +280,9 @@ pfkey_flow(int sd, uint8_t satype, uint8 sa_flowtype.sadb_protocol_exttype = SADB_X_EXT_FLOW_TYPE; sa_flowtype.sadb_protocol_len = sizeof(sa_flowtype) / 8; sa_flowtype.sadb_protocol_direction = flow->flow_dir; - sa_flowtype.sadb_protocol_proto = SADB_X_FLOW_TYPE_REQUIRE; + sa_flowtype.sadb_protocol_proto = + (flow->flow_dir == IPSP_DIRECTION_IN ? + SADB_X_FLOW_TYPE_USE : SADB_X_FLOW_TYPE_REQUIRE); bzero(_protocol, sizeof(sa_protocol)); sa_protocol.sadb_protocol_exttype = SADB_X_EXT_PROTOCOL;
Re: IKEv2 difference with 6.7
> 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-> msgid: 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-> msgid: 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-> msgid: 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-> msgid: 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-> msgid: 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:
Re: IKEv2 difference with 6.7
On Tue, Jun 16, 2020 at 02:11:21PM -0400, Daniel Ouellet wrote: > > > On 6/16/20 1:35 PM, Patrick Wildt wrote: > > On Tue, Jun 16, 2020 at 01:09:32PM -0400, Daniel Ouellet wrote: > >> Hi Tobias, > >> > >> I put below the full configuration and the flows as well with the 6.6 > >> binary and switch to the 6.7 binary without any other changes as well as > >> the full config. > >> > >> The config may be a bit weird at first as I tunnel routable IP's over > >> the iked over a Verizon Fios line. You can't get routable IP's from Fios > >> and I have needs for it. So that was my way around it for years now. > >> > >> Anyway, here below: > >> > >> gateway$ doas cat /etc/ipsec.conf > >> flow esp out from ::/0 to ::/0 type deny > >> flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass > >> flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass > >> flow esp from 66.63.44.67 to 66.63.44.97 type bypass > >> flow esp from 66.63.44.90 to 66.63.44.97 type bypass > >> > >> (This above was to allow the two local subnet to take to one an other as > >> they are in different dmz. I can delete that config and it changed > >> nothing anyway. Just wanted to write why in case you wonder.) > >> > >> gateway$ doas cat /etc/iked.conf > >> # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in > >> Ashburn. > >> ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com > >> > >> ikev2 "Flow" active \ > >> from re1 to tunnel.realconnect.com \ > >> from re1 to stats.realconnect.com \ > >> from 66.63.44.66 to 0.0.0.0/0 \ > >> from 66.63.44.67 to 66.63.0.0/18 \ > >> from home.ouellet.us to 0.0.0.0/0 \ > >> from 66.63.44.96/28 to 0.0.0.0/0 \ > >>from 66.63.44.79 to 43.229.64.0/22 \ > >>from 66.63.44.79 to 45.7.36.0/22 \ > >>from 66.63.44.79 to 103.240.224.0/22 \ > >>from 66.63.44.79 to 104.160.128.0/19 \ > >>from 66.63.44.79 to 162.249.72.0/21 \ > >>from 66.63.44.79 to 185.40.64.0/22 \ > >>from 66.63.44.79 to 192.64.168.0/21 \ > >> peer tunnel.realconnect.com > >> > >> (Here above for the 66.63.44.79, again a weird stuff, that's only for my > >> older son. When he play LoL over Fios it suck! But when I tunnel it to > >> my tunnel and then directly to Equinix where Riot is and I peer at, all > >> is great and hard to believe I am sure, but latency is much lower. Again > >> not relevant, just in case you wonder. I know, it's stupid, but I do a > >> lots of work from home and I need to keep the family happy too. (;) > >> > >> On 6/16/20 6:09 AM, Tobias Heider wrote: > >>> Hi Daniel, > >>> > >>> On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote: > > Probably related to the following change documented in > > https://www.openbsd.org/faq/upgrade67.html: > > > > iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by > > iked(8) or > > isakmpd(8) was changed from "use" to "require". This means unencrypted > > traffic > > matching the flows will no longer be accepted. Flows of type "use" can > > still be > > set up manually in ipsec.conf(5). > > I have what appear to be similar problem. I used iked form 5.6 all the > way to 6.6 no problem, wel some, but I worked it out. All in archive. > > But going from 6.6 to 6.7 I can't get it to work anymore. Nothing > changed, same configuration, just a sysupgrade and that's it. > > I read this and I can understand the words, but may be I am think, but I > don't understand what to do with it. > >>> > >>> The default behavior if IPsec flows was changed to not accept unencrypted > >>> packets matching a registered flow. > >>> You can list your flows with 'ipsecctl -sf'. > >> > >> gateway$ doas ipsecctl -sf > >> flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 43.229.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 45.7.36.0/22 to 66.63.44.79 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 66.63.5.250 to
Re: IKEv2 difference with 6.7
Hi guys, First of all, thanks for the amazing work you've done with 6.7! That said, I've got the same issue here after I updated to 6.7. The VPN keeps cutting off every 10 minutes or so. Is there any way I could fix that ? Here's my configuration: local_gw="203.0.113.1" local_network="198.51.100.0/24" remote_gw="203.0.113.2" remote_network="192.0.2.0/26" remote_network2="192.0.2.64/26" ikev2 active esp \ from $local_gw to $remote_gw \ from $local_network to $remote_network \ from $local_network to $remote_network2 \ peer $remote_gw \ ikesa enc aes-128 auth hmac-sha1 prf hmac-sha1 group modp1536 \ childsa auth hmac-sha1 enc aes-128 group modp1536 \ ikelifetime 86400 lifetime 43200 \ psk "X" That's what I can see in the logs: Jun 16 08:07:00 vpn00 iked[31977]: ikev2_init_ike_sa: initiating "policy1" Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: send IKE_SA_INIT req 0 peer 203.0.113.2:500 local 0.0.0.0:500, 382 bytes Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: recv IKE_SA_INIT res 0 peer 203.0.113.2:500 local 203.0.113.1:500, 352 bytes, policy 'policy1' Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: send IKE_AUTH req 1 peer 203.0.113.2:4500 local 203.0.113.1:4500, 284 bytes, NAT-T Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: recv IKE_AUTH res 1 peer 203.0.113.2:4500 local 203.0.113.1:4500, 252 bytes, policy 'policy1' Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: ikev2_childsa_enable: loaded SPIs: 0xae51c8bb, 0x3ab61433 Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: ikev2_childsa_enable: loaded flows: ESP-198.51.100.0/24=192.0.2.64/26(0), ESP-198.51.100.0/24=192.0.2.0/26(0), ESP-203.0.113.1/32=203.0.113.2/32(0) Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: established peer 203.0.113.2:4500[IPV4/203.0.113.2] local 203.0.113.1:4500[FQDN/vpn00.example.net] policy 'policy1' as initiator Jun 16 08:12:02 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 1 INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 Jun 16 08:12:06 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 2 INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 Jun 16 08:12:14 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 3 INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 Jun 16 08:12:30 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 4 INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 Jun 16 08:13:02 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 5 INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 Jun 16 08:14:06 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: sa_free: retransmit limit reached Jun 16 08:15:00 vpn00 iked[31977]: ikev2_init_ike_sa: initiating "policy1" Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: send IKE_SA_INIT req 0 peer 203.0.113.2:500 local 0.0.0.0:500, 382 bytes Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: recv IKE_SA_INIT res 0 peer 203.0.113.2:500 local 203.0.113.1:500, 352 bytes, policy 'policy1' Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: send IKE_AUTH req 1 peer 203.0.113.2:500 local 203.0.113.1:500, 284 bytes Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: recv IKE_AUTH res 1 peer 203.0.113.2:500 local 203.0.113.1:500, 252 bytes, policy 'policy1' Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: ikev2_childsa_enable: loaded SPIs: 0xae51c8bd, 0x7009bc39 Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: ikev2_childsa_enable: loaded flows: ESP-198.51.100.0/24=192.0.2.64/26(0), ESP-198.51.100.0/24=192.0.2.0/26(0), ESP-203.0.113.1/32=203.0.113.2/32(0) Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: established peer 203.0.113.2:500[IPV4/203.0.113.2] local 203.0.113.1:500[FQDN/vpn00.example.net] policy 'policy1' as initiator Jun 16 08:16:02 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 1 INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 Jun 16 08:16:06 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 2 INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 Jun 16 08:16:14 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 3 INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 Jun 16 08:16:30 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 4 INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 Jun 16 08:17:02 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 5 INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 Jun 16 08:18:06 vpn00 iked[31977]: spi=0x3f6d5768feb36565: sa_free: retransmit limit reached On 2020-06-16 02:55, Daniel Ouellet wrote: Just for the records, I just took a copy of iked version 6.6 and used that instead of 6.7 and all is good. I saved the 6.7 version. gateway# ls -al /sbin/iked* -r-xr-xr-x
Re: IKEv2 difference with 6.7
On 6/16/20 1:35 PM, Patrick Wildt wrote: > On Tue, Jun 16, 2020 at 01:09:32PM -0400, Daniel Ouellet wrote: >> Hi Tobias, >> >> I put below the full configuration and the flows as well with the 6.6 >> binary and switch to the 6.7 binary without any other changes as well as >> the full config. >> >> The config may be a bit weird at first as I tunnel routable IP's over >> the iked over a Verizon Fios line. You can't get routable IP's from Fios >> and I have needs for it. So that was my way around it for years now. >> >> Anyway, here below: >> >> gateway$ doas cat /etc/ipsec.conf >> flow esp out from ::/0 to ::/0 type deny >> flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass >> flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass >> flow esp from 66.63.44.67 to 66.63.44.97 type bypass >> flow esp from 66.63.44.90 to 66.63.44.97 type bypass >> >> (This above was to allow the two local subnet to take to one an other as >> they are in different dmz. I can delete that config and it changed >> nothing anyway. Just wanted to write why in case you wonder.) >> >> gateway$ doas cat /etc/iked.conf >> # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in >> Ashburn. >> ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com >> >> ikev2 "Flow" active \ >> from re1 to tunnel.realconnect.com \ >> from re1 to stats.realconnect.com \ >> from 66.63.44.66 to 0.0.0.0/0 \ >> from 66.63.44.67 to 66.63.0.0/18 \ >> from home.ouellet.us to 0.0.0.0/0 \ >> from 66.63.44.96/28 to 0.0.0.0/0 \ >> from 66.63.44.79 to 43.229.64.0/22 \ >> from 66.63.44.79 to 45.7.36.0/22 \ >> from 66.63.44.79 to 103.240.224.0/22 \ >> from 66.63.44.79 to 104.160.128.0/19 \ >> from 66.63.44.79 to 162.249.72.0/21 \ >> from 66.63.44.79 to 185.40.64.0/22 \ >> from 66.63.44.79 to 192.64.168.0/21 \ >> peer tunnel.realconnect.com >> >> (Here above for the 66.63.44.79, again a weird stuff, that's only for my >> older son. When he play LoL over Fios it suck! But when I tunnel it to >> my tunnel and then directly to Equinix where Riot is and I peer at, all >> is great and hard to believe I am sure, but latency is much lower. Again >> not relevant, just in case you wonder. I know, it's stupid, but I do a >> lots of work from home and I need to keep the family happy too. (;) >> >> On 6/16/20 6:09 AM, Tobias Heider wrote: >>> Hi Daniel, >>> >>> On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote: > Probably related to the following change documented in > https://www.openbsd.org/faq/upgrade67.html: > > iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by > iked(8) or > isakmpd(8) was changed from "use" to "require". This means unencrypted > traffic > matching the flows will no longer be accepted. Flows of type "use" can > still be > set up manually in ipsec.conf(5). I have what appear to be similar problem. I used iked form 5.6 all the way to 6.6 no problem, wel some, but I worked it out. All in archive. But going from 6.6 to 6.7 I can't get it to work anymore. Nothing changed, same configuration, just a sysupgrade and that's it. I read this and I can understand the words, but may be I am think, but I don't understand what to do with it. >>> >>> The default behavior if IPsec flows was changed to not accept unencrypted >>> packets matching a registered flow. >>> You can list your flows with 'ipsecctl -sf'. >> >> gateway$ doas ipsecctl -sf >> flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 43.229.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 45.7.36.0/22 to 66.63.44.79 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 66.63.5.250 to 72.83.103.147 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 103.240.224.0/22 to 66.63.44.79 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow
Re: IKEv2 difference with 6.7
On Tue, Jun 16, 2020 at 01:09:32PM -0400, Daniel Ouellet wrote: > Hi Tobias, > > I put below the full configuration and the flows as well with the 6.6 > binary and switch to the 6.7 binary without any other changes as well as > the full config. > > The config may be a bit weird at first as I tunnel routable IP's over > the iked over a Verizon Fios line. You can't get routable IP's from Fios > and I have needs for it. So that was my way around it for years now. > > Anyway, here below: > > gateway$ doas cat /etc/ipsec.conf > flow esp out from ::/0 to ::/0 type deny > flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass > flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass > flow esp from 66.63.44.67 to 66.63.44.97 type bypass > flow esp from 66.63.44.90 to 66.63.44.97 type bypass > > (This above was to allow the two local subnet to take to one an other as > they are in different dmz. I can delete that config and it changed > nothing anyway. Just wanted to write why in case you wonder.) > > gateway$ doas cat /etc/iked.conf > # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in > Ashburn. > ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com > > ikev2 "Flow" active \ > from re1 to tunnel.realconnect.com \ > from re1 to stats.realconnect.com \ > from 66.63.44.66 to 0.0.0.0/0 \ > from 66.63.44.67 to 66.63.0.0/18 \ > from home.ouellet.us to 0.0.0.0/0 \ > from 66.63.44.96/28 to 0.0.0.0/0 \ > from 66.63.44.79 to 43.229.64.0/22 \ > from 66.63.44.79 to 45.7.36.0/22 \ > from 66.63.44.79 to 103.240.224.0/22 \ > from 66.63.44.79 to 104.160.128.0/19 \ > from 66.63.44.79 to 162.249.72.0/21 \ > from 66.63.44.79 to 185.40.64.0/22 \ > from 66.63.44.79 to 192.64.168.0/21 \ > peer tunnel.realconnect.com > > (Here above for the 66.63.44.79, again a weird stuff, that's only for my > older son. When he play LoL over Fios it suck! But when I tunnel it to > my tunnel and then directly to Equinix where Riot is and I peer at, all > is great and hard to believe I am sure, but latency is much lower. Again > not relevant, just in case you wonder. I know, it's stupid, but I do a > lots of work from home and I need to keep the family happy too. (;) > > On 6/16/20 6:09 AM, Tobias Heider wrote: > > Hi Daniel, > > > > On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote: > >>> Probably related to the following change documented in > >>> https://www.openbsd.org/faq/upgrade67.html: > >>> > >>> iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by > >>> iked(8) or > >>> isakmpd(8) was changed from "use" to "require". This means unencrypted > >>> traffic > >>> matching the flows will no longer be accepted. Flows of type "use" can > >>> still be > >>> set up manually in ipsec.conf(5). > >> > >> I have what appear to be similar problem. I used iked form 5.6 all the > >> way to 6.6 no problem, wel some, but I worked it out. All in archive. > >> > >> But going from 6.6 to 6.7 I can't get it to work anymore. Nothing > >> changed, same configuration, just a sysupgrade and that's it. > >> > >> I read this and I can understand the words, but may be I am think, but I > >> don't understand what to do with it. > > > > The default behavior if IPsec flows was changed to not accept unencrypted > > packets matching a registered flow. > > You can list your flows with 'ipsecctl -sf'. > > gateway$ doas ipsecctl -sf > flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 43.229.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 45.7.36.0/22 to 66.63.44.79 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 66.63.5.250 to 72.83.103.147 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 103.240.224.0/22 to 66.63.44.79 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 104.160.128.0/19 to 66.63.44.79 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid
Re: IKEv2 difference with 6.7
Hi Tobias, I put below the full configuration and the flows as well with the 6.6 binary and switch to the 6.7 binary without any other changes as well as the full config. The config may be a bit weird at first as I tunnel routable IP's over the iked over a Verizon Fios line. You can't get routable IP's from Fios and I have needs for it. So that was my way around it for years now. Anyway, here below: gateway$ doas cat /etc/ipsec.conf flow esp out from ::/0 to ::/0 type deny flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass flow esp from 66.63.44.67 to 66.63.44.97 type bypass flow esp from 66.63.44.90 to 66.63.44.97 type bypass (This above was to allow the two local subnet to take to one an other as they are in different dmz. I can delete that config and it changed nothing anyway. Just wanted to write why in case you wonder.) gateway$ doas cat /etc/iked.conf # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in Ashburn. ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com ikev2 "Flow" active \ from re1 to tunnel.realconnect.com \ from re1 to stats.realconnect.com \ from 66.63.44.66 to 0.0.0.0/0 \ from 66.63.44.67 to 66.63.0.0/18 \ from home.ouellet.us to 0.0.0.0/0 \ from 66.63.44.96/28 to 0.0.0.0/0 \ from 66.63.44.79 to 43.229.64.0/22 \ from 66.63.44.79 to 45.7.36.0/22 \ from 66.63.44.79 to 103.240.224.0/22 \ from 66.63.44.79 to 104.160.128.0/19 \ from 66.63.44.79 to 162.249.72.0/21 \ from 66.63.44.79 to 185.40.64.0/22 \ from 66.63.44.79 to 192.64.168.0/21 \ peer tunnel.realconnect.com (Here above for the 66.63.44.79, again a weird stuff, that's only for my older son. When he play LoL over Fios it suck! But when I tunnel it to my tunnel and then directly to Equinix where Riot is and I peer at, all is great and hard to believe I am sure, but latency is much lower. Again not relevant, just in case you wonder. I know, it's stupid, but I do a lots of work from home and I need to keep the family happy too. (;) On 6/16/20 6:09 AM, Tobias Heider wrote: > Hi Daniel, > > On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote: >>> Probably related to the following change documented in >>> https://www.openbsd.org/faq/upgrade67.html: >>> >>> iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by >>> iked(8) or >>> isakmpd(8) was changed from "use" to "require". This means unencrypted >>> traffic >>> matching the flows will no longer be accepted. Flows of type "use" can >>> still be >>> set up manually in ipsec.conf(5). >> >> I have what appear to be similar problem. I used iked form 5.6 all the >> way to 6.6 no problem, wel some, but I worked it out. All in archive. >> >> But going from 6.6 to 6.7 I can't get it to work anymore. Nothing >> changed, same configuration, just a sysupgrade and that's it. >> >> I read this and I can understand the words, but may be I am think, but I >> don't understand what to do with it. > > The default behavior if IPsec flows was changed to not accept unencrypted > packets matching a registered flow. > You can list your flows with 'ipsecctl -sf'. gateway$ doas ipsecctl -sf flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 43.229.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 45.7.36.0/22 to 66.63.44.79 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.250 to 72.83.103.147 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 103.240.224.0/22 to 66.63.44.79 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 104.160.128.0/19 to 66.63.44.79 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 162.249.72.0/21 to 66.63.44.79 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 185.40.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid
Re: IKEv2 difference with 6.7
Hi, On Tue, Jun 16, 2020 at 03:25:12PM +0200, tris...@pilat.me wrote: > Hi guys, > > First of all, thanks for the amazing work you've done with 6.7! > > That said, I've got the same issue here after I updated to 6.7. The VPN > keeps cutting off every 10 minutes or so. Is there any way I could fix that > ? This sound like a different problem. The unanswered INFORMATIONAL messages are used to check if the peer is still there. After they go unanswered the connection is restarted. May I ask which IKE implementation is running on the peer? You can try https://marc.info/?l=openbsd-misc=159178866010830=2 to see if disabling DPD would actually solve your problem. > > Here's my configuration: > > local_gw="203.0.113.1" > local_network="198.51.100.0/24" > > remote_gw="203.0.113.2" > remote_network="192.0.2.0/26" > remote_network2="192.0.2.64/26" > > ikev2 active esp \ > from $local_gw to $remote_gw \ > from $local_network to $remote_network \ > from $local_network to $remote_network2 \ > peer $remote_gw \ > ikesa enc aes-128 auth hmac-sha1 prf hmac-sha1 group modp1536 \ > childsa auth hmac-sha1 enc aes-128 group modp1536 \ > ikelifetime 86400 lifetime 43200 \ > psk "X" > > That's what I can see in the logs: > > Jun 16 08:07:00 vpn00 iked[31977]: ikev2_init_ike_sa: initiating "policy1" > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: send IKE_SA_INIT > req 0 peer 203.0.113.2:500 local 0.0.0.0:500, 382 bytes > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: recv IKE_SA_INIT > res 0 peer 203.0.113.2:500 local 203.0.113.1:500, 352 bytes, policy > 'policy1' > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: send IKE_AUTH req > 1 peer 203.0.113.2:4500 local 203.0.113.1:4500, 284 bytes, NAT-T > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: recv IKE_AUTH res > 1 peer 203.0.113.2:4500 local 203.0.113.1:4500, 252 bytes, policy 'policy1' > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: > ikev2_childsa_enable: loaded SPIs: 0xae51c8bb, 0x3ab61433 > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: > ikev2_childsa_enable: loaded flows: ESP-198.51.100.0/24=192.0.2.64/26(0), > ESP-198.51.100.0/24=192.0.2.0/26(0), ESP-203.0.113.1/32=203.0.113.2/32(0) > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: established peer > 203.0.113.2:4500[IPV4/203.0.113.2] local > 203.0.113.1:4500[FQDN/vpn00.example.net] policy 'policy1' as initiator > Jun 16 08:12:02 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 1 > INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 > Jun 16 08:12:06 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 2 > INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 > Jun 16 08:12:14 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 3 > INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 > Jun 16 08:12:30 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 4 > INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 > Jun 16 08:13:02 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 5 > INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 > Jun 16 08:14:06 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: sa_free: > retransmit limit reached > Jun 16 08:15:00 vpn00 iked[31977]: ikev2_init_ike_sa: initiating "policy1" > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: send IKE_SA_INIT > req 0 peer 203.0.113.2:500 local 0.0.0.0:500, 382 bytes > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: recv IKE_SA_INIT > res 0 peer 203.0.113.2:500 local 203.0.113.1:500, 352 bytes, policy > 'policy1' > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: send IKE_AUTH req > 1 peer 203.0.113.2:500 local 203.0.113.1:500, 284 bytes > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: recv IKE_AUTH res > 1 peer 203.0.113.2:500 local 203.0.113.1:500, 252 bytes, policy 'policy1' > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: > ikev2_childsa_enable: loaded SPIs: 0xae51c8bd, 0x7009bc39 > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: > ikev2_childsa_enable: loaded flows: ESP-198.51.100.0/24=192.0.2.64/26(0), > ESP-198.51.100.0/24=192.0.2.0/26(0), ESP-203.0.113.1/32=203.0.113.2/32(0) > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: established peer > 203.0.113.2:500[IPV4/203.0.113.2] local > 203.0.113.1:500[FQDN/vpn00.example.net] policy 'policy1' as initiator > Jun 16 08:16:02 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 1 > INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 > Jun 16 08:16:06 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 2 > INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 > Jun 16 08:16:14 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 3 > INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 > Jun 16 08:16:30 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 4 > INFORMATIONAL req 2 peer
Re: IKEv2 difference with 6.7
On Fri, Jun 12, 2020 at 09:27:18PM +0200, Tobias Heider wrote: > On Fri, Jun 12, 2020 at 03:31:56PM +0200, Patrik Ragnarsson wrote: > > Hi, > > > > We have two OpenBSD machines acting as gateways for our network using > > CARP and IPsec (IKEv2). > > > > When the machines were running OpenBSD 6.6, from an IPSec client, you > > were able to reach the passive gateway while being connected to the > > active gateway. On OpenBSD 6.7, it seems this is no longer possible. > > > > The setup looks like this: > > > > - The two servers share using CARP (carp10 > > (carpdev trunk1)) > > - The two servers share 10.200.200.1 using CARP (carp20 (carpdev > > vlan2000)) > > - The active (MASTER) gateway has 10.200.200.2 (vlan2000 (parent trunk0)) > > - The passive (BACKUP) gateway has 10.200.200.3 (vlan2000 (parent trunk0)) > > > > iked.conf looks like this on both machines: > > > > $ cat /etc/iked.conf > > local_endpoint = "" > > roadwarrior_net = "10.100.100.0/24" > > > > ikev2 "roadwarrior-psk" ipcomp esp \ > > from 10.200.200.0/24 to 0.0.0.0/0 \ > > peer any local $local_endpoint \ > > srcid $local_endpoint \ > > psk "" \ > > config address $roadwarrior_net \ > > config netmask 255.255.255.0\ > > tag "$name-$id" > > > > sasyncd.conf from the active gateway: > > > > $ cat /etc/sasyncd.conf > > interface carp10 > > listen on 10.200.200.2 > > peer 10.200.200.3 > > control iked > > sharedkey > > > > sasyncd.conf from the passive gateway: > > > > $ cat /etc/sasyncd.conf > > interface carp10 > > listen on 10.200.200.3 > > peer 10.200.200.2 > > control iked > > sharedkey > > > > The PF rules on both gateways looks like this: > > > > block drop log all > > pass on vlan2000 proto carp all keep state (no-sync) > > pass on trunk1 proto carp all keep state (no-sync) > > pass on vlan2000 all no state > > pass out on trunk1 all flags S/SA > > pass in on trunk1 inet proto tcp from any to (trunk1:0) port = 22 > > flags S/SA keep state (no-sync) > > pass in on trunk1 inet proto udp from any to (trunk1:0) port > > 6:61000 keep state (no-sync) > > pass out on trunk1:0 all flags S/SA keep state (no-sync) > > pass in on trunk1 inet proto icmp all > > block return in on trunk1 proto udp from any to any port 33434:33534 > > pass out on trunk1 from (vlan2000:network) to any flags S/SA > > nat-to (carp10:0) > > pass in on trunk1 inet proto udp from any to port > > = 500 > > pass in on trunk1 inet proto udp from any to > > port = 4500 > > pass out on trunk1 inet proto udp from to any > > port = 500 > > pass out on trunk1 inet proto udp from to any > > port = 4500 > > pass in on trunk1 inet proto esp from any to > > pass out on trunk1 inet proto esp from to any > > pass in on enc0 inet from 10.100.100.0/24 to 10.200.200.0/24 flags > > S/SA keep state (if-bound) > > pass in on enc0 inet proto ipencap from any to > IP> keep state (if-bound) > > pass out on enc0 inet from 10.200.200.0/24 to 10.100.100.0/24 > > flags S/SA keep state (if-bound) > > pass out on enc0 inet proto ipencap from to > > any keep state (if-bound) > > > > On both gateways, I can see that the same flows and SAs have been > > created after the client have connected to the VPN. (ipsecctl -s all) > > > > A client (macOS) can reach 10.200.200.1 and 10.200.200.2 (and other > > servers in 10.200.200.0/24) but not 10.200.200.3: > > > > $ ping -c5 10.200.200.3 > > PING 10.200.200.3 (10.200.200.3): 56 data bytes > > Request timeout for icmp_seq 0 > > Request timeout for icmp_seq 1 > > Request timeout for icmp_seq 2 > > Request timeout for icmp_seq 3 > > > > --- 10.200.200.3 ping statistics --- > > 5 packets transmitted, 0 packets received, 100.0% packet loss > > > > I can see the ICMP echo requests reach the vlan2000 interface on the > > passive gateway (tcpdump -netti vlan2000 icmp) > > > > 1591718254.738903 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > 1591718255.740275 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > 1591718256.740455 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > 1591718257.743593 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > > > Running iked in the foreground (iked -dv) on the passive gateway, I > > can see the following when I try to ping 10.200.200.3 from the client: > > > > pfkey_process: acquire request (peer ) > > pfkey_process: flow in from 10.200.200.0/255.255.255.0 to > > 10.100.100.173/255.255.255.255 via > > ikev2_acquire_sa: flow wasn't found > > > > I've also tried disabling PF on the
Re: IKEv2 difference with 6.7
Hi Daniel, On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote: > > Probably related to the following change documented in > > https://www.openbsd.org/faq/upgrade67.html: > > > > iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by > > iked(8) or > > isakmpd(8) was changed from "use" to "require". This means unencrypted > > traffic > > matching the flows will no longer be accepted. Flows of type "use" can > > still be > > set up manually in ipsec.conf(5). > > I have what appear to be similar problem. I used iked form 5.6 all the > way to 6.6 no problem, wel some, but I worked it out. All in archive. > > But going from 6.6 to 6.7 I can't get it to work anymore. Nothing > changed, same configuration, just a sysupgrade and that's it. > > I read this and I can understand the words, but may be I am think, but I > don't understand what to do with it. The default behavior if IPsec flows was changed to not accept unencrypted packets matching a registered flow. You can list your flows with 'ipsecctl -sf'. > > I see the require type modifier in ipsec.conf man page, not into > iked.conf man page. > > Do you mean what ever rules we had in iked.conf needs to be in > ipsec.conf now? No, that won't work. > > I am really sorry if I don't follow the meaning or what you tried to > say, but how can this be fix, or changed? > To help you I will need to know a bit more about your setup. In particular the architecture of your network, your iked.conf and the output of 'ipsecctl -sa' would be helpful. A more detailed description of what exactly does not work would also help. > My guess is that it is simple and I don't think about it properly, but I > am hitting a road block trying to figure it out. > > I am a bit at a lost and any clue stick would be greatly appreciated. > > Thanks > > Daniel > - Tobias
Re: IKEv2 difference with 6.7
> Probably related to the following change documented in > https://www.openbsd.org/faq/upgrade67.html: > > iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by iked(8) > or > isakmpd(8) was changed from "use" to "require". This means unencrypted traffic > matching the flows will no longer be accepted. Flows of type "use" can still > be > set up manually in ipsec.conf(5). I have what appear to be similar problem. I used iked form 5.6 all the way to 6.6 no problem, wel some, but I worked it out. All in archive. But going from 6.6 to 6.7 I can't get it to work anymore. Nothing changed, same configuration, just a sysupgrade and that's it. I read this and I can understand the words, but may be I am think, but I don't understand what to do with it. I see the require type modifier in ipsec.conf man page, not into iked.conf man page. Do you mean what ever rules we had in iked.conf needs to be in ipsec.conf now? I am really sorry if I don't follow the meaning or what you tried to say, but how can this be fix, or changed? My guess is that it is simple and I don't think about it properly, but I am hitting a road block trying to figure it out. I am a bit at a lost and any clue stick would be greatly appreciated. Thanks Daniel
Re: IKEv2 difference with 6.7
On 6/15/20 8:04 PM, Daniel Ouellet wrote: >> Probably related to the following change documented in >> https://www.openbsd.org/faq/upgrade67.html: >> >> iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by iked(8) >> or >> isakmpd(8) was changed from "use" to "require". This means unencrypted >> traffic >> matching the flows will no longer be accepted. Flows of type "use" can still >> be >> set up manually in ipsec.conf(5). > > I have what appear to be similar problem. I used iked form 5.6 all the > way to 6.6 no problem, wel some, but I worked it out. All in archive. > > But going from 6.6 to 6.7 I can't get it to work anymore. Nothing > changed, same configuration, just a sysupgrade and that's it. > > I read this and I can understand the words, but may be I am think, but I > don't understand what to do with it. > > I see the require type modifier in ipsec.conf man page, not into > iked.conf man page. > > Do you mean what ever rules we had in iked.conf needs to be in > ipsec.conf now? > > I am really sorry if I don't follow the meaning or what you tried to > say, but how can this be fix, or changed? > > My guess is that it is simple and I don't think about it properly, but I > am hitting a road block trying to figure it out. > > I am a bit at a lost and any clue stick would be greatly appreciated. > > Thanks > > Daniel Just for the records, I just took a copy of iked version 6.6 and used that instead of 6.7 and all is good. I saved the 6.7 version. gateway# ls -al /sbin/iked* -r-xr-xr-x 1 root bin 436584 Jun 15 20:42 /sbin/iked -r-xr-xr-x 1 root bin 448744 May 7 12:52 /sbin/iked.original So it's definitely nothing else that is stopping it from working. Just a new requirement for iked to use this new way and so far I am coming short as to how to get this done right.
Re: IKEv2 difference with 6.7
On Fri, Jun 12, 2020 at 03:31:56PM +0200, Patrik Ragnarsson wrote: > Hi, > > We have two OpenBSD machines acting as gateways for our network using > CARP and IPsec (IKEv2). > > When the machines were running OpenBSD 6.6, from an IPSec client, you > were able to reach the passive gateway while being connected to the > active gateway. On OpenBSD 6.7, it seems this is no longer possible. > > The setup looks like this: > > - The two servers share using CARP (carp10 > (carpdev trunk1)) > - The two servers share 10.200.200.1 using CARP (carp20 (carpdev vlan2000)) > - The active (MASTER) gateway has 10.200.200.2 (vlan2000 (parent trunk0)) > - The passive (BACKUP) gateway has 10.200.200.3 (vlan2000 (parent trunk0)) > > iked.conf looks like this on both machines: > > $ cat /etc/iked.conf > local_endpoint = "" > roadwarrior_net = "10.100.100.0/24" > > ikev2 "roadwarrior-psk" ipcomp esp \ > from 10.200.200.0/24 to 0.0.0.0/0 \ > peer any local $local_endpoint \ > srcid $local_endpoint \ > psk "" \ > config address $roadwarrior_net \ > config netmask 255.255.255.0\ > tag "$name-$id" > > sasyncd.conf from the active gateway: > > $ cat /etc/sasyncd.conf > interface carp10 > listen on 10.200.200.2 > peer 10.200.200.3 > control iked > sharedkey > > sasyncd.conf from the passive gateway: > > $ cat /etc/sasyncd.conf > interface carp10 > listen on 10.200.200.3 > peer 10.200.200.2 > control iked > sharedkey > > The PF rules on both gateways looks like this: > > block drop log all > pass on vlan2000 proto carp all keep state (no-sync) > pass on trunk1 proto carp all keep state (no-sync) > pass on vlan2000 all no state > pass out on trunk1 all flags S/SA > pass in on trunk1 inet proto tcp from any to (trunk1:0) port = 22 > flags S/SA keep state (no-sync) > pass in on trunk1 inet proto udp from any to (trunk1:0) port > 6:61000 keep state (no-sync) > pass out on trunk1:0 all flags S/SA keep state (no-sync) > pass in on trunk1 inet proto icmp all > block return in on trunk1 proto udp from any to any port 33434:33534 > pass out on trunk1 from (vlan2000:network) to any flags S/SA > nat-to (carp10:0) > pass in on trunk1 inet proto udp from any to port = > 500 > pass in on trunk1 inet proto udp from any to > port = 4500 > pass out on trunk1 inet proto udp from to any > port = 500 > pass out on trunk1 inet proto udp from to any > port = 4500 > pass in on trunk1 inet proto esp from any to > pass out on trunk1 inet proto esp from to any > pass in on enc0 inet from 10.100.100.0/24 to 10.200.200.0/24 flags > S/SA keep state (if-bound) > pass in on enc0 inet proto ipencap from any to IP> keep state (if-bound) > pass out on enc0 inet from 10.200.200.0/24 to 10.100.100.0/24 > flags S/SA keep state (if-bound) > pass out on enc0 inet proto ipencap from to > any keep state (if-bound) > > On both gateways, I can see that the same flows and SAs have been > created after the client have connected to the VPN. (ipsecctl -s all) > > A client (macOS) can reach 10.200.200.1 and 10.200.200.2 (and other > servers in 10.200.200.0/24) but not 10.200.200.3: > > $ ping -c5 10.200.200.3 > PING 10.200.200.3 (10.200.200.3): 56 data bytes > Request timeout for icmp_seq 0 > Request timeout for icmp_seq 1 > Request timeout for icmp_seq 2 > Request timeout for icmp_seq 3 > > --- 10.200.200.3 ping statistics --- > 5 packets transmitted, 0 packets received, 100.0% packet loss > > I can see the ICMP echo requests reach the vlan2000 interface on the > passive gateway (tcpdump -netti vlan2000 icmp) > > 1591718254.738903 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > 10.100.100.173 > 10.200.200.3: icmp: echo request > 1591718255.740275 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > 10.100.100.173 > 10.200.200.3: icmp: echo request > 1591718256.740455 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > 10.100.100.173 > 10.200.200.3: icmp: echo request > 1591718257.743593 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > 10.100.100.173 > 10.200.200.3: icmp: echo request > > Running iked in the foreground (iked -dv) on the passive gateway, I > can see the following when I try to ping 10.200.200.3 from the client: > > pfkey_process: acquire request (peer ) > pfkey_process: flow in from 10.200.200.0/255.255.255.0 to > 10.100.100.173/255.255.255.255 via > ikev2_acquire_sa: flow wasn't found > > I've also tried disabling PF on the passive gateway, I still couldn't > reach 10.200.200.3. > > Appreciate it if anyone has any ideas of what's going on. > > Thanks! Probably related to the following change documented in https://www.openbsd.org/faq/upgrade67.html: iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by iked(8) or
IKEv2 difference with 6.7
Hi, We have two OpenBSD machines acting as gateways for our network using CARP and IPsec (IKEv2). When the machines were running OpenBSD 6.6, from an IPSec client, you were able to reach the passive gateway while being connected to the active gateway. On OpenBSD 6.7, it seems this is no longer possible. The setup looks like this: - The two servers share using CARP (carp10 (carpdev trunk1)) - The two servers share 10.200.200.1 using CARP (carp20 (carpdev vlan2000)) - The active (MASTER) gateway has 10.200.200.2 (vlan2000 (parent trunk0)) - The passive (BACKUP) gateway has 10.200.200.3 (vlan2000 (parent trunk0)) iked.conf looks like this on both machines: $ cat /etc/iked.conf local_endpoint = "" roadwarrior_net = "10.100.100.0/24" ikev2 "roadwarrior-psk" ipcomp esp \ from 10.200.200.0/24 to 0.0.0.0/0 \ peer any local $local_endpoint \ srcid $local_endpoint \ psk "" \ config address $roadwarrior_net \ config netmask 255.255.255.0\ tag "$name-$id" sasyncd.conf from the active gateway: $ cat /etc/sasyncd.conf interface carp10 listen on 10.200.200.2 peer 10.200.200.3 control iked sharedkey sasyncd.conf from the passive gateway: $ cat /etc/sasyncd.conf interface carp10 listen on 10.200.200.3 peer 10.200.200.2 control iked sharedkey The PF rules on both gateways looks like this: block drop log all pass on vlan2000 proto carp all keep state (no-sync) pass on trunk1 proto carp all keep state (no-sync) pass on vlan2000 all no state pass out on trunk1 all flags S/SA pass in on trunk1 inet proto tcp from any to (trunk1:0) port = 22 flags S/SA keep state (no-sync) pass in on trunk1 inet proto udp from any to (trunk1:0) port 6:61000 keep state (no-sync) pass out on trunk1:0 all flags S/SA keep state (no-sync) pass in on trunk1 inet proto icmp all block return in on trunk1 proto udp from any to any port 33434:33534 pass out on trunk1 from (vlan2000:network) to any flags S/SA nat-to (carp10:0) pass in on trunk1 inet proto udp from any to port = 500 pass in on trunk1 inet proto udp from any to port = 4500 pass out on trunk1 inet proto udp from to any port = 500 pass out on trunk1 inet proto udp from to any port = 4500 pass in on trunk1 inet proto esp from any to pass out on trunk1 inet proto esp from to any pass in on enc0 inet from 10.100.100.0/24 to 10.200.200.0/24 flags S/SA keep state (if-bound) pass in on enc0 inet proto ipencap from any to keep state (if-bound) pass out on enc0 inet from 10.200.200.0/24 to 10.100.100.0/24 flags S/SA keep state (if-bound) pass out on enc0 inet proto ipencap from to any keep state (if-bound) On both gateways, I can see that the same flows and SAs have been created after the client have connected to the VPN. (ipsecctl -s all) A client (macOS) can reach 10.200.200.1 and 10.200.200.2 (and other servers in 10.200.200.0/24) but not 10.200.200.3: $ ping -c5 10.200.200.3 PING 10.200.200.3 (10.200.200.3): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 --- 10.200.200.3 ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss I can see the ICMP echo requests reach the vlan2000 interface on the passive gateway (tcpdump -netti vlan2000 icmp) 1591718254.738903 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request 1591718255.740275 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request 1591718256.740455 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request 1591718257.743593 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request Running iked in the foreground (iked -dv) on the passive gateway, I can see the following when I try to ping 10.200.200.3 from the client: pfkey_process: acquire request (peer ) pfkey_process: flow in from 10.200.200.0/255.255.255.0 to 10.100.100.173/255.255.255.255 via ikev2_acquire_sa: flow wasn't found I've also tried disabling PF on the passive gateway, I still couldn't reach 10.200.200.3. Appreciate it if anyone has any ideas of what's going on. Thanks!
