Re: isakmpd does not tag packets

[Tobias Heider]

On Tue, Dec 12, 2023 at 07:38:30AM +0100, Sebastian John wrote:
> Hello,
> 
> I installed (not upgrade) OpenBSD 7.4 (amd64) on a brand new
> machine. I put the isakmpd.conf from the old maschine (7.3) on the
> new one. Also some other configurations (interfaces, pf...). All
> works fine but the incomming IPSec packets are not tagged anymore. 
> 
> [.. isakmpd.conf ..]
> PF-Tag= IPSEC_FOOBAR
> [..]
> 
> [.. pf.conf ..]
> pass out quick on em0 inet tagged IPSEC_FOOBAR
> [..]
> 
> On the 7.3 maschine this works. Since OpenBSD 7.4 this does not work
> anymore. I didn't find any information in the upgrade instructions.
> There are a known bug? Or any other ideas?

Thanks for the report.

It looks like this was broken when we added sec(4) support in 7.4.
I just committed a fix.

> 
> Sebastian
> 
> 
> 
> -- 
> 

Re: Iked between OpenBSD and Linux (raspberry pi)

[Tobias Heider]

> > > ikev2 "LINUX-CLIENT_INET4_LAN" passive esp \
> > >   from 10.88.0.0/22 to 10.88.12.0/24 \
> > >   from 203.0.113.92 to 10.88.12.0/24 \
> > >   peer any local 203.0.113.92 \
> > >   ikesa enc aes-256-gcm-12 prf hmac-sha2-512 group ecp521 \
> > >childsa enc aes-256-gcm prf hmac-sha2-512 group ecp521 \
> > >   srcid openbsd-server.example.com dstid linux-client.example.com \
> > >   lifetime 3600 bytes 1G \
> > >   psk "123123123" \
> > >   tag "$name-$id"
> > > 
> > > Updated client configuration
> > > 
> > > ikev2 "OPENBSD-SERVER_INET4_NETS" active esp \
> > >   from 10.88.12.0/24 to 10.88.0.0/22 \
> > >   from 10.88.12.0/24 to 203.0.113.92 \
> > >   peer openbsd-server.example.com \
> > >   ikesa enc aes-256-gcm-12 prf hmac-sha2-512 group ecp521 \
> > >childsa enc aes-256-gcm prf hmac-sha2-512 group ecp521 \
> > >   srcid linux-client.example.com dstid openbsd-server.example.com \
> > >   lifetime 3600 bytes 1G \
> > >   psk "123123123" \
> > >   tag "$name-$id"
> 
> Does it work if you remove the second "from ... to" line? It looks like the SA
> payload is malformed, so the flows are the most likely cause.

No that is probably not it.

> > > ikev2_next_payload: length 72 nextpayload SA
> > > ikev2_add_proposals: length 0

This suggests that it might be the "childsa" option . What happens if you
use the default for that on both machines?

Re: Iked between OpenBSD and Linux (raspberry pi)

[Tobias Heider]

On Tue, Oct 24, 2023 at 10:42:11PM +0200, Tobias Heider wrote:
> On Tue, Oct 24, 2023 at 03:35:57PM -0500, rea...@catastrophe.net wrote:
> > On Tue, Oct 24, 2023 at 03:06:41PM -0500, rea...@catastrophe.net wrote:
> > [..]
> > >$ uname -a
> > >OpenBSD openbsd-server 7.4 GENERIC#1336 amd64
> > >
> > >ikev2 "LINUX-CLIENT_INET4_LAN" passive esp \
> > >  from 10.88.0.0/22 to 10.88.12.0/24 \
> > >  from 203.0.113.92 to 10.88.12.0/24 \
> > >  peer any local openbsd-server.example.com \
> > >  ikesa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
> > >   childsa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
> > >  srcid openbsd-server.example.com dstid linux-client.example.com \
> > >  ikelifetime 4h \
> > >  psk "123123123" \
> > >  tag "$name-$id"
> > >
> > >Client configuration
> > >
> > ># uname -a
> > >Linux linux-client 6.1.14-v7+ #1633 SMP Thu Mar  2 11:02:03 GMT 2023 
> > >armv7l GNU/Linux
> > >
> > >ikev2 "OPENBSD-SERVER_INET4_NETS" active esp \
> > >  from 10.88.12.0/24 to 10.88.0.0/22 \
> > >  from 10.88.12.0/24 to 203.0.113.92 \
> > >  peer 203.0.113.92 \
> > >  ikesa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
> > >   childsa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
> > >  srcid openbsd-server.example.com dstid linux-client.example.com \
> > >  ikelifetime 4h \
> > >  psk "123123123" \
> > >  tag "$name-$id"
> 
> One thing that is clearly wrong are the IDs. The client should probably use:
> 
>srcid linux-client.example.com dstid openbsd-server.example.com \

urgh just saw that you already fixed that.

> 
> > 
> > 
> > So some of these were a bit backwards. I fixed the configurations but am 
> > now seeing the following on the server side:
> > 
> > Oct 24 15:22:10 openbsd-server iked[12052]: spi=0x84023eb6ab6a9d33: 
> > ikev2_resp_recv: failed to parse message
> > 
> > Updated server configuration
> > 
> > ikev2 "LINUX-CLIENT_INET4_LAN" passive esp \
> >   from 10.88.0.0/22 to 10.88.12.0/24 \
> >   from 203.0.113.92 to 10.88.12.0/24 \
> >   peer any local 203.0.113.92 \
> >   ikesa enc aes-256-gcm-12 prf hmac-sha2-512 group ecp521 \
> >childsa enc aes-256-gcm prf hmac-sha2-512 group ecp521 \
> >   srcid openbsd-server.example.com dstid linux-client.example.com \
> >   lifetime 3600 bytes 1G \
> >   psk "123123123" \
> >   tag "$name-$id"
> > 
> > Updated client configuration
> > 
> > ikev2 "OPENBSD-SERVER_INET4_NETS" active esp \
> >   from 10.88.12.0/24 to 10.88.0.0/22 \
> >   from 10.88.12.0/24 to 203.0.113.92 \
> >   peer openbsd-server.example.com \
> >   ikesa enc aes-256-gcm-12 prf hmac-sha2-512 group ecp521 \
> >childsa enc aes-256-gcm prf hmac-sha2-512 group ecp521 \
> >   srcid linux-client.example.com dstid openbsd-server.example.com \
> >   lifetime 3600 bytes 1G \
> >   psk "123123123" \
> >   tag "$name-$id"

Does it work if you remove the second "from ... to" line? It looks like the SA
payload is malformed, so the flows are the most likely cause.

> > 
> > 
> > Full logs are below
> > 
> > Server Logs
> > 
> > # iked -dvv
> > policy_lookup: setting policy 'LINUX-CLIENT_INET4_LAN'
> > spi=0xb825bd62181aa707: recv IKE_SA_INIT req 0 peer 192.0.51.245:23804
> > local 203.0.113.92:500, 330 bytes, policy 'LINUX-CLIENT_INET4_LAN'
> > ikev2_recv: ispi 0xb825bd62181aa707 rspi 0x
> > ikev2_policy2id: srcid FQDN/openbsd-server.example.com length 23
> > ikev2_pld_parse: header ispi 0xb825bd62181aa707 rspi 0x
> > nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length
> > 330 response 0
> > ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 40
> > ikev2_pld_sa: more 0 reserved 0 length 36 proposal #1 protoid IKE spisize 0
> > xforms 3 spi 0
> > ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_GCM_12
> > ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
> > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_521
> > ikev2_pld_xform: more 0 reserved 0 length 8 type PRF id HMAC_SHA2_512
> > ikev2_pld_payloads: payload KE nextpayload NONCE critical 0x00 length 140
> > ikev2_pld_ke: dh group ECP_521 reserved 0
> > ikev2_pld_payloads: payload NONCE nextpayloa

Re: Iked between OpenBSD and Linux (raspberry pi)

[Tobias Heider]

On Tue, Oct 24, 2023 at 03:35:57PM -0500, rea...@catastrophe.net wrote:
> On Tue, Oct 24, 2023 at 03:06:41PM -0500, rea...@catastrophe.net wrote:
> [..]
> >$ uname -a
> >OpenBSD openbsd-server 7.4 GENERIC#1336 amd64
> >
> >ikev2 "LINUX-CLIENT_INET4_LAN" passive esp \
> >  from 10.88.0.0/22 to 10.88.12.0/24 \
> >  from 203.0.113.92 to 10.88.12.0/24 \
> >  peer any local openbsd-server.example.com \
> >  ikesa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
> >   childsa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
> >  srcid openbsd-server.example.com dstid linux-client.example.com \
> >  ikelifetime 4h \
> >  psk "123123123" \
> >  tag "$name-$id"
> >
> >Client configuration
> >
> ># uname -a
> >Linux linux-client 6.1.14-v7+ #1633 SMP Thu Mar  2 11:02:03 GMT 2023 armv7l 
> >GNU/Linux
> >
> >ikev2 "OPENBSD-SERVER_INET4_NETS" active esp \
> >  from 10.88.12.0/24 to 10.88.0.0/22 \
> >  from 10.88.12.0/24 to 203.0.113.92 \
> >  peer 203.0.113.92 \
> >  ikesa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
> >   childsa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
> >  srcid openbsd-server.example.com dstid linux-client.example.com \
> >  ikelifetime 4h \
> >  psk "123123123" \
> >  tag "$name-$id"

One thing that is clearly wrong are the IDs. The client should probably use:

   srcid linux-client.example.com dstid openbsd-server.example.com \

> 
> 
> So some of these were a bit backwards. I fixed the configurations but am 
> now seeing the following on the server side:
> 
> Oct 24 15:22:10 openbsd-server iked[12052]: spi=0x84023eb6ab6a9d33: 
> ikev2_resp_recv: failed to parse message
> 
> Updated server configuration
> 
> ikev2 "LINUX-CLIENT_INET4_LAN" passive esp \
>   from 10.88.0.0/22 to 10.88.12.0/24 \
>   from 203.0.113.92 to 10.88.12.0/24 \
>   peer any local 203.0.113.92 \
>   ikesa enc aes-256-gcm-12 prf hmac-sha2-512 group ecp521 \
>childsa enc aes-256-gcm prf hmac-sha2-512 group ecp521 \
>   srcid openbsd-server.example.com dstid linux-client.example.com \
>   lifetime 3600 bytes 1G \
>   psk "123123123" \
>   tag "$name-$id"
> 
> Updated client configuration
> 
> ikev2 "OPENBSD-SERVER_INET4_NETS" active esp \
>   from 10.88.12.0/24 to 10.88.0.0/22 \
>   from 10.88.12.0/24 to 203.0.113.92 \
>   peer openbsd-server.example.com \
>   ikesa enc aes-256-gcm-12 prf hmac-sha2-512 group ecp521 \
>childsa enc aes-256-gcm prf hmac-sha2-512 group ecp521 \
>   srcid linux-client.example.com dstid openbsd-server.example.com \
>   lifetime 3600 bytes 1G \
>   psk "123123123" \
>   tag "$name-$id"
> 
> 
> Full logs are below
> 
> Server Logs
> 
> # iked -dvv
> policy_lookup: setting policy 'LINUX-CLIENT_INET4_LAN'
> spi=0xb825bd62181aa707: recv IKE_SA_INIT req 0 peer 192.0.51.245:23804
> local 203.0.113.92:500, 330 bytes, policy 'LINUX-CLIENT_INET4_LAN'
> ikev2_recv: ispi 0xb825bd62181aa707 rspi 0x
> ikev2_policy2id: srcid FQDN/openbsd-server.example.com length 23
> ikev2_pld_parse: header ispi 0xb825bd62181aa707 rspi 0x
> nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length
> 330 response 0
> ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 40
> ikev2_pld_sa: more 0 reserved 0 length 36 proposal #1 protoid IKE spisize 0
> xforms 3 spi 0
> ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_GCM_12
> ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
> ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_521
> ikev2_pld_xform: more 0 reserved 0 length 8 type PRF id HMAC_SHA2_512
> ikev2_pld_payloads: payload KE nextpayload NONCE critical 0x00 length 140
> ikev2_pld_ke: dh group ECP_521 reserved 0
> ikev2_pld_payloads: payload NONCE nextpayload VENDOR critical 0x00 length 36
> ikev2_pld_payloads: payload VENDOR nextpayload NOTIFY critical 0x00 length
> 16
> ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length
> 28
> ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_SOURCE_IP
> ikev2_nat_detection: peer source 0xb825bd62181aa707 0x
> 192.0.51.245:23804
> ikev2_pld_notify: NAT_DETECTION_SOURCE_IP detected NAT
> ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length
> 28
> ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_DESTINATION_IP
> ikev2_nat_detection: peer destination 0xb825bd62181aa707 0x
> 203.0.113.92:500
> ikev2_pld_payloads: payload NOTIFY nextpayload NONE critical 0x00 length 14
> ikev2_pld_notify: protoid NONE spisize 0 type SIGNATURE_HASH_ALGORITHMS
> ikev2_pld_notify: signature hash SHA2_256 (2)
> ikev2_pld_notify: signature hash SHA2_384 (3)
> ikev2_pld_notify: signature hash SHA2_512 (4)
> proposals_negotiate: score 3
> proposals_negotiate: score 0
> proposals_negotiate: score 0
> proposals_negotiate: score 0
> proposals_negotiate: score 0
> proposals_negotiate: score 0
> proposals_negotiate: score 0
> proposals_negotiate: score 3
> 

Re: Iked between OpenBSD and Linux (raspberry pi)

[Tobias Heider]

Hi,

On Tue, Oct 24, 2023 at 03:06:41PM -0500, rea...@catastrophe.net wrote:
> I have a small raspberry pi device that I'd like to connect to a 7.4
> machine with iked(8) and PSK auth, to start. The rpi device is going 
> to be on a mobile network and behind a small NAT device. 
> 
> I haven't had any problem with the following configurations between 
> two OpenBSD devices, but the rpi fails to connect with a similar config.
> 
> Has anyone gotten a rpi connected to a 7.4 (or whatever other version 
> running iked(8)) with the available OpenIKED package?
> 
> Thanks for any help in advance.

Can you add verbose server logs too? I don't see any obvious incompatibility.

- Tobias

> 
> 
> Server configuration
> 
> $ uname -a
> OpenBSD openbsd-server 7.4 GENERIC#1336 amd64
> 
> ikev2 "LINUX-CLIENT_INET4_LAN" passive esp \
>   from 10.88.0.0/22 to 10.88.12.0/24 \
>   from 203.0.113.92 to 10.88.12.0/24 \
>   peer any local openbsd-server.example.com \
>   ikesa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
>childsa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
>   srcid openbsd-server.example.com dstid linux-client.example.com \
>   ikelifetime 4h \
>   psk "123123123" \
>   tag "$name-$id"
> 
> Client configuration
> 
> # uname -a
> Linux linux-client 6.1.14-v7+ #1633 SMP Thu Mar  2 11:02:03 GMT 2023 armv7l 
> GNU/Linux
> 
> ikev2 "OPENBSD-SERVER_INET4_NETS" active esp \
>   from 10.88.12.0/24 to 10.88.0.0/22 \
>   from 10.88.12.0/24 to 203.0.113.92 \
>   peer 203.0.113.92 \
>   ikesa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
>childsa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group ecp521 \
>   srcid openbsd-server.example.com dstid linux-client.example.com \
>   ikelifetime 4h \
>   psk "123123123" \
>   tag "$name-$id"
> 
> 
> Server logs
> 
> openbsd-server# tail /var/log/daemon
> Oct 24 14:46:14 obsd-server iked[6925]: spi=0x55dc1e4f08b3ac60: recv 
> IKE_SA_INIT req 0 peer 192.0.51.213:59458 local 203.0.113.92:500, 338 bytes, 
> policy 'LINUX-CLIENT_INET4_LAN'
> Oct 24 14:46:14 obsd-server iked[6925]: spi=0x55dc1e4f08b3ac60: send 
> IKE_SA_INIT res 0 peer 192.0.51.213:59458 local 203.0.113.92:500, 338 bytes
> Oct 24 14:46:14 obsd-server iked[6925]: spi=0x55dc1e4f08b3ac60: recv IKE_AUTH 
> req 1 peer 192.0.51.213:54016 local 203.0.113.92:4500, 320 bytes, policy 
> 'LINUX-CLIENT_INET4_LAN'
> Oct 24 14:46:14 obsd-server iked[6925]: spi=0x55dc1e4f08b3ac60: 
> ikev2_ike_auth_recv: no compatible policy found
> Oct 24 14:46:14 obsd-server iked[6925]: spi=0x55dc1e4f08b3ac60: 
> ikev2_send_auth_failed: authentication failed for
> Oct 24 14:46:14 obsd-server iked[6925]: spi=0x55dc1e4f08b3ac60: send IKE_AUTH 
> res 1 peer 192.0.51.213:54016 local 203.0.113.92:4500, 96 bytes, NAT-T
> Oct 24 14:46:14 obsd-server iked[6925]: spi=0x55dc1e4f08b3ac60: sa_free: 
> authentication failed
> 
> Client logs
> 
> linux-client# iked -ddvv
> create_ike: using unknown for peer linux-client.example.com
> ikev2 "OPENBSD-SERVER_INET4_NETS" active tunnel esp inet from 10.88.12.0/24 
> to 10.88.0.0/22 from 10.88.12.0/24 to 203.0.113.92 local any peer 
> 203.0.113.92 ikesa enc aes-256 prf hmac-sha2-512 auth hmac-sha2-512 group 
> ecp521 childsa enc aes-256 auth hmac-sha2-512 group ecp521 noesn srcid 
> openbsd-server.example.com dstid linux-client.example.com ikelifetime 14400 
> lifetime 10800 bytes 4294967296 psk 
> 0x746869732d69732d612d6c6f6e672d746573742d70772d39 tag "$name-$id"
> /etc/iked.conf: loaded 1 configuration rules
> ca_privkey_serialize: type ECDSA length 121
> ca_pubkey_serialize: type ECDSA length 91
> config_getpolicy: received policy
> config_getpfkey: received pfkey fd 3
> ca_privkey_to_method: type ECDSA method ECDSA_256
> ca_getkey: received private key type ECDSA length 121
> ca_getkey: received public key type ECDSA length 91
> ca_dispatch_parent: config reset
> ca_reload: local cert type ECDSA
> config_getocsp: ocsp_url none tolerate 0 maxage -1
> ikev2_dispatch_cert: updated local CERTREQ type ECDSA length 0
> 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_getstatic: dpd_check_interval 60
> config_getstatic: no enforcesingleikesa
> config_getstatic: no fragmentation
> config_getstatic: mobike
> config_getstatic: nattport 4500
> config_getstatic: no stickyaddress
> ikev2_init_ike_sa: initiating "OPENBSD-SERVER_INET4_NETS"
> ikev2_policy2id: srcid FQDN/openbsd-server.example.com length 23
> ikev2_add_proposals: length 44
> ikev2_next_payload: length 48 nextpayload KE
> ikev2_next_payload: length 140 nextpayload NONCE
> ikev2_next_payload: length 36 nextpayload VENDOR
> ikev2_next_payload: length 16 nextpayload NOTIFY
> ikev2_nat_detection: local source 0x55dc1e4f08b3ac60 0x 
> 0.0.0.0:500
> ikev2_next_payload: length 28 nextpayload NOTIFY
> ikev2_nat_detection: local 

Re: host-to-host encryption with iked

[Tobias Heider]

On October 3, 2023 2:30:54 PM GMT+02:00, "Robert B. Carleton" 
 wrote:
>Tobias Heider  writes:
>
>> On October 3, 2023 1:32:39 AM GMT+02:00, "Robert B. Carleton" 
>>  wrote:
>>>I'm trying to setup host-to-host encryption using iked with the
>>>following configuration:
>>>
>>>On 10.2.2.10:
>>>
>>>ikev2 passive esp from 10.2.2.10 to 10.2.1.11 srcid 10.2.2.10
>>>
>>>On 10.2.1.11:
>>>
>>>ikev2 active esp from 10.2.1.11 to 10.2.2.10 srcid 10.2.1.11
>>>
>>>I exchanged the /etc/iked/local.pub files into /etc/iked/pubkeys/ipv4/
>>>on each host using the respective IPs as the file names.
>>>
>>>When I start iked, it responds agreeably:
>>>
>>>On 10.2.2.10:
>>>
>>># iked -dv 
>>>ikev2 "policy1" passive tunnel esp inet from 10.2.2.10 to 10.2.1.11 local 
>>>10.2.2.10 peer 10.2.1.11 ikesa enc aes-128-gcm enc aes-256-gcm prf 
>>>hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group 
>>>curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group 
>>>modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc 
>>>aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf 
>>>hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth 
>>>hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 
>>>group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 
>>>group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn 
>>>childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth 
>>>hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 
>>>10.2.2.10 lifetime 10800 bytes 4294967296 signature
>>>spi=0xe0fd27448726d995: recv IKE_SA_INIT req 0 peer 10.2.1.11:500 local 
>>>10.2.2.10:500, 518 bytes, policy 'policy1'
>>>spi=0xe0fd27448726d995: send IKE_SA_INIT res 0 peer 10.2.1.11:500 local 
>>>10.2.2.10:500, 235 bytes
>>>spi=0xe0fd27448726d995: recv IKE_AUTH req 1 peer 10.2.1.11:500 local 
>>>10.2.2.10:500, 463 bytes, policy 'policy1'
>>>spi=0xe0fd27448726d995: send IKE_AUTH res 1 peer 10.2.1.11:500 local 
>>>10.2.2.10:500, 342 bytes
>>>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, 
>>>0xd94b3836 (enc aes-128-gcm esn)
>>>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: 
>>>ESP-10.2.2.10/32=10.2.1.11/32(0)
>>>spi=0xe0fd27448726d995: established peer 10.2.1.11:500[IPV4/10.2.1.11] local 
>>>10.2.2.10:500[IPV4/10.2.2.10] policy 'policy1' as responder (enc aes-128-gcm 
>>>group curve25519 prf hmac-sha2-256)
>>>
>>>On 10.2.1.11:
>>>
>>># iked -dv 
>>>ikev2 "policy1" active tunnel esp inet from 10.2.1.11 to 10.2.2.10 local 
>>>10.2.1.11 peer 10.2.2.10 ikesa enc aes-128-gcm enc aes-256-gcm prf 
>>>hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group 
>>>curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group 
>>>modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc 
>>>aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf 
>>>hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth 
>>>hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 
>>>group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 
>>>group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn 
>>>childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth 
>>>hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 
>>>10.2.1.11 lifetime 10800 bytes 4294967296 signature
>>>ikev2_init_ike_sa: initiating "policy1"
>>>spi=0xe0fd27448726d995: send IKE_SA_INIT req 0 peer 10.2.2.10:500 local 
>>>10.2.1.11:500, 518 bytes
>>>spi=0xe0fd27448726d995: recv IKE_SA_INIT res 0 peer 10.2.2.10:500 local 
>>>10.2.1.11:500, 235 bytes, policy 'policy1'
>>>spi=0xe0fd27448726d995: send IKE_AUTH req 1 peer 10.2.2.10:500 local 
>>>10.2.1.11:500, 463 bytes
>>>spi=0xe0fd27448726d995: recv IKE_AUTH res 1 peer 10.2.2.10:500 local 
>>>10.2.1.11:500, 342 bytes, policy 'policy1'
>>>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, 
>>>0xd94b3836 (enc aes-128-gcm esn)
>>>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: 
>>>ESP-10.2.1.11/32=10.2.2.10/32(0)
>>>spi=0xe0fd274

Re: host-to-host encryption with iked

[Tobias Heider]

On October 3, 2023 1:32:39 AM GMT+02:00, "Robert B. Carleton" 
 wrote:
>I'm trying to setup host-to-host encryption using iked with the
>following configuration:
>
>On 10.2.2.10:
>
>ikev2 passive esp from 10.2.2.10 to 10.2.1.11 srcid 10.2.2.10
>
>On 10.2.1.11:
>
>ikev2 active esp from 10.2.1.11 to 10.2.2.10 srcid 10.2.1.11
>
>I exchanged the /etc/iked/local.pub files into /etc/iked/pubkeys/ipv4/
>on each host using the respective IPs as the file names.
>
>When I start iked, it responds agreeably:
>
>On 10.2.2.10:
>
># iked -dv 
>ikev2 "policy1" passive tunnel esp inet from 10.2.2.10 to 10.2.1.11 local 
>10.2.2.10 peer 10.2.1.11 ikesa enc aes-128-gcm enc aes-256-gcm prf 
>hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group 
>curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group 
>modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc 
>aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf 
>hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth 
>hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group 
>ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group 
>modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa 
>enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 auth 
>hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 10.2.2.10 lifetime 
>10800 bytes 4294967296 signature
>spi=0xe0fd27448726d995: recv IKE_SA_INIT req 0 peer 10.2.1.11:500 local 
>10.2.2.10:500, 518 bytes, policy 'policy1'
>spi=0xe0fd27448726d995: send IKE_SA_INIT res 0 peer 10.2.1.11:500 local 
>10.2.2.10:500, 235 bytes
>spi=0xe0fd27448726d995: recv IKE_AUTH req 1 peer 10.2.1.11:500 local 
>10.2.2.10:500, 463 bytes, policy 'policy1'
>spi=0xe0fd27448726d995: send IKE_AUTH res 1 peer 10.2.1.11:500 local 
>10.2.2.10:500, 342 bytes
>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, 
>0xd94b3836 (enc aes-128-gcm esn)
>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: 
>ESP-10.2.2.10/32=10.2.1.11/32(0)
>spi=0xe0fd27448726d995: established peer 10.2.1.11:500[IPV4/10.2.1.11] local 
>10.2.2.10:500[IPV4/10.2.2.10] policy 'policy1' as responder (enc aes-128-gcm 
>group curve25519 prf hmac-sha2-256)
>
>On 10.2.1.11:
>
># iked -dv 
>ikev2 "policy1" active tunnel esp inet from 10.2.1.11 to 10.2.2.10 local 
>10.2.1.11 peer 10.2.2.10 ikesa enc aes-128-gcm enc aes-256-gcm prf 
>hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group 
>curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group 
>modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc 
>aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf 
>hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth 
>hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group 
>ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group 
>modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa 
>enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 auth 
>hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 10.2.1.11 lifetime 
>10800 bytes 4294967296 signature
>ikev2_init_ike_sa: initiating "policy1"
>spi=0xe0fd27448726d995: send IKE_SA_INIT req 0 peer 10.2.2.10:500 local 
>10.2.1.11:500, 518 bytes
>spi=0xe0fd27448726d995: recv IKE_SA_INIT res 0 peer 10.2.2.10:500 local 
>10.2.1.11:500, 235 bytes, policy 'policy1'
>spi=0xe0fd27448726d995: send IKE_AUTH req 1 peer 10.2.2.10:500 local 
>10.2.1.11:500, 463 bytes
>spi=0xe0fd27448726d995: recv IKE_AUTH res 1 peer 10.2.2.10:500 local 
>10.2.1.11:500, 342 bytes, policy 'policy1'
>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, 
>0xd94b3836 (enc aes-128-gcm esn)
>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: 
>ESP-10.2.1.11/32=10.2.2.10/32(0)
>spi=0xe0fd27448726d995: established peer 10.2.2.10:500[IPV4/10.2.2.10] local 
>10.2.1.11:500[IPV4/10.2.1.11] policy 'policy1' as initiator (enc aes-128-gcm 
>group curve25519 prf hmac-sha2-256)
>
>Here's the output from ipsecctl -sa:
>
>On 10.2.2.10:
>
>FLOWS:
>flow esp in from 10.2.1.11 to 10.2.2.10 peer 10.2.1.11 srcid IPV4/10.2.2.10 
>dstid IPV4/10.2.1.11 type require
>flow esp out from 10.2.2.10 to 10.2.1.11 peer 10.2.1.11 srcid IPV4/10.2.2.10 
>dstid IPV4/10.2.1.11 type require
>
>SAD:
>esp tunnel from 10.2.2.10 to 10.2.1.11 spi 0x0135c999 enc aes-128-gcm
>esp tunnel from 10.2.1.11 to 10.2.2.10 spi 0x8a858058 enc aes-128-gcm
>
>On 10.2.1.11:
>
>FLOWS:
>flow esp in from 10.2.2.10 to 10.2.1.11 peer 10.2.2.10 srcid IPV4/10.2.1.11 
>dstid IPV4/10.2.2.10 type require
>flow esp out from 10.2.1.11 to 10.2.2.10 peer 10.2.2.10 srcid IPV4/10.2.1.11 
>dstid IPV4/10.2.2.10 type require
>
>SAD:
>esp tunnel from 10.2.2.10 to 10.2.1.11 spi 0x0135c999 enc aes-128-gcm
>esp tunnel from 10.2.1.11 to 10.2.2.10 spi 0x8a858058 enc aes-128-gcm
>
>Once 

Re: IPsec over PPPoE

[Tobias Heider]

On Wed, Aug 23, 2023 at 08:03:34AM +0200, Jiri Navratil wrote:
> Hello,
> 
> Thank you for quick and helpful replies.
> 
> Adding line
> 
> set skip on enc0  
> 
> to pf.conf enabled traffic between my sites.
> 
> I see in https://www.openbsd.org/faq/faq17.html
> 
> "Traffic between them should appear after decapsulation on the enc0
> interface, and can be filtered as such." and next line works with VPN
> tag, but there are no lines "pass in ... tag VPN" in pf.conf before this
> part. Shall that be added to FAQ? I expect, that switch from "set skip on
> enc0" to "pass in ... tag VPN" will be better in my case.
> 
> If someone with IPsec experiences will propose changes to FAQ17, then I
> also noted:
> 
> In "road warrior" part, there is "We'll assume the public IP for the
> client is 203.0.113.2.", but the example uses "any".

I think any is the better choice here. This would allow other clients
to connect to the same server (if they have a valid key) which is probably
what most people want.

> 
> I think, that word "daemon" is better then "server" here: 
> 
> The ikectl(8) utility is used to control the server,

Agree

> 
> I want to extend my IKEv2 Site-to-site VPN with road warrior
> configuration. If the road warrior part will include few lines about,
> how to extend responder to handle both site-to-site and road warrior, it
> will be very helpful.

Are you thinking of an example with multiple "ikev2 ..." blocks or a comment
mentioning that you can have multiple of those in the same config file?
Because that is technically all you need.

> 
> Thank you OpenBSD for IPsec and thank you for your support to let me
> configure it.
> 
> BR,
> Jiří
> 
> -- 
> Jiri Navratil, https://nocloud.cz
> 

Re: IPsec "road warrior" VPN not getting set up properly.

[Tobias Heider]

I am a bit late to the party, but some more comments below.

On Sun, Jul 09, 2023 at 11:27:20PM -0400, Anthony Coulter wrote:
> Summary of this email:
> 
> 1. I respond to a couple of specific points made by other folks in this
>thread to clarify what I'm trying to accomplish (set up a couple of
>ad hoc link-local routes without having to ask my ISP for a larger
>subnet) and to acknowledge that I said something stupid about pings.
> 
> 2. I abandon my quest to get NDP proxying added to iked and instead ask
>if we can add a "rtlabel" keyword to iked.conf to make it easier for
>me to write a separate process that monitors the routing table to
>detect when the tunnel gets set up.
> 
> 3. I ask three questions about the intended uses of routing labels, the
>purpose of iked's "cloned routes," and the viability of a routing
>socket that checks your privileges at the time it is opened instead
>of the time it is used.
> 
> 4. I provide a first draft of a patch which adds that "rtlabel" keyword.
> 
> 
> === Part I. Responding to the discussion ===
> 
> Andy Bradford wrote:
> 
> >> I would also suggest comparing the "hackiness" of NDP proxying to the
> >> hackiness of NAT, which is how we solve this same problem in IPv4.
> >
> > I realize I'm coming in late to this discussion, and may not actually
> > have anything of value to add, but...
> >
> > I'm not sure how NDP proxying and NAT are related at all. I seems to
> > me that NDP proxying is more akin to proxy ARP than NAT:
> >
> > http://man.openbsd.org/arp#s
> 
> They are related in that they are solutions to similar problems. In
> IPv4 we use NAT to deal with the shortage of IP addresses. In IPv6 we
> can use NDP proxying to deal with a local shortage of IPv6 subnets. My
> purpose in writing the line you quoted was to argue that NDP proxying
> is no more hacky than NAT, and the rest of the email tried to argue
> that it was less hacky. Zack Newman, at least, disagrees, and nobody
> jumped to defend my position. So OK, I will settle for calling them
> equally hacky.
> 
> My goal in this discussion was to either convince someone that adding
> automatic NDP proxying to iked was a good idea, or to at least get
> agreement that it isn't a bad idea so that they would accept the code
> if I wrote it myself. I failed in both of these objectives. But that's
> why it matters to me whether NDP proxying is considered hacky or not.
> If it's hacky, then the iked maintainers will reject a patch that adds
> the ndp-proxy keyword even if I write it myself.
> 
> 
> Zack Newman wrote:
> 
> > Yeah, I don't have the interest to get into it about this; but I find
> > it (informally) inconsistent to take an ideological stance against NAT
> > and not have a similar stance against NDP proxying.
> 
> To this I'll say that my stance against NAT isn't ideological. It's
> just that NAT is more intrusive than NDP proxying. All NDP proxying
> does is tell nearby hosts to update their routing tables to do exactly
> what you want them to do. NAT, on the other hand, rewrites addresses
> and ports so the packet you send out isn't the packet the other end
> receives. And I'm not saying that people shouldn't use NAT for IPv4.
> I just think that in the IPv6 case, if getting more subnets isn't an
> easy affair, NDP proxying is a less-intrusive hack to get your VPN
> client's traffic routed properly than NAT is, and as such, setting it
> up ought to be as convenient and hassle-free as adding rules to pf.
> 
> 
> > Also not sure where you heard that ICMP does not work with NAT. Surely
> > you don't believe that. Go ahead and use ping(8) on any device that
> > relies on NAT to talk to the outside world and witness how it
> > "magically" works. ICMP uses the Query ID in lieu of a port number.
> 
> Yikes, I wasn't thinking clearly. While it's true that an external host
> can't ping the NATted host (it can only ping the server which is doing
> the NAT), that isn't the gist of what I claimed. Yes, you are correct.
> 
> 
> > Will NDP proxying work? Depending on what you want, sure just like NAT
> > will likely work. Relying on a simple routing table is far more ideal.
> > NDP proxying is also vulnerable to NDP cache DoS. You can use your
> > favorite search engine to learn why NDP proxying is not as good as
> > simple routes.
> 
> Thanks for the specific example. I looked into this and it seems that
> my use case might be misunderstood. The NDP cache DoS depends on a
> setup similar to what the "nd-reflector" project (linked to in a
> previous email in this thread) provides: NDP-proxying an entire subnet
> instead of just the one host in question. Under these circumstances,
> an attacker can fill the router's NDP cache with a bunch of
> incorrectly-proxied addresses that don't actually point to anything,
> just by trying to hit a bunch of random addresses in the subnet and
> tricking the NDP proxy into responding to all of them.
> 
> The use case I have in mind is to 

Re: IPsec "road warrior" VPN not getting set up properly.

[Tobias Heider]

On July 5, 2023 4:35:30 AM GMT+03:00, Anthony Coulter 
 wrote:
>Short version:
>
>I'm trying to set up a "road warrior"-style VPN like the one described
>at https://www.openbsd.org/faq/faq17.html but I'm trying to use IPv6 so
>I can have globally-routable addresses (so I'm not using NAT). So far
>I've gotten the initiator and the responder to set up a security
>association (to be precise, according to "ipsecctl -sa" the
>initiator/client sees one SA and zero flows, and the responder/server
>sees two SA's and two flows). When I try to ping the client's virtual
>IP address from the server, tcpdump running on the egress interfaces of
>both the client and the server see appropriately-sized "esp" packets
>going from the server to the client as expected, but tcpdump doesn't
>see any traffic emerging on the "lo1" loopback interface the FAQ told
>me to create, nor does it see any evidence of ping-responses being
>sent. When I try to ping from the client to the server, I get
>"ping6: sendmsg: Permission denied".
>
>
>Longer version:
>
>The client is running -current and the server is running 7.3.
>
>The server is a VPS hosted in a datacenter somewhere, and my VPS
>provider gives me a whole /64 subnet to work with. My VPS provider
>doesn't appear to look at neighbor discovery traffic; it routes all
>traffic in that /64 to my VirtIO interface, regardless of which IP
>address it is, which seems like a handy feature for what I'm trying to
>do.
>
>Here is what I want to do: the client should open an IPsec tunnel to
>the server. The client should request an IPv6 address from the server's
>enormous /64 subnet. Then, applications running on the client should
>have the option to use that "virtual" IPv6 address as though it was
>available on a local interface on the client machine. The client would
>effectively be multihosted: in addition to its regular physical
>Internet connection it would also have this IPsec tunnel that also
>connects to the global Internet. My plan right now is to use rdomains
>to control which applications use the tunnel and which ones use the
>regular egress interface, but I'm not attached to that specific
>approach.
>
>The application should be obvious: I'm trying to set up a region-faking
>VPN, so that I can have applications appear to connect to the Internet
>from different continents.
>
>Both client and server are using the same pf.conf that is installed by
>default. I tried adding "pass on enc0" to the client's pf.conf and
>"pass on enc0 tagged ROADW" to the server's, but it hasn't made a
>difference because (I assume) my existing pf.conf rules weren't
>blocking much to begin with.
>
>Here are my config files, with IP addresses and server names changed.
>But basically you should see the client at 2001:db8:1::1 connecting to
>the server at 2001:db8:2::1 and requesting a random IP address in the
>server's subnet, e.g. 2001:db8:2::485b:4ac7. I have also put the
>appropriate keys in /etc/iked/pubkeys/fqdn/.
>
>=== Client-side configuration ===
>$ cat /etc/hostname.lo1
>rdomain 1
>
>$ cat /etc/iked.conf
>ikev2 'client_config' active esp \
>rdomain 1 \
>from dynamic to any \
>   local 2001:db8:1::1 \
>peer  2001:db8:2::1 \
>srcid client.example.org \
>dstid server.example.org \
>request address any \
>iface lo1
>
>=== Server-side configuration ===
>
>$ cat /etc/sysctl.conf
>net.inet6.ip6.forwarding=1
>
>$ cat /etc/iked.conf
>ikev2 'server_config' passive esp \
>from any to dynamic \
>local 2001:db8:2::1 \
>   peer  2001:db8:1::1 \
>srcid server.example.org \
>config address 2001:db8:2::/64 \
>tag "ROADW"
>
>=== End of configurations ===
>
>Does it work? Sort of. Here's what I see on the server:
>
>=== Checking status on the server ===
>
># ipsecctl -sa
>FLOWS:
>flow esp in from 2001:db8:2::485b:4ac7 to ::/0 peer 2001:db8:1::1 srcid 
>FQDN/server.example.org dstid FQDN/client.example.org type require
>flow esp out from ::/0 to 2001:db8:2::485b:4ac7 peer 2001:db8:1::1 srcid 
>FQDN/server.example.org dstid FQDN/client.example.org type require
>
>SAD:
>esp tunnel from 2001:db8:2::1 to 2001:db8:1::1 spi 0x001a3754 enc aes-128-gcm
>esp tunnel from 2001:db8:1::1 to 2001:cb8:2::1 spi 0x7634a3b6 enc aes-128-gcm
>
>$ route show
>Internet6:
>DestinationGateway Flags   Refs  Use   Mtu  Prio Iface
>defaultfe80::1234%vio0 UGS8  578 - 
>8 vio0 
>::/96  localhost   UGRS   00 32768 8 lo0  
>localhost  localhost   UHhl  10   90 32768 1 lo0  
>:::0.0.0.0/96  localhost   UGRS   00 32768 8 lo0  
>2001:db8:2::/64server  UCn3 3630 - 
>4 vio0 
>2001:db8:2::485b:4ac7  link#1  UHLc   0 3633 - 3 vio0 
>...and a whole lot more
>
>=== Checking status on the client ===
>
># ipsecctl -sa
>FLOWS:
>No 

Re: lidaction on an M1 macbook

[Tobias Heider]

On Tue, Apr 11, 2023 at 06:29:50PM +0200, Jan Stary wrote:
> > o On arm64, add a machdep.lidaction sysctl(8)
> > for aplsmc(4) Apple Silicon laptops.
> 
> Should that be mentioned in the arm64 examples/sysctl.conf
> as on other such architectures?
> 
> Index: etc/etc.arm64/sysctl.conf
> ===
> RCS file: /cvs/src/etc/etc.arm64/sysctl.conf,v
> retrieving revision 1.1
> diff -u -p -r1.1 sysctl.conf
> --- etc.arm64/sysctl.conf 11 Jan 2017 22:57:34 -  1.1
> +++ etc.arm64/sysctl.conf 11 Apr 2023 15:40:50 -
> @@ -0,0 +1 @@
> +#machdep.lidaction=0 # 1=suspend, 2=hibernate laptop upon lid closing
> 
> 
> > aplsmc(4) provides support for the lid position sensor.
> 
> Should that be mentioned in aplsmc(4)?

Sounds like a good idea.

> 
> Index: aplsmc.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.arm64/aplsmc.4,v
> retrieving revision 1.2
> diff -u -p -r1.2 aplsmc.4
> --- aplsmc.4  10 Jan 2022 21:16:44 -  1.2
> +++ aplsmc.4  11 Apr 2023 15:49:20 -
> @@ -28,7 +28,7 @@ The
>  driver provides support for the System Management Controller (SMC)
>  found on various Apple SoCs.
>  The driver provides a collection of current, fan, power, temperature,
> -voltage and battery information sensors.
> +voltage, lid position and battery information sensors.
>  .Pp
>  Sensor values are made available through the
>  .Xr sysctl 8

ok too.

> 
> 
> > >  The arm64 default for the machdep.lidaction is 1, making the
> > >  system suspend when the lid is closed.
> 
> On this M1 macbook (dmesg below), I see no difference
> between lidaction=0 and lidaction=1; with both,
> closing and opening the lid does this:
> 
> (lidaction=0)

Is this still the case?
For me lidaction=0 seems to only disable the screen which is inteded,
lidaction=1 triggers a suspend.

> 
> Apr 11 16:54:22 mb /bsd: uhub0 detached
> Apr 11 16:54:22 mb /bsd: uhub1 detached
> 
> Apr 11 16:54:31 mb /bsd: wsdisplay_switch2: not switching
> Apr 11 16:54:31 mb /bsd: cpu0: 1 wakeup events
> Apr 11 16:54:31 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic 
> xHCI root hub" rev 3.00/1.00 addr 1
> Apr 11 16:54:31 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic 
> xHCI root hub" rev 3.00/1.00 addr 1
> Apr 11 16:54:31 mb /bsd: cpu7: 1 wakeup events
> Apr 11 16:54:31 mb /bsd: cpu4: 1 wakeup events
> Apr 11 16:54:31 mb /bsd: cpu6: 1 wakeup events
> Apr 11 16:54:31 mb /bsd: cpu5: 1 wakeup events
> Apr 11 16:54:31 mb /bsd: cpu1: 1 wakeup events
> Apr 11 16:54:31 mb /bsd: cpu3: 1 wakeup events
> Apr 11 16:54:31 mb /bsd: cp
> Apr 11 16:54:31 mb /bsd: u2: 1 wakeup events
> Apr 11 16:54:31 mb root: running /etc/apm/resume
> Apr 11 16:54:36 mb apmd: system resumed from sleep
> Apr 11 16:54:36 mb apmd: battery status: high. external power status: not 
> connected. estimated battery life 99% (834 minutes life time estimate)
> 
> (lidaction=1)
> 
> Apr 11 17:05:12 mb /bsd: uhub0 detached
> Apr 11 17:05:12 mb /bsd: uhub1 detached
> 
> Apr 11 17:05:20 mb /bsd: wsdisplay_switch2: not switching
> Apr 11 17:05:20 mb /bsd: cpu0: 1 wakeup events
> Apr 11 17:05:20 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic 
> xHCI root hub" rev 3.00/1.00 addr 1
> Apr 11 17:05:20 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic 
> xHCI root hub" rev 3.00/1.00 addr 1
> Apr 11 17:05:20 mb /bsd: cpu7: 1 wakeup events
> Apr 11 17:05:20 mb /bsd: cpu5: 1 wakeup events
> Apr 11 17:05:20 mb /bsd: cpu4: 1 wakeup events
> Apr 11 17:05:20 mb /bsd: cpu6: 1 wakeup events
> Apr 11 17:05:20 mb /bsd: cpu2: 1 wakeup events
> Apr 11 17:05:20 mb /bsd: cpu3: 1 wakeup events
> Apr 11 17:05:20 mb /bsd: cpu1: 1 wakeup events
> Apr 11 17:05:20 mb root: running /etc/apm/resume
> Apr 11 17:05:26 mb apmd: system resumed from sleep
> Apr 11 17:05:26 mb apmd: battery status: high. external power status: not 
> connected. estimated battery life 98% (796 minutes life time estimate)
> 
> So even with lidaction=0 it kind-of-suspends,
> and kind-of-resumes, running /etc/apm/resume.
> Is that expected?
> 
> There also seems to be a difference between suspending with apm -z
> and suspending by closing the lid; namely, apm -z does call
> /etc/apm/suspend but the lid does not. Is that intended?
> 
> (apm -z)
> 
> Apr 11 16:55:30 mb apmd: system suspending
>^^^
> Apr 11 16:55:30 mb apmd: battery status: high. external power status: not 
> connected. estimated battery life 99% (712 minutes life time estimate)
> Apr 11 16:55:30 mb root: running /etc/apm/suspend
>  
> Apr 11 16:55:31 mb /bsd: uhub0 detached
> Apr 11 16:55:31 mb /bsd: uhub1 detached
> 
> Apr 11 16:55:37 mb /bsd: wsdisplay_switch2: not switching
> Apr 11 16:55:37 mb /bsd: cpu0: 1 wakeup events
> Apr 11 16:55:37 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic 
> xHCI root hub" rev 

Re: Username and/or password lengths for OpenIKED with EAP MSCHAP-V2

[Tobias Heider]

On Fri, Mar 10, 2023 at 05:00:36PM -0500, A Tammy wrote:
> 
> On 3/10/23 15:42, J Doe wrote:
> > On 2023-03-05 17:19, A Tammy wrote:
> >
> >>
> >> On 3/5/23 16:49, J Doe wrote:
> >>> Hello,
> >>>
> >>> I was wondering if there is a limit to the number of characters that
> >>> the username and/or password can be when using EAP MSCHAP-V2 in
> >>> OpenIKED.
> >>>
> >>> In particular, I was wondering if either OpenIKED enforced a limit or
> >>> whether MSCHAP-V2 has a limit based on the underlying authentication
> >>> scheme ?
> >>>
> >>> Thanks,
> >>>
> >>> - J
> >>>
> >> A quick 30s look into the source code shows -
> >> https://github.com/openbsd/src/blob/master/sbin/iked/chap_ms.h#LL30C2-L30C32
> >>
> >>
> >>> #define MSCHAP_MAXNTPASSWORD_SZ    255    /* unicode chars */
> >>
> >> a good point for you to start looking :)
> >>
> >> Cheers,
> >> Aisha
> >
> > Hi,
> >
> > Thanks for your response ... Ordinarily, I would assume that the
> > maximum password size would then be 255 ASCII characters, but is the
> > size different because the comment notes it's for Unicode characters ?
> >
> > Thanks,
> >
> > - J
> >
> I don't know :)
> 
> You should try to read the source code, that's not the only variable in
> that file, maybe the other ones are the actual password/username size.
> 
> 

IKED_PASSWORD_SIZE from types.h seems to be the actually enforced limit.
The relevant code snippet is config.c:471:

memcpy(old->usr_pass, new->usr_pass, IKED_PASSWORD_SIZE);

Re: Authentication in OpenIKED

[Tobias Heider]

On Wed, Mar 01, 2023 at 01:38:24PM +, Stuart Henderson wrote:
> On 2023/03/01 14:21, Tobias Heider wrote:
> > On Wed, Mar 01, 2023 at 09:24:50AM -, Stuart Henderson wrote:
> > > On 2023-03-01, J Doe  wrote:
> > > > Hello,
> > > >
> > > > I have a question regarding authentication options in OpenIKED on 
> > > > OpenBSD 7.2
> > > >
> > > > On my test lab I have one OpenBSD 7.2 machine with OpenIKED configured 
> > > > to use PSK and a macOS 13.2.1 client that can connect to it.
> > > >
> > > > I read in: man iked.conf that PSK should not be used, so I am now 
> > > 
> > > I don't see that in the iked.conf manual. There is some reference to not
> > > using psk in /etc/examples/iked.conf but it's not clear whether that's
> > > because of the need to share a single psk with all endpoints connecting
> > > via the same iked.conf configuration line (certainly a problem when
> > > you have multiple users from unknown IPs but perhaps not if used for
> > > separately-configured lan-to-lan tunnels with strong randomly generated
> > > psks) or whether it's something else.
> > 
> > We should probably remove that comment.
> 
> Wondering if we should actually remove the whole examples/iked.conf
> file, it doesn't seem hugely useful..
> 

I don't think I have ever used it.  ok with me if no one objects.

Re: Authentication in OpenIKED

[Tobias Heider]

On Wed, Mar 01, 2023 at 09:24:50AM -, Stuart Henderson wrote:
> On 2023-03-01, J Doe  wrote:
> > Hello,
> >
> > I have a question regarding authentication options in OpenIKED on 
> > OpenBSD 7.2
> >
> > On my test lab I have one OpenBSD 7.2 machine with OpenIKED configured 
> > to use PSK and a macOS 13.2.1 client that can connect to it.
> >
> > I read in: man iked.conf that PSK should not be used, so I am now 
> 
> I don't see that in the iked.conf manual. There is some reference to not
> using psk in /etc/examples/iked.conf but it's not clear whether that's
> because of the need to share a single psk with all endpoints connecting
> via the same iked.conf configuration line (certainly a problem when
> you have multiple users from unknown IPs but perhaps not if used for
> separately-configured lan-to-lan tunnels with strong randomly generated
> psks) or whether it's something else.

We should probably remove that comment.

I think there is actually no reason to avoid PSK in IKEv2 if both endpoints
are trusted. Of course it doesn't scale well and all security considerations
for shared WiFi passwords apply here as well, but there isn't an obvious
weakeness like the plain text passphrase being sent over the network.
Expecting people to generate X509 certificates for simple peer-to-peer setups
seems a lot worse.

> 
> > investigating EAP with MSCHAP-V2 and X.509 certificate authentication, 
> > but I am confused as to which is more secure.
> >
> > It seems to me that if I use EAP with MSCHAP-V2, I need a certificate on 
> > the OpenBSD machine, but I can connect from the macOS client with a user 
> > name and password, whereas X.509 authentication requires an X.509 
> > certificate on *BOTH* client and server - is that correct ?
> 
> Yes.
> 
> > If it is, is the reason that X.509 authentication is more secure because 
> > of the two certificates required, whereas authentication with EAP with 
> > MSCHAP-V2 is less secure because only one certificate is required ?
> 
> One problem is that MSCHAPv2 requires that the password is stored
> in cleartext rather than some kind of hash, so someone with access
> to the server config is able to connect (as any user), whereas with
> certificates this can't be done.
> 
> Another is that it's a password which must often be typed by a user,
> so in that case there's some disincentive to having a more secure
> but hard to type password.
> 
> (There are other long documented problems with MSCHAPv2 but my
> understanding is that those are not so important when used with in
> conjunction with protocols like IKEv2 and PEAP where the auth is done
> over a channel which is already secure - however that does require that
> the initiator actually checks the certificate sent by the responder
> otherwise MITM is a problem - and in most implementations it's all too
> easy to disable checking this i.e. on the client side).
> 
> -- 
> Please keep replies on the mailing list.
> 

Re: ikev2_resp_create_child_sa: no proposal chosen

[Tobias Heider]

On Fri, Feb 24, 2023 at 09:24:29AM -, Stuart Henderson wrote:
> On 2023-02-23, Thomas Bohl  wrote:
> > I have several OpenBSD 7.2 connected to a commercial VPN-Router (LANCOM 
> > 1781EW+) using iked. It works, except every time the Child SA 
> > negotiation starts, iked answers NO_PROPOSAL_CHOSEN to the router. Which 
> > leads to closed connections and a new IKE SA negotiation.
> > I don't understand this because the proposal looks supported to me.
> 
> Child SA failing after the initial tunnel comes up usually relates to a
> mismatch with PFS (DH groups).

Right, it is a huge fail in the protocol desing that those incompatibilities
aren't detected until the first refresh which can happen hours after it
seemingly worked just fine.

The only solution I could think of to make it more obvious would be
forcing a rekey handshake right after the initial one, but that would
increase the network load and might have other downsides.

> 
> > I got desperate and tried adding this to iked.conf, which didn't help:
> >
> > childsa group modp2048 \
> > childsa group modp2048 noesn\
> > childsa enc aes-256-gcm group modp2048 \
> > childsa enc aes-256-gcm group modp2048 noesn \
> > childsa enc aes-256 group modp2048 \
> > childsa enc aes-256 group modp2048 noesn \
> > childsa enc aes-256-gcm group modp2048 prf hmac-sha2-256 \
> > childsa enc aes-256-gcm group modp2048 prf hmac-sha2-256 noesn \
> > childsa enc aes-256 group modp2048 prf hmac-sha2-256 \
> > childsa enc aes-256 group modp2048 prf hmac-sha2-256 noesn \
> > childsa enc aes-256 group modp2048 prf hmac-sha1 \
> > childsa enc aes-256 group modp2048 prf hmac-sha1 noesn \
> >
> > Any ideas?
> 
> Try adding some non-modp2048 options. Maybe look at the SA installed
> from the initial negotiation (ipsecctl -vvsa) for ideas.

I think this is the right answer. The log tells you what the other side sent:

spi=0x0a131729beeb819a: ikev2_log_proposal: ESP #1 ENCR=AES_CBC-256
spi=0x0a131729beeb819a: ikev2_log_proposal: ESP #1 INTEGR=HMAC_SHA2_256_128
spi=0x0a131729beeb819a: ikev2_log_proposal: ESP #1 INTEGR=HMAC_SHA1_96
spi=0x0a131729beeb819a: ikev2_log_proposal: ESP #1 ESN=NONE

There isn't any DH group for PFS here, so drop the modp2048 or add it on the
other side.

> 
> 
> -- 
> Please keep replies on the mailing list.
> 

Re: How to configure iked with OpenBSD (roadwarrior)?

[Tobias Heider]

On Thu, Nov 24, 2022 at 06:51:40PM +0300, Aleksandr Mikhaylov wrote:
> Tobias Heider wrote:
> > On Thu, Nov 24, 2022 at 05:50:57PM +0300, Aleksandr Mikhaylov wrote:
> > > Tobias Heider wrote:
> > > > On Thu, Nov 24, 2022 at 12:45:03PM +0300, Aleksandr Mikhaylov wrote:
> > > > > Hi. Please tell me how to connect to an OpenBSD 7.2 Release
> > > > > from an OpenBSD 7.2 Release client via iked.
> > > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > your configs look ok.  The server log shows the handshake is completed
> > > > and a IKE_AUTH reply is sent to the client, but on the client side this
> > > > message never arrives. This is why it keeps on resending the AUTH 
> > > > request
> > > > until it times out.
> > > > 
> > > > It is not clear whether the reply is lost in transit or discarded by 
> > > > your
> > > > client.  You could try looking at a tcpdump of your handshake or enable
> > > > verbose logging in iked on your client and see if you can find anything
> > > > suspicious after "send IKE_AUTH req 1 ...".
> > > > 
> > > > - Tobias
> > > 
> > > And on which ports should the connection come to the laptop? It has pf
> > > configured on it and is behind NAT
> > 
> > Probably the one with your default route. Try 'route get bsd.server.vds'.
> 
> I mean tcp/udp port
> 

That would be udp 4500 because it is using udpencap for NAT traversal as we
can see in your log:

send IKE_AUTH res 1 peer W.X.Y.Z:4500 local A.B.C.D:4500 ...

Re: How to configure iked with OpenBSD (roadwarrior)?

[Tobias Heider]

On Thu, Nov 24, 2022 at 05:50:57PM +0300, Aleksandr Mikhaylov wrote:
> Tobias Heider wrote:
> > On Thu, Nov 24, 2022 at 12:45:03PM +0300, Aleksandr Mikhaylov wrote:
> > > Hi. Please tell me how to connect to an OpenBSD 7.2 Release
> > > from an OpenBSD 7.2 Release client via iked.
> > > 
> > 
> > Hi,
> > 
> > your configs look ok.  The server log shows the handshake is completed
> > and a IKE_AUTH reply is sent to the client, but on the client side this
> > message never arrives. This is why it keeps on resending the AUTH request
> > until it times out.
> > 
> > It is not clear whether the reply is lost in transit or discarded by your
> > client.  You could try looking at a tcpdump of your handshake or enable
> > verbose logging in iked on your client and see if you can find anything
> > suspicious after "send IKE_AUTH req 1 ...".
> > 
> > - Tobias
> 
> And on which ports should the connection come to the laptop? It has pf
> configured on it and is behind NAT

Probably the one with your default route. Try 'route get bsd.server.vds'.

Re: How to configure iked with OpenBSD (roadwarrior)?

[Tobias Heider]

On Thu, Nov 24, 2022 at 12:45:03PM +0300, Aleksandr Mikhaylov wrote:
> Hi. Please tell me how to connect to an OpenBSD 7.2 Release
> from an OpenBSD 7.2 Release client via iked.
> I'm trying to set it up with this documentation,
> https://www.openbsd.org/faq/faq17.html#clientikev2
> but it just doesn't work.
> 
> I have a VDS machine (server) with OpenBSD, 
> with one external ip-address A.B.C.D, 
> which I want to connect to from my laptop.
> 
> I copied the file from VDS /etc/iked/local.pub to the laptop in
> /etc/iked/pubkeys/fqdn/bsd.server.vds and from the laptop the file
> /etc/iked/local.pub on VDS in /etc/iked/pubkeys/fqdn/amihailov.laptop
> 
> VDS machine settings:
> 
> cat /etc/iked.conf
> ikev2 'responder_rsa' passive esp \
> from any to dynamic \
> local any peer any \
> srcid bsd.server.vds \
> config address 172.24.24.0/24 \
> tag "ROADW"
> 
> cat /etc/sysctl.conf
> net.inet.ip.forwarding=1
> 
> pf.conf:
> ...
> block in on vio0
> pass out 
> pass in proto udp from any to port {500, 4500} keep state
> pass in proto esp from any
> pass on enc0 from any to any
> pass on enc0 from any to self keep state (if-bound)
> ...
> 
> # cat /etc/hostname.enc0
> inet 172.24.24.1 255.255.255.0 172.24.24.255
> up
> 
> Laptop settings:
> ikev2 'amihailov.laptop' active esp \
> from dynamic to any \ \
> peer bsd.server.vds \
> srcid amihailov.laptop \
> dstid bsd.server.vds \
> request address any \
> iface lo1
> 
> When I run iked - I get the following log messages on the server:
> 
> https://pastebin.com/raw/rgpTtMzr
> 
> And on the laptop:
> 
> https://pastebin.com/raw/UUrryZCN
> 
> A.B.C.D is the external address of the server, 
> 10.222.222.222 is the address of the laptop in the local network
> W.X.Y.Z is the external address of the gateway, 
> through which the laptop gets to the Internet.
> 
> Lo1 interface on the laptop also does not get an ip-address.
> I would be very grateful if you could tell me what I am doing wrong. 
> If you need any additional logs and information, I will send it to you. 
> Thanks for your attention!
> 

Hi,

your configs look ok.  The server log shows the handshake is completed
and a IKE_AUTH reply is sent to the client, but on the client side this
message never arrives. This is why it keeps on resending the AUTH request
until it times out.

It is not clear whether the reply is lost in transit or discarded by your
client.  You could try looking at a tcpdump of your handshake or enable
verbose logging in iked on your client and see if you can find anything
suspicious after "send IKE_AUTH req 1 ...".

- Tobias

Re: wpa_supplicant broken?

[Tobias Heider]

On Sat, Aug 13, 2022 at 11:10:12AM +, Kostya Berger wrote:
> Hi,I'm trying to connect my OpenBSD 7.1 box to WPA-Enterprise AP. But 
> wpa_supplicant fails to connect. However, the same config works fine in 
> FreeBSD etc, just as it did  in previous versions of OpenBSD (the last I used 
> was 6.8 I think).
> Отправлено из Yahoo Почты для Android

Hi Kostya,

can you check if your connection works after a manual `reassociate` triggered 
from
wpa_cli?

Re: IKEV2 two devices can connect but only one can make traffic

[Tobias Heider]

On Tue, Apr 12, 2022 at 01:03:55AM +0200, Ettore Tagarelli wrote:
> If I use the "dynamic keyword I get this error: "no IP address found for
> dynamic" though "config address 192.168.98.1/24" is there.
> Using 0.0.0.0/32 instead of 0.0.0.0/0 causes that traffic is not routed
> ('cause /32 restrict the only address possible to 0.0.0.0) though
> connection happens correctly.

Because I mixed it up. 0.0.0.0/32 should be equivalent to dynamic.
What i meant was "from 0.0.0.0/0 to 0.0.0.0/32" but now that you have
7.0 you might as well use the less confusing keywords.

Re: IKEV2 two devices can connect but only one can make traffic

[Tobias Heider]

On Tue, Apr 12, 2022 at 03:06:50PM +0200, Ettore Tagarelli wrote:
> Updated to 7.0
> ...same problem 

What does the updated config look like? 
"from 0.0.0.0/0 to dynamic" should work in 7.0.

Re: IKEV2 two devices can connect but only one can make traffic

[Tobias Heider]

On Mon, Apr 11, 2022 at 11:13:45PM +0200, Ettore Tagarelli wrote:
> this is my iked.conf
> as far as I know the "somename" Stuart wrote about is automatically added
> by iked.

I don't exactly remember how it worked back in 6.6 either but you
could try 0.0.0.0/32 instead of 0.0.0.0/0.
In any case I would also advise to update to a newer version.

> 
> 
> user "cash" "password1"
> user "phosh" "password2"
> 
>ikev2 passive esp \
>   from 0.0.0.0/0 to 192.168.98.1/24 \
>   local 192.168.99.3 peer any \
>eap "mschap-v2" \
>config address 192.168.98.1/24 \
>   tag "$eapid"
> 
> Last device connected works, the other stops working.
> I suppose my problem could be related NAT. At the moment I couldn't try to
> connect the devices from different networks,
> Hope that someone could help
> thanks

Re: Tunnel traffic does not match SA on initial connection to remote httpd

[Tobias Heider]

On Fri, Mar 25, 2022 at 12:23:45PM -0500, rea...@catastrophe.net wrote:
> The setup is two gateways with IPsec channels setup in tunnel mode
> to bridge networks 10.255.255.0/24 and 10.254.255.0/24. Traffic from 
> server-east:enc0 does not match a SA in place when trying to connect to
> httpd on server-west.
> 
> Setup in ASCII art:
> 
> em0:203.0.113.50 -~-~- ipsec tunnel -~-~-~- vio0:100.64.1.92
>  | SERVER-WEST | | SERVER-EAST |
> enc0:10.255.255.1/24enc0:10.254.255.1/24
> 
> When traffic sources from 10.254.255.1 to server-west's httpd, the initial
> SYN goes out 100.64.1.92 and does not match the ipsec SA in place:
> 
> flow esp out from 10.254.255.0/24 to 10.255.255.0/24 peer 203.0.113.50 srcid
> FQDN/server-east.example.com dstid FQDN/server-west.example.com type require
> 
> However, return traffic on server-west matches an SA already in place and is
> sent back over the tunnel to server-east. Here is a pcap from server-west
> showing the initial connection; the second packet is the response from
> server-west to server-east over the tunnel, etc.
> 
> 11:15:07.595477 100.64.1.92.53545 > 203.0.113.50.80: SWE 
> 466527235:466527235(0) win 16384  6,nop,nop,timestamp 3005156378 0> (DF)
> 11:15:07.641673 203.0.113.50 > 100.64.1.92: esp spi 0x5787a1ca seq 1 len 80 
> (DF)
> 11:15:07.641901 100.64.1.92 > 203.0.113.50: esp spi 0x9a987eb3 seq 1 len 76
> 11:15:11.959583 100.64.1.92.63317 > 203.0.113.50.80: SWE 
> 321626718:321626718(0) win 16384  6,nop,nop,timestamp 891794631 0> (DF)
> 11:15:12.005730 203.0.113.50 > 100.64.1.92: esp spi 0x5787a1ca seq 2 len 80 
> (DF)
> 
> The SA being match on server-west is:
> 
> esp tunnel from 203.0.113.50 to 100.64.1.92 spi 0x5787a1ca enc aes-256-gcm
> 
> Is something missing in my configs or does anything look obviously broken?

It looks like synproxy in your pf.conf might be the problem.
You could try adding a "from 10.254.255.1/24 to 203.0.113.50" flow to your
iked config and see if that catches the initial syn or remove the synproxy
option in pf to test how that works.

> 
> Many thanks in advance for any help.
> 
> 
> PF RULES
> 
> 
> # server-west pf
> match in all scrub (no-df random-id max-mss 1440)
> match out on em0 inet from 10.255.255.0/24 to any nat-to (em0) round-robin
> block drop in log on ! em0 inet from 203.0.113.48/30 to any
> block drop log all
> pass out proto tcp all modulate state
> pass out proto udp from any to any port = 500
> pass out proto udp from any to any port = 4500
> pass out proto esp all
> pass out proto ah all
> pass out all modulate state
> block drop in log from urpf-failed to any label "uRPF"
> block drop in log from no-route to any
> pass in proto udp from any to 203.0.113.50 port = 500 keep state
> pass in proto udp from any to 203.0.113.50 port = 4500 keep state
> pass in proto esp from any to 203.0.113.50 
> pass in proto ah from any to 203.0.113.50
> pass in inet proto tcp from any to 203.0.113.50 port = 80 flags S/SA synproxy 
> state (source-track rule, max-src-conn 256, max-src-conn-rate 40/2, overload 
>  flush, src.track 2)
> pass in inet proto tcp from 100.64.1.92 to 203.0.113.50 port = 5201 flags S/SA
> 
> # server-east pf
> match in all scrub (no-df random-id max-mss 1440)
> match out on vio0 inet from 10.254.255.0/24 to any nat-to (vio0) round-robin
> block drop in log on ! vio0 inet from 100.64.0.0/23 to any
> block drop log all
> pass out proto tcp all modulate state
> pass out proto udp from any to any port = 500
> pass out proto udp from any to any port = 4500
> pass out proto esp all
> pass out proto ah all
> pass out all modulate state
> block drop in log from urpf-failed to any label "uRPF"
> block drop in log from no-route to any
> pass in inet proto udp from any to 100.64.1.92 port = 500 keep state
> pass in inet proto udp from any to 100.64.1.92 port = 4500 keep state
> pass in inet proto esp from any to 100.64.1.92
> pass in inet proto ah from any to 100.64.1.92
> pass on enc0 all flags S/SA modulate state (if-bound) tagged VPN.SERVER-WEST
> pass on enc0 all flags S/SA modulate state (if-bound)
> pass in inet proto tcp from any to 100.64.1.92 port = 80 flags S/SA synproxy 
> state (source-track rule, max-src-conn 256, max-src-conn-rate 40/2, overload 
>  flush, src.track 2)
> pass in inet proto tcp from 203.0.113.50 to 100.64.1.92 port = 5201 flags S/SA
> 
> IPSEC FLOWS
> ===
> 
> # server-west flows
> FLOWS:
> flow esp in from 10.254.255.0/24 to 10.255.255.0/24 peer 100.64.1.92 srcid 
> FQDN/server-west.example.com dstid FQDN/server-east.example.com type require
> flow esp in from 100.64.1.92 to 203.0.113.50 peer 100.64.1.92 srcid 
> FQDN/server-west.example.com dstid FQDN/server-east.example.com type require
> flow esp out from 10.255.255.0/24 to 10.254.255.0/24 peer 100.64.1.92 srcid 
> FQDN/server-west.example.com dstid FQDN/server-east.example.com type require
> flow esp out from 203.0.113.50 to 100.64.1.92 peer 100.64.1.92 srcid 
> 

Re: ipsec traffic is dropped between two machines

[Tobias Heider]

On Mon, Mar 21, 2022 at 01:04:28PM -0500, rea...@catastrophe.net wrote:
> I have two openbsd machines configured to connect their respective
> downstream networks over ipsec. When I try to generate traffic (ping)
> from server-west's enc0 interface (10.255.255.1) to server-east's enc0
> interface (10.254.255.1), traffic is sent out the corresponding
> SA but is never seen on server-east's enc0 interface. Only when I
> simultaneously generate traffic (ping, again) on server-east back to 
> server-west do I see the echo replies from server-east on server-west.
> 
> The flows look correct in the SA table on server-west and traffic leaves on
> enc0, hits vio0 on server-east as ESP traffic, but then is dropped. Again,
> only when I also start a ping on server-east (10.254.255.1) to server-west
> (10.255.255.1) does the original ping session see replies.
> 
> Any help is appreciated. Here are the relevant configs and outputs.

I don't fully understand your setup but having both 10.255.255.0/24 to
10.254.255.0/24 and 10.254.255.0/24 to 10.255.255.0/24 configured on both
sides does not make sense to me.

Assuming 10.255.255.0/24 is reachable via server-west and 10.254.255.0/24 via
server-east the configs should probably be:

server-west:/etc/iked.conf
-
ikev2 'server-east.example.com' passive esp \
from 10.255.255.0/24 to 10.254.255.0/24 \
from 203.0.113.50/32 to 10.254.255.0/24 \
local 203.0.113.50 peer server-east.example.com \
srcid server-west.example.com \
dstid server-east.example.com \
psk "12345" \
tag "VPN.EAST"

server-east:/etc/iked.conf
-
ikev2 'server-west.example.com' active esp \
from 10.254.255.0/24 to 10.255.255.0/24 \
from 100.64.1.92/32 to 10.255.255.0/24 \
local 100.64.1.92 peer server-west.example.com \
srcid server-east.example.com \
dstid server-west.example.com \
psk "12345" \
tag "VPN.WEST"

Re: functional difference of isakmpd and iked

[Tobias Heider]

On Fri, Mar 11, 2022 at 11:27:59AM +0100, Axel Rau wrote:
> 
> 
> > Am 09.03.2022 um 11:44 schrieb Axel Rau :
> > 
> > are both able to support the same network topologies with both IPv4 and 
> > IPv6?
> Seems to be a difficult question.
> What can I do to get an answer / a comment of one of the experts?
> 
> Axel

Hey Axel,

looks like your setup should also work with iked.  Keep in mind
however that running iked and isakmpd on the same machine does not work,
so you will probably have to switch all machines at the same time without
overlap.
Feel free to reach out if you encounter any problems.

- Tobias

> ---
> PGP-Key: CDE74120  ☀  computing @ chaos claudius
> 

Re: ikev2 fails with mschap-v2

[Tobias Heider]

On Mon, Feb 21, 2022 at 09:12:27AM -0600, rea...@catastrophe.net wrote:
> On Mon, Feb 21, 2022 at 02:55:39PM +0100, Tobias Heider wrote:
> >On Sat, Feb 19, 2022 at 12:28:15AM -0600, rea...@catastrophe.net wrote:
> >> IKE is failing when I connect using a simple password defined in
> >> /etc/iked.conf. I'm connecting from a native Mac client...is 
> >> mschap-v2 on MacOS broken or are my configs wrong? Thanks in advance.
> >> 
> [..]
> >> /etc/iked.conf - fails with username/password
> >> ##
> >> user "testuser" "testpassword"
> >> ikev2 "ROAD_WARRIOR" esp \
> >>from 0.0.0.0/0 to 10.1.255.0/24 \
> >>peer any local vpn.company.com \
> >> srcid vpn.company.com \
> >> dstid mac-laptop \
> >> eap "mschap-v2" \
> >>config address 10.1.255.0/24 \
> >> config name-server 10.1.255.1 \
> >>tag "$name-$id"
> >> 
> >Hard to tell what's going wrong here. Looks like the mac ignores the IKE_AUTH
> >response and restarts the handshake.  I haven't seen any other reports about
> >problems with the mac implementation and i don't have one to test.
> >You could try enabling verbose logging with 'iked -dvvv' or
> >'ikectl log verbose' and see if that gives us any clues.
> 
> Here is the output of iked -dvvv

Looks all ok.  Is there any way to get logs from the mac?
It still looks like the other side just drops the AUTH response
for no obvious reason.

> 
> bash-5.1# iked -dvvv 
> create_ike: using signature for peer mac-laptop
> ikev2 "ROAD_WARRIOR" passive tunnel esp inet from 0.0.0.0/0 to 10.1.255.0/24 
> local 192.168.110.50 peer any ikesa enc aes-128-gcm enc aes-256-gcm prf 
> hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group 
> curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group 
> modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc 
> aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf 
> hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth 
> hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group 
> ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group 
> modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa 
> enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 
> auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid vpn.company.com 
> dstid mac-laptop lifetime 10800 bytes 4294967296 eap "MSCHAP_V2" config 
> address 10.1.255.0 config name-server 10.1.255.1 tag "$name-$id"
> /etc/iked.conf: loaded 2 configuration rules
> ca_privkey_serialize: type RSA_KEY length 1192
> 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 1192
> ca_getkey: received public key type RSA_KEY length 270
> ca_dispatch_parent: config reset
> ca_reload: loaded cert file vpn.company.com.crt
> ca_validate_cert: /C=US/ST=Anystate/L=Anytown/O=Company.COM/OU=Remote Network 
> Services/CN=vpn.company.com/emailAddress=r...@company.com unable to get local 
> issuer certificate
> ca_reload: local cert type RSA_KEY
> config_getocsp: ocsp_url none tolerate 0 maxage -1
> config_new_user: inserting new user testuser
> user "testuser" "testpassword"
> ikev2_dispatch_cert: updated local CERTREQ type RSA_KEY length 0
> config_getpolicy: received policy
> 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_getstatic: dpd_check_interval 60
> config_getstatic: no enforcesingleikesa
> config_getstatic: no fragmentation
> config_getstatic: mobike
> config_getstatic: nattport 4500
> config_getstatic: no stickyaddress
> policy_lookup: setting policy 'ROAD_WARRIOR'
> spi=0x2cb46a467283eb2e: recv IKE_SA_INIT req 0 peer 172.20.20.11:62336 local 
> 192.168.110.50:500, 604 bytes, policy 'ROAD_WARRIOR'
> ikev2_recv: ispi 0x2cb46a467283eb2e rspi 0x
> ikev2_policy2id: srcid FQDN/vpn.company.com length 23
> ikev2_pld_parse: header ispi 0x2cb46a467283eb2e rspi 0x 
> nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 
> 604 response 0
> ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 220
> ikev2_pld_sa: more 2 reserved 0 length 44 proposal #1 protoid IKE spi

Re: iked EAP account limit

[Tobias Heider]

On Mon, Feb 21, 2022 at 01:33:12PM +, n8dandy wrote:
> Hello there,
> 
> First of all, I would like to thank people involved with iked. It works 
> flawlessly, especially with Apple devices. Thanks for your work.
> In the near future, I plan to allow around 330 people to use this service. Do 
> you know how many accounts we can support with the "user" directive ? Is 
> there any limit ?
> 
> Kind regards
> 

I don't think there is a hard limit. 330 should work without problems.

Re: ikev2 fails with mschap-v2

[Tobias Heider]

On Sat, Feb 19, 2022 at 12:28:15AM -0600, rea...@catastrophe.net wrote:
> IKE is failing when I connect using a simple password defined in
> /etc/iked.conf. I'm connecting from a native Mac client...is 
> mschap-v2 on MacOS broken or are my configs wrong? Thanks in advance.
> 
> Working configuration and logs:
> 
> /etc/iked.conf - works with psk
> 
> ikev2 "ROAD_WARRIOR" esp \
>   from 0.0.0.0/0 to 10.1.255.0/24 \
>   peer any local vpn.company.com \
> srcid vpn.company.com \
> dstid mac-laptop \
> psk "ASDFASDFASDFASDF"
>   config address 10.1.255.0/24 \
> config name-server 10.1.255.1 \
>   tag "$name-$id"
> 
> spi=0x1d5c3d767b281592: recv IKE_SA_INIT req 0 peer 172.20.20.11:53784 local 
> 192.168.110.50:500, 604 bytes, policy 'ROAD_WARRIOR'
> spi=0x1d5c3d767b281592: ikev2_sa_responder_dh: want dh ECP_256, KE has 
> MODP_2048 spi=0x1d5c3d767b281592: ikev2_resp_recv: failed to negotiate IKE SA
> spi=0x1d5c3d767b281592: ikev2_add_error: INVALID_KE_PAYLOAD
> spi=0x1d5c3d767b281592: send IKE_SA_INIT res 0 peer 172.20.20.11:53784 local 
> 192.168.110.50:500, 38 bytes
> spi=0x1d5c3d767b281592: recv IKE_SA_INIT req 0 peer 172.20.20.11:53784 local 
> 192.168.110.50:500, 412 bytes, policy 'ROAD_WARRIOR'
> spi=0x1d5c3d767b281592: send IKE_SA_INIT res 0 peer 172.20.20.11:53784 local 
> 192.168.110.50:500, 240 bytes
> spi=0x1d5c3d767b281592: recv IKE_AUTH req 1 peer 172.20.20.11:56756 local 
> 192.168.110.50:4500, 560 bytes, policy 'ROAD_WARRIOR'
> spi=0x1d5c3d767b281592: assigned address 10.1.255.179 to FQDN/mac-laptop
> spi=0x1d5c3d767b281592: send IKE_AUTH res 1 peer 172.20.20.11:56756 local 
> 192.168.110.50:4500, 272 bytes, NAT-T
> spi=0x1d5c3d767b281592: ikev2_childsa_enable: loaded SPIs: 0xa60629d5, 
> 0x016966b2 (enc aes-256 auth hmac-sha2-256)
> spi=0x1d5c3d767b281592: ikev2_childsa_enable: loaded flows: 
> ESP-0.0.0.0/0=10.1.255.0/24(0)
> spi=0x1d5c3d767b281592: established peer 172.20.20.11:56756[FQDN/mac-laptop] 
> local 192.168.110.50:4500[FQDN/vpn.company.com] assigned 10.1.255.179 policy 
> 'ROAD_WARRIOR' as responder (enc aes-256 auth hmac-sha2-256 group ecp256 prf 
> hmac-sha2-256)
> 
> /etc/iked.conf - fails with username/password
> ##
> user "testuser" "testpassword"
> ikev2 "ROAD_WARRIOR" esp \
>   from 0.0.0.0/0 to 10.1.255.0/24 \
>   peer any local vpn.company.com \
> srcid vpn.company.com \
> dstid mac-laptop \
> eap "mschap-v2" \
>   config address 10.1.255.0/24 \
> config name-server 10.1.255.1 \
>   tag "$name-$id"
> 
> starting the daemon..
> 
> # iked -d -v
> ikev2 "ROAD_WARRIOR" passive tunnel esp inet from 0.0.0.0/0 to
> 10.1.255.0/24 local 192.168.110.50 peer any ikesa enc aes-128-gcm enc
> aes-256-gcm prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf
> hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group
> modp4096 group modp3072 group modp2048 group modp1536 group modp1024 ikesa
> enc aes-256 enc aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf
> hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth
> hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group curve25519 group
> ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group
> modp2048 group modp1536 group modp1024 childsa enc aes-128-gcm enc
> aes-256-gcm group none esn noesn childsa enc aes-256 enc aes-192 enc aes-128
> auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1
> group none esn noesn srcid vpn.company.com dstid mac-laptop lifetime 10800
> bytes 4294967296 eap "MSCHAP_V2" config address 10.1.255.0 config
> name-server 10.1.255.1 tag "$name-$id"
> user "testuser" "testpassword"
> 
> [..]
> 
> spi=0x5a37ce60a7490c70: recv IKE_SA_INIT req 0 peer 172.20.20.11:64235 local 
> 192.168.110.50:500, 604 bytes, policy 'ROAD_WARRIOR'
> spi=0x5a37ce60a7490c70: ikev2_sa_responder_dh: want dh ECP_256, KE has 
> MODP_2048
> spi=0x5a37ce60a7490c70: ikev2_resp_recv: failed to negotiate IKE SA
> spi=0x5a37ce60a7490c70: ikev2_add_error: INVALID_KE_PAYLOAD
> spi=0x5a37ce60a7490c70: send IKE_SA_INIT res 0 peer 172.20.20.11:64235 local 
> 192.168.110.50:500, 38 bytes
> spi=0x5a37ce60a7490c70: recv IKE_SA_INIT req 0 peer 172.20.20.11:64235 local 
> 192.168.110.50:500, 412 bytes, policy 'ROAD_WARRIOR'
> spi=0x5a37ce60a7490c70: send IKE_SA_INIT res 0 peer 172.20.20.11:64235 local 
> 192.168.110.50:500, 265 bytes
> spi=0x5a37ce60a7490c70: recv IKE_AUTH req 1 peer 172.20.20.11:58037 local 
> 192.168.110.50:4500, 512 bytes, policy 'ROAD_WARRIOR'
> spi=0x5a37ce60a7490c70: ikev2_pld_eap: REQUEST id 0 length 5 EAP-IDENTITY
> spi=0x5a37ce60a7490c70: send IKE_AUTH res 1 peer 172.20.20.11:58037 local 
> 192.168.110.50:4500, 1472 bytes, NAT-T
> spi=0x92b7ead070f25c61: recv IKE_SA_INIT req 0 peer 172.20.20.11:64235 local 
> 192.168.110.50:500, 604 bytes, policy 'ROAD_WARRIOR'
> spi=0x92b7ead070f25c61: 

Re: did 70-006_x509 break ikectl ca ?

[Tobias Heider]

On Sun, Dec 12, 2021 at 10:01:20PM +0100, Harald Dunkel wrote:
> Hi folks,
> 
> since syspatch 70-006_x509 and a reboot IKEv2 between 2 OpenBSD clusters
> (2 hosts on each end, carp interface, passive by default, managed via
> sasyncd) appears to be broken. /var/log/messages says
> 
> Dec 12 21:40:28 gate5a iked[57676]: spi=0x5a7c2732b4b355e6: 
> ikev2_dispatch_cert: peer certificate is invalid
> 
> certificates have been generated using ikectl ca.
> 
> How comes? I haven't changed the ca or the ike configuration since
> 6.8.
> 
> Unfortunately rolling back the syspatch or issuing new certificates
> did not help. I am stuck and desperate.
> 
> 
> Every helpful comment is highly appreciated.
> 
> Harri

Hi Harald,

i haven't heard of any problems with the syspatch you mention and I didn't
manage to reproduce your problem on my 7.0 machine.  From your description
I'm assuming all four machines are running syspatched 7.0.

Some ideas:
- to verify that this is a libcrypto problem, try
  'openssl verify -CAfile /path/to/ca /path/to/cert' and see if still fails.
- You are saying newly generated certs don't work. Did you modify
  '/etc/ssl/ikeca.cnf'?  If yes, see if it works with the original config.
- This is just a guess, but there were a several changes in recent libcrypto
  versions that made the certificate parsing stricter. Does your cert maybe
  have multiple extensions of the same type (e.g. multiple subjectAltNames)?

This is all I can say without seeing the actual certificates and/or iked log.

- Tobias

Re: iked: "rsa routines:CRYPTO_internal:block type is not 01"

[Tobias Heider]

Hey Georg,

The configs look ok to me.  The error message and your description
sound like you might have forgotten to copy the certificate private
keys to /etc/iked/private/local.key

On Wed, Dec 01, 2021 at 08:50:58PM +0100, Georg Pfuetzenreuter wrote:
> Hello,
> 
> I try to connect two OpenBSD 7.0 systems using iked and kindly seek
> assistance.
> 
> The IKE_AUTH process fails with the following:
> router03 iked[15809]: ca_sslerror: dsa_verify_final: error:04FFF06A:rsa
> routines:CRYPTO_internal:block type is not 01
> router03 iked[15809]: ca_sslerror: dsa_verify_final: error:04FFF072:rsa
> routines:CRYPTO_internal:padding check failed
> router03 iked[15809]: spi=0x47b7e91158cd1425: ikev2_auth_verify:
> ikev2_msg_authverify failed
> router03 iked[15809]: spi=0x47b7e91158cd1425: ikev2_send_auth_failed:
> authentication failed for FQDN/router04.example.com
> 
> router04 iked[14683]: spi=0x47b7e91158cd1425: sa_free: authentication failed
> notification from peer
> 
> This is the iked.conf for router03:
> ikev2 'foo' passive transport esp proto gre \
> from 7x.xx.xx.x5 to 5x.xx.xx.x3 \
> local 7x.xx.xx.x5 peer 5x.xx.xx.x3 \
> ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group brainpool384 \
> childsa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group brainpool384
> \
> srcid router03.example.com
> 
> This is the iked.conf for router04:
> ikev2 'bar' active transport esp proto gre \
> from 5x.xx.xx.x3 to 7x.xx.xx.x5 \
> local 5x.xx.xx.x3 peer 7x.xx.xx.x5 \
> ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group brainpool384 \
> childsa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group brainpool384
> \
> srcid router04.example.com
> 
> I attempted the following routes of authentication:
> - X.509: Creating a new CA on router04, installing the CA and client
> certificates on router03.
> - X.509: Installing the existing CA from router03 on router04 with a
> respective client certificate for the latter.
> - Public Key: Installing the public keys as described in iked(8).
> 
> And the following configuration variations:
> - Specifying of ikeauth ecdsa384 or ikeauth rsa on both sides.
> - Removing the ikesa and childsa declarations on both sides.
> 
> The X.509 attempts were performed using CA's and client certificates
> manually requested and signed using openssl, as well as using CA's and
> client certificates generated using ikectl.
> In the X.509 attempts, the srcid was made sure to be present in the SAN's of
> the client certificate.
> In the public key attempts, the srcid was made sure to be the name of the
> public key in the fqdn directory.
> 
> I would appreciate any advice.
> Please note that I am able to successfully connect both iked instances to
> StrongSwan endpoints - only the authentication between the two iked
> instances themselves fails.
> 
> Kind regards
> Georg
> 

Re: iked choosing the wrong policy?

[Tobias Heider]

On Tue, Jul 27, 2021 at 11:18:53AM +0200, Patrick Wildt wrote:
> On Tue, Jul 27, 2021 at 09:55:34AM +0200, Claudio Jeker wrote:
> > On Tue, Jul 27, 2021 at 07:32:09AM -, Stuart Henderson wrote:
> > > On 2021-07-27, Vladimir Nikishkin  wrote:
> > > > Hello, everyone.
> > > >
> > > > This is my iked.conf:
> > > >
> > > > ```
> > > > ikev2 "for-phone" passive esp \
> > > > from any to 10.0.3.2/32 \
> > > > local egress peer any \
> > > ...
> > > > dstid phone.mine \
> > > 
> > > > ikev2 "for-laptop" passive esp \
> > > > from any to 10.0.3.3/32 \
> > > > local egress peer any \
> > > ...
> > > > dstid laptop.mine \
> > > 
> > > Two policies with "peer any" doesn't work.
> > > 
> > > > How to correct the setup?
> > > 
> > > Maybe it's possible by modifying the code, I'm not sure if the
> > > id is sent early enough though so it might not be possible.
> > 
> > This is one of the biggest annoyances of iked. It does not even help to
> > use different IPs and 'local' to split up the rules. Would love if someone
> > would fix this.
> 
> Using differnt IPs for local should work.  The trouble is not in iked,
> but in the IKEv2 protocol.  The IDs are only shared in the second part
> of the handshake.  So until then, there's no way for the daemon to find
> the correct policy, apart from looking at local or peer address.
> 
> That's why the settings for the IKE-SA should be similar across all
> policies thate could be valid, and the Child-SA can then (afaik) have
> different settings.
> 
> But still, using different IPs for local should work in -current.
> 

The protocol is tricky but this SHOULD work as long as the policies use 
different
dstids and it does so in my tests.

I am not sure what exactly causes it to fail in this particular setup.
Some more info such as a verbose log of the handshake and the OpenBSD
version would be helpful to figure out what's wrong.

Re: after upgrade to 6.9, iked does not pass traffic

[Tobias Heider]

On Mon, May 31, 2021 at 02:31:22PM +, Leclerc, Sebastien wrote:
> > > > If that doesn't help you could share the output of 'ipsecctl -sa' to 
> > > > find
> > > > out if the IPsec SAs or flows are the problem.
> > > 
> > > That may be the problem, there is nothing between 192.168.1.109 and 
> > > 192.168.9.101 :
> > > (192.168.8.2 is the firewall interface that 192.168.1.109 is connecting 
> > > to,
> > > 192.168.9.101 is what the vpn client is trying to communicate with)
> > > 
> > > # ipsecctl -sa
> > > FLOWS:
> > > No flows
> > > 
> > > SAD:
> > > esp tunnel from 192.168.8.2 to 192.168.1.109 spi 0x0e7b0e8b auth 
> > > hmac-sha1 enc aes-256
> > > esp tunnel from 192.168.1.109 to 192.168.8.2 spi 0x6830eab4 auth 
> > > hmac-sha1 enc aes-256
> 
> > Ok, so this seems to be the cause.  From your log snippet i can see that
> > there must have been SAs at some point because it shows an
> > "ikev2_childsa_enable" line.
> > Try running iked with -vv. Maybe the verbose log contains an error message
> > that helps us find out what's wrong.
> 
> The SAs seem to be only the first "from" clause (from 192.168.8.2 to 
> 192.168.1.109), which are the VPN endpoints, not the second one, which covers 
> the network behind the OpenBSD machine, and the IP assigned to the Windows 
> machine in this same subnet (arp-proxied).

The SAs are ok but the flows are not loaded correctly.  Looks like it is an
actual bug in 6.9.  It is triggered by the 'config address' line in your
configuration, so working around that one line would be one solution.

The diff below should also fix your problem and allow you to keep your config
unchanged.

Index: ikev2.c
===
RCS file: /mount/openbsd/cvs/src/sbin/iked/ikev2.c,v
retrieving revision 1.319
diff -u -p -r1.319 ikev2.c
--- ikev2.c 23 Mar 2021 21:31:29 -  1.319
+++ ikev2.c 1 Jun 2021 09:27:08 -
@@ -7062,7 +7062,7 @@ ikev2_cp_fixaddr(struct iked_sa *sa, str
naddr = (sa->sa_cp == IKEV2_CP_REQUEST) ?
sa->sa_addrpool : sa->sa_cp_addr;
if (naddr == NULL)
-   return (-1);
+   return (-2);
in4 = (struct sockaddr_in *)>addr;
if (in4->sin_addr.s_addr)
return (-2);
@@ -7074,7 +7074,7 @@ ikev2_cp_fixaddr(struct iked_sa *sa, str
naddr = (sa->sa_cp == IKEV2_CP_REQUEST) ?
sa->sa_addrpool6 : sa->sa_cp_addr6;
if (naddr == NULL)
-   return (-1);
+   return (-2);
in6 = (struct sockaddr_in6 *)>addr;
if (!IN6_IS_ADDR_UNSPECIFIED(>sin6_addr))
return (-2);

Re: after upgrade to 6.9, iked does not pass traffic

[Tobias Heider]

On Mon, May 31, 2021 at 12:20:29PM +, Leclerc, Sebastien wrote:
> > I'm not sure about that bge0 rule.  iked.conf(5) mentions ipencap only
> > in the context of enc interfaces.
> > You could try adding 'set skip on enc0' to find out if pf is the problem.
> 
> That rule has been the same for some years now, without problem. I tried
> adding set skip on enc0, but the problem persists.
> 
> > If that doesn't help you could share the output of 'ipsecctl -sa' to find
> > out if the IPsec SAs or flows are the problem.
> 
> That may be the problem, there is nothing between 192.168.1.109 and 
> 192.168.9.101 :
> (192.168.8.2 is the firewall interface that 192.168.1.109 is connecting to,
> 192.168.9.101 is what the vpn client is trying to communicate with)
> 
> # ipsecctl -sa
> FLOWS:
> No flows
> 
> SAD:
> esp tunnel from 192.168.8.2 to 192.168.1.109 spi 0x0e7b0e8b auth hmac-sha1 
> enc aes-256
> esp tunnel from 192.168.1.109 to 192.168.8.2 spi 0x6830eab4 auth hmac-sha1 
> enc aes-256

Ok, so this seems to be the cause.  From your log snippet i can see that
there must have been SAs at some point because it shows an
"ikev2_childsa_enable" line.
Try running iked with -vv. Maybe the verbose log contains an error message
that helps us find out what's wrong.

Re: after upgrade to 6.9, iked does not pass traffic

[Tobias Heider]

On Fri, May 28, 2021 at 11:56:54AM +, Leclerc, Sebastien wrote:
> >It looks like 'keep state (if-bound)' iked.conf(5) is not present or being 
> >respected on the return traffic to the VPN device/firewall from your 
> >internal network.  ICMP traffic is coming into the VPN device >encrypted, 
> >being decrypted and passed to the destination.  The destination responds 
> >back but the VPN device is not taking those responses and pushing them back 
> >through enc0.
> 
> Thank you for your response Jason.
> Here is the relevant pf.conf configuration, keep state (if-bound) is there, 
> so I don't think it's the cause of the problem :
> 
> pass inet proto udp from 192.168.1.109 to bge0 port 500
> pass inet proto esp from 192.168.1.109 to bge0
> pass on bge0 proto ipencap keep state (if-bound)
> pass inet from 192.168.9.208 to vlan0:network
> 

I'm not sure about that bge0 rule.  iked.conf(5) mentions ipencap only
in the context of enc interfaces.
You could try adding 'set skip on enc0' to find out if pf is the problem.

If that doesn't help you could share the output of 'ipsecctl -sa' to find
out if the IPsec SAs or flows are the problem.

Re: IKEv2: CHILD_SA is not created

[Tobias Heider]

On Wed, May 12, 2021 at 12:06:21PM +0300, Денис Давыдов wrote:
> I tried to specify an explicit parameter -T to disable NAT-Traversal
> auto-detection and use `local' parameter. Also according to your advice
> tried a configuration like this:
> 
> ikev2 crypto-primary active esp \
>   from any to any \
>   local 1.1.1.1 peer 7.7.7.7 \
>   ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group modp2048
> \
>   childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
>   ikelifetime 86400 lifetime 28800 \
>   psk "secret"
> 
> And I got:
> 
> May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_pld_payloads: decrypted
> payload TSi nextpayload TSr critical 0x00 length 8
> May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_pld_tss: count 1 length 0
> May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_validate_ts: malformed
> payload: too short for header (0 < 8)
> May 12 08:45:17 crypto-gw2 iked[17640]: ikev2_validate_pld: malformed
> payload: shorter than minimum header size (0 < 4)

This looks like you're running < 6.9 where any doesn't work for traffic
selectors.  Either try using 0.0.0.0/0 instead or even better update
to the latest version.

> 
> Full log: https://pastebin.com/MLC4VXSs
> 
> P.S. Tried removing the ikelifetime and lifetime parameters as well. Did
> not help, the same behavior.
> 
> On Tue, May 11, 2021 at 7:43 PM Tobias Heider 
> wrote:
> 
> > From my limited understanding of cisco ASA configs i can't see any
> > obvious problems.
> >
> > You could try setting 'from any to any' on your side to see how the server
> > responds. If the server is configured to narrow traffic selectors, the
> > handshake
> > should succeed and the log will tell you the exact traffic selectors you
> > need
> > in your config (look for ikev2_pld_ts in the verbose log).
> >
> > On Tue, May 11, 2021 at 01:47:53PM +0300, Денис Давыдов wrote:
> > > Tobias,
> > >
> > > The remote side gave me their Cisco ASA 5585 settings and they showed the
> > > logs:
> > >
> > > object network Svc_2_2_2_2
> > > host 2.2.2.2
> > > object network Svc_3_3_3_3
> > > host 3.3.3.3
> > > crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA2
> > > protocol esp encryption aes-256
> > > protocol esp integrity sha-256
> > >
> > > object-group network Customer
> > > description Customer
> > > network-object 10.21.139.8 255.255.255.252
> > > object-group network ISP-to-Customer
> > > description ISP-to-Customer
> > > network-object object Svc_2_2_2_2
> > > network-object object Svc_3_3_3_3
> > > access-list outside_cryptomap_2470 extended permit ip object-group
> > > ISP-to-Customer object-group Customer
> > > crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA2
> > > crypto map outside_map 2470 match address outside_cryptomap_2470
> > > crypto map outside_map 2470 set pfs group14
> > > crypto map outside_map 2470 set connection-type answer-only
> > > crypto map outside_map 2470 set peer 1.1.1.1
> > > crypto map outside_map 2470 set ikev2 ipsec-proposal ESP-AES256-SHA2
> > > crypto map outside_map 2470 set nat-t-disable
> > > crypto map outside_map 2470 set reverse-route
> > > crypto ikev2 policy 100
> > > encryption aes-256
> > > integrity sha
> > > group 21 20 19 24 14 5 2
> > > prf sha
> > > lifetime seconds 28800
> > > tunnel-group 1.1.1.1 type ipsec-l2l
> > > tunnel-group 1.1.1.1 general-attributes
> > > default-group-policy GroupPolicy-Def-IKE2
> > > tunnel-group 1.1.1.1 ipsec-attributes
> > > ikev1 pre-shared-key *
> > > ikev2 remote-authentication pre-shared-key *
> > > ikev2 local-authentication pre-shared-key *
> > >  ikev2 local-authentication pre-shared-key *
> > >
> > > asa-8m-a5-820-l2l/sec/act# sh logg | i 1.1.1.1
> > > May 11 2021 13:35:11: %ASA-7-609001: Built local-host outside:1.1.1.1
> > > May 11 2021 13:35:11: %ASA-6-302015: Built inbound UDP connection
> > > 1392894457 for outside:1.1.1.1/500 (1.1.1.1/500) to identity:7.7.7.7/500
> > (
> > > 7.7.7.7/500)
> > > May 11 2021 13:35:11: %ASA-7-713906: IKE Receiver: Packet received on
> > > 7.7.7.7:500 from 1.1.1.1:500
> > > May 11 2021 13:35:11: %ASA-5-750002: Local:7.7.7.7:500 Remote:
> > 1.1.1.1:500
> > > Username:Unknown IKEv2 Received a IKE_INIT_SA request
> > > May 11 2021 13:35:11: %ASA-7-713906: IKE Receiver: Packet received on
> > > 7.7.7.7:500 from 1.1.1.1:500
&g

Re: IKEv2: CHILD_SA is not created

[Tobias Heider]

>From my limited understanding of cisco ASA configs i can't see any
obvious problems.

You could try setting 'from any to any' on your side to see how the server
responds. If the server is configured to narrow traffic selectors, the handshake
should succeed and the log will tell you the exact traffic selectors you need
in your config (look for ikev2_pld_ts in the verbose log).

On Tue, May 11, 2021 at 01:47:53PM +0300, Денис Давыдов wrote:
> Tobias,
> 
> The remote side gave me their Cisco ASA 5585 settings and they showed the
> logs:
> 
> object network Svc_2_2_2_2
> host 2.2.2.2
> object network Svc_3_3_3_3
> host 3.3.3.3
> crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA2
> protocol esp encryption aes-256
> protocol esp integrity sha-256
> 
> object-group network Customer
> description Customer
> network-object 10.21.139.8 255.255.255.252
> object-group network ISP-to-Customer
> description ISP-to-Customer
> network-object object Svc_2_2_2_2
> network-object object Svc_3_3_3_3
> access-list outside_cryptomap_2470 extended permit ip object-group
> ISP-to-Customer object-group Customer
> crypto ipsec ikev2 ipsec-proposal ESP-AES256-SHA2
> crypto map outside_map 2470 match address outside_cryptomap_2470
> crypto map outside_map 2470 set pfs group14
> crypto map outside_map 2470 set connection-type answer-only
> crypto map outside_map 2470 set peer 1.1.1.1
> crypto map outside_map 2470 set ikev2 ipsec-proposal ESP-AES256-SHA2
> crypto map outside_map 2470 set nat-t-disable
> crypto map outside_map 2470 set reverse-route
> crypto ikev2 policy 100
> encryption aes-256
> integrity sha
> group 21 20 19 24 14 5 2
> prf sha
> lifetime seconds 28800
> tunnel-group 1.1.1.1 type ipsec-l2l
> tunnel-group 1.1.1.1 general-attributes
> default-group-policy GroupPolicy-Def-IKE2
> tunnel-group 1.1.1.1 ipsec-attributes
> ikev1 pre-shared-key *
> ikev2 remote-authentication pre-shared-key *
> ikev2 local-authentication pre-shared-key *
>  ikev2 local-authentication pre-shared-key *
> 
> asa-8m-a5-820-l2l/sec/act# sh logg | i 1.1.1.1
> May 11 2021 13:35:11: %ASA-7-609001: Built local-host outside:1.1.1.1
> May 11 2021 13:35:11: %ASA-6-302015: Built inbound UDP connection
> 1392894457 for outside:1.1.1.1/500 (1.1.1.1/500) to identity:7.7.7.7/500 (
> 7.7.7.7/500)
> May 11 2021 13:35:11: %ASA-7-713906: IKE Receiver: Packet received on
> 7.7.7.7:500 from 1.1.1.1:500
> May 11 2021 13:35:11: %ASA-5-750002: Local:7.7.7.7:500 Remote:1.1.1.1:500
> Username:Unknown IKEv2 Received a IKE_INIT_SA request
> May 11 2021 13:35:11: %ASA-7-713906: IKE Receiver: Packet received on
> 7.7.7.7:500 from 1.1.1.1:500
> May 11 2021 13:35:11: %ASA-5-750007: Local:7.7.7.7:500 Remote:1.1.1.1:500
> Username:1.1.1.1 IKEv2 SA DOWN. Reason: application initiated
> May 11 2021 13:35:11: %ASA-4-113019: Group = 1.1.1.1, Username = 1.1.1.1,
> IP = 1.1.1.1, Session disconnected. Session Type: LAN-to-LAN, Duration:
> 0h:05m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: IKE Delete
> May 11 2021 13:35:11: %ASA-5-750006: Local:7.7.7.7:500 Remote:1.1.1.1:500
> Username:1.1.1.1 IKEv2 SA UP. Reason: New Connection Established
> May 11 2021 13:35:11: %ASA-6-113009: AAA retrieved default group policy
> (GroupPolicy-Def-IKE2) for user = 1.1.1.1
> 
> 
> P.S. This is strange, but with another provider, which has the Cisco ASA
> 5585-SSP10, there are no such problems.
> 
> --
> Sincerely,
> Denis
> 
> On Fri, May 7, 2021 at 1:10 PM Tobias Heider 
> wrote:
> 
> > On Fri, May 07, 2021 at 12:17:35PM +0300, Денис Давыдов wrote:
> > > Hello all,
> > >
> > > I can't understand why I got SA_INIT timeout:
> > > May  5 13:18:54 crypto-gw2 iked[65530]: spi=0x73bcd531eb2e8899: sa_free:
> > > SA_INIT timeout
> > >
> > > 1.1.1.1 (crypto-gw2) - my host
> > > 7.7.7.7 - our isp provider (some of cisco devices)
> > >
> > > /etc/iked.conf (on 1.1.1.1):
> > >
> > > ikev2 crypto-primary active esp \
> > >   from 10.21.139.8/30 to 2.2.2.2 \
> > >   from 10.21.139.8/30 to 3.3.3.3 \
> > >   peer 7.7.7.7 \
> > >   ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group
> > modp2048
> > > \
> > >   childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
> > >   ikelifetime 86400 lifetime 28800 \
> > >   psk "secret"
> > >
> > > The remote side claims to have the same settings.
> > >
> > > crypto-gw2# ikectl sh sa | grep 7.7.7.7
> > > iked_sas: 0xb0e1878b7d0 rspi 0x2d606f017d098928 ispi 0xd0497626849535cd
> > > 1.1.1.1:500->7.7.7.7:500[] AUTH_SUCCESS i nexti 0x0
> > pol
> > > 0xb0e9b38d000
> > >
> > > Why CHILD_SA is not being created? I tried to figure it out from the logs
> > > but couldn't.
> >
> >
> > It looks like the peer sends its IKE_AUTH reply without SA payload but
> > with a TS_UNACCEPTABLE notification.
> > The most likely cause is that your "from ... to ..." configuration is
> > incompatible with the configuration of your peer.
> >
> > Thanks for the report, I will see how I can make this error more obvious
> > in the logs.
> >

Re: IKEv2: CHILD_SA is not created

[Tobias Heider]

On Fri, May 07, 2021 at 12:17:35PM +0300, Денис Давыдов wrote:
> Hello all,
> 
> I can't understand why I got SA_INIT timeout:
> May  5 13:18:54 crypto-gw2 iked[65530]: spi=0x73bcd531eb2e8899: sa_free:
> SA_INIT timeout
> 
> 1.1.1.1 (crypto-gw2) - my host
> 7.7.7.7 - our isp provider (some of cisco devices)
> 
> /etc/iked.conf (on 1.1.1.1):
> 
> ikev2 crypto-primary active esp \
>   from 10.21.139.8/30 to 2.2.2.2 \
>   from 10.21.139.8/30 to 3.3.3.3 \
>   peer 7.7.7.7 \
>   ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group modp2048
> \
>   childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
>   ikelifetime 86400 lifetime 28800 \
>   psk "secret"
> 
> The remote side claims to have the same settings.
> 
> crypto-gw2# ikectl sh sa | grep 7.7.7.7
> iked_sas: 0xb0e1878b7d0 rspi 0x2d606f017d098928 ispi 0xd0497626849535cd
> 1.1.1.1:500->7.7.7.7:500[] AUTH_SUCCESS i nexti 0x0 pol
> 0xb0e9b38d000
> 
> Why CHILD_SA is not being created? I tried to figure it out from the logs
> but couldn't.


It looks like the peer sends its IKE_AUTH reply without SA payload but
with a TS_UNACCEPTABLE notification.
The most likely cause is that your "from ... to ..." configuration is
incompatible with the configuration of your peer.

Thanks for the report, I will see how I can make this error more obvious
in the logs.

Re: OpenIKED and Strongswan

[Tobias Heider]

On Mon, Feb 22, 2021 at 03:59:53PM +0100, Riccardo Giuntoli wrote:
> Ok. In the log you can appreciate.
> 
> UK-HOST one OpenBSD machine connected to three openbsd, one mikrotik and
> one VyOS. The VyOS is CAT-HOST
> 
> Kind regards

The log looks fine but it doesn't seem to contain the error message you
sent earlier.
Can you try reproducing the bug and then send a log containing the error
message and everything that happened before?

> 
> 
> On Mon, Feb 22, 2021 at 12:02 PM Stuart Henderson 
> wrote:
> 
> > On 2021-02-22, Riccardo Giuntoli  wrote:
> > > Ok I've got the same error on three different OpenBSD, tell me what error
> > > do you want or if you want an access.
> >
> > It would be a good start to run iked in the foreground with iked -vvd and
> > show the log from there.
> >
> >
> >
> 
> -- 
> Name: Riccardo Giuntoli
> Email: tag...@gmail.com
> Location: sant Pere de Ribes, BCN, Spain
> PGP Key: 0x67123739
> PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739
> Key server: hkp://wwwkeys.eu.pgp.net

> create_ike: using signature for peer --FR--
> create_ike: using signature for peer 
> ikev2 "--CAT-HOST--" passive transport esp proto gre inet from --UK-- to 
> --CAT-- local --UK-- peer any ikesa enc aes-256 prf 
> hmac-sha2-256,hmac-sha2-384,hmac-sha2-512,hmac-sha1 auth hmac-sha2-256 group 
> ecp256 childsa enc aes-256 auth hmac-sha2-256 group ecp256 esn,noesn srcid 
> --UK-ID-- ikelifetime 86400 lifetime 3600 bytes 536870912 signature
> /etc/iked.conf: loaded 4 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
> ca_reload: loaded ca file ca.crt
> ca_reload: /C=FR/ST=Seine-Saint-Denis/L=Aubervilliers/O=Telecom 
> Lobby/OU=VPNC/CN=--CA-HOST--
> ca_reload: loaded 1 ca certificate
> ca_reload: loaded cert file --FR-HOST--.crt
> ca_reload: loaded cert file --UK-HOST--.crt
> config_getpolicy: received policy
> config_getpolicy: received policy
> config_getpolicy: received policy
> config_getpolicy: received policy
> 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_getstatic: dpd_check_interval 15
> config_getstatic: no enforcesingleikesa
> config_getstatic: no fragmentation
> config_getstatic: mobike
> config_getstatic: nattport 4500
> ca_validate_cert: /C=FR/ST=Seine-Saint-Denis/L=Aubervilliers/O=Telecom 
> Lobby/OU=VPNC/CN=--FR-HOST-- ok
> ca_validate_cert: /C=UK/ST=England/L=London/O=Telecom 
> Lobby/OU=VPNC/CN=--UK-HOST-- ok
> ca_reload: local cert type X509_CERT
> config_getocsp: ocsp_url none tolerate 0 maxage -1
> ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
> ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
> policy_lookup: setting policy '--CAT-HOST--'
> spi=0xc5881d3ed32f5801: recv INFORMATIONAL req 4428 peer --FR--:500 local 
> --UK--:500, 96 bytes, policy '--CAT-HOST--'
> ikev2_recv: ispi 0xc5881d3ed32f5801 rspi 0xfcad33aa65954d8e
> ikev2_init_recv: unknown SA
> ikev2_init_ike_sa: initiating "--FR-HOST--"
> ikev2_policy2id: srcid UFQDN/--UK-ID-- length 31
> ikev2_add_proposals: length 68
> ikev2_next_payload: length 72 nextpayload KE
> ikev2_next_payload: length 104 nextpayload NONCE
> ikev2_next_payload: length 36 nextpayload NOTIFY
> ikev2_nat_detection: local source 0xf2043da59221143f 0x 
> --UK--:500
> ikev2_next_payload: length 28 nextpayload NOTIFY
> ikev2_nat_detection: local destination 0xf2043da59221143f 0x 
> --FR--:500
> ikev2_next_payload: length 28 nextpayload NOTIFY
> ikev2_next_payload: length 14 nextpayload NONE
> ikev2_pld_parse: header ispi 0xf2043da59221143f rspi 0x 
> nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 
> 310 response 0
> ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 72
> ikev2_pld_sa: more 0 reserved 0 length 68 proposal #1 protoid IKE spisize 0 
> xforms 7 spi 0
> ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128
> 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 8 type DH id ECP_384
> 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_SHA2_384
> ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_512
> ikev2_pld_xform: more 0 reserved 0 length 8 type PRF id HMAC_SHA1
> ikev2_pld_payloads: payload KE nextpayload NONCE critical 0x00 length 104
> ikev2_pld_ke: dh group ECP_384 reserved 0
> ikev2_pld_payloads: 

Re: OpenIKED and Strongswan

[Tobias Heider]

On Mon, Feb 22, 2021 at 09:06:58AM +0100, Riccardo Giuntoli wrote:
> I there I've got a lot of problems putting a IKE2 point to point connection
> stable between OpenBSD/OpenIKED and VyOS/Strongswan.
> 
> Basically OpenBSD is a transport GRE in passive mode. Strongswan active GRE
> transport. Gre tunnel is builded above and keepalive work in all the two
> sides, because I've changed the beaviour of the tun interface in linux.
> 
> This is the error that I've got also in the OpenBSD side:
> 
> Feb 22 07:54:34 ganesha iked[26646]: spi=0x53365c1f26b25ca8:
> ikev2_ike_sa_rekey: busy, delaying rekey
> Feb 22 07:54:34 ganesha iked[26646]: spi=0xbbc576f1b7bbeff8:
> ikev2_ike_sa_rekey: busy, delaying rekey
> Feb 22 07:54:35 ganesha iked[26646]: pfkey_sa_lookup: message: No such
> process
> Feb 22 07:54:35 ganesha iked[26646]: pfkey_sa_lookup: message: No such
> process
> Feb 22 07:54:38 ganesha iked[26646]: spi=0xa74b9d54a7346659:
> ikev2_ike_sa_rekey: busy, delaying rekey
> Feb 22 07:54:38 ganesha iked[26646]: pfkey_sa_lookup: message: No such
> process
> Feb 22 07:54:38 ganesha iked[26646]: pfkey_sa_lookup: message: No such
> process
> Feb 22 07:54:39 ganesha iked[26646]: spi=0xb1cc5054712c2e6e:
> ikev2_ike_sa_rekey: busy, delaying rekey
> Feb 22 07:54:40 ganesha iked[26646]: spi=0x56465bd460d16d54:
> ikev2_ike_sa_rekey: busy, delaying rekey
> Feb 22 07:54:40 ganesha iked[26646]: pfkey_sa_lookup: message: No such
> process
> 

I don't see any obvious misconfiguration so this might be a bug,
but without the log i won't be able to help.

- Tobias

> 
> Here you are the Strongswan configuration:
> 
> conn 
> keyexchange=ikev2
> type=transport
> auto=start
> reauth=no
> ikelifetime=1h
> dpdaction=restart
> dpddelay=15
> dpdtimeout=1
> closeaction=restart
> 
> left=%defaultroute
> leftsourceip=%config4
> leftauth=pubkey
> leftid=%indra@
> leftprotoport=gre
> leftupdown=/config/ipsec/ESJP-updown.sh
> 
> right=
> rightsubnet=
> rightauth=pubkey
> rightid=%j
> rightcert=/etc/ipsec.d/certs/.crt
> rightprotoport=gre
> 
> #!/bin/bash
> 
> set -o nounset
> set -o errexit
> 
> TUN_IFACE="tun2"
> 
> case "${PLUTO_VERB}" in
> up-host)
> echo "Putting interface ${TUN_IFACE} up"
> ifconfig $TUN_IFACE up
> echo "Disabling IPsec policy (SPD) for ${TUN_IFACE}"
> sysctl -w "net.ipv4.conf.${TUN_IFACE}.disable_policy=1"
> echo "Accepting gre keepalive"
> sysctl -w "net.ipv4.conf.${TUN_IFACE}.accept_local=1"
> ;;
> down-host)
> ifconfig $TUN_IFACE down
> ;;
> esac
> 
> IKE is checked with DPD
> SA is checked with te script
> 
> above also a cron script acting in this way:
> 
> #!/bin/bash
> ROUTER_IP=
> IPSEC=""
> GRE="tun2"
> 
> PING_RESULT=$(fping -I$GRE $ROUTER_IP 2>&1)
> ALIVE="alive"
> STATUS=$(ipsec status $IPSEC)
> ESTABLISED="INSTALLED"
> 
> if [[ "$PING_RESULT" != *"$ALIVE"* ]]; then
> if [[ "$STATUS" == *"$ESTABLISHED"* ]]; then
> ipsec stroke down-nb $IPSEC
> ipsec up $IPSEC
> else
> ipsec up $IPSEC
> fi
> fi
> 
> In the OpenBSD side:
> 
> set dpd_check_interval 15
> ikev2 "" passive transport \
> proto gre \
> from  to \
> local jpeer any \
> ikesa uth hmac-sha2-256 enc aes-256 group ecp256  \
> childsa auth hmac-sha2-256 enc aes-256 group ecp256 \
> srcid "shiva@"  \
> ikelifetime 86400 lifetime 3600
> 
> root@shiva:/etc# cat hostname.gre1
> 
> 
> 
> description ""
> keepalive 5 2
> mtu 1392
> !ifconfig gre1 4  netmask 0xfffc up
> !ifconfig gre1 tunnel  
> root@shiva:/etc#
> 
> And some ifstated to check keepalive status.
> 
> Any suggestions?
> 
> -- 
> Name: Riccardo Giuntoli
> Email: tag...@gmail.com
> Location: sant Pere de Ribes, BCN, Spain
> PGP Key: 0x67123739
> PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739
> Key server: hkp://wwwkeys.eu.pgp.net

Re: iked(8) CREATE_CHILD_SA successful at initial connection time, fail at rekey interval

[Tobias Heider]

Hi,

looks like a PFS problem.

Here's where it fails:
> Jan 26 18:48:30 strannik iked[41041]: spi=0x6184b254a8e8d175:
> ikev2_log_proposal: ESP #1 DH=MODP_2048

At the moment, PFS groups must be enabled manually.
Try this:

ikev2 "home" passive esp inet \
from 10.0.10.0/24 to 10.0.1.0/24 \
from 10.0.10.0/24 to 10.0.4.0/24 \
from 10.0.10.0/24 to 10.0.7.0/24 \
local responder peer initiator \
childsa group modp2048 \
srcid "/CN=responder" dstid "/CN=initiator"

- Tobias

Re: Iked <-> Strongswan

[Tobias Heider]

Hi,

this doesn't look like an IKE problem if the handshake succeeds.
Try comparing the kernel SAs and flows (ipsecctl -sa on OpenBSD). 
I think strongswan for some errors deletes child SAs right after
the handshake, maybe the charon log contains more information.

- Tobias

On Wed, Jul 29, 2020 at 11:17:22PM +0200, Stephan Mending wrote:
> Hi *, 
> 
> I've been trying to a longer time now to setup a connection between a 
> strongswan server and an openbsd client. Which as
> turns out isn't as straightforward as I thought. Doesn't matter how I setup 
> the strongswan config I'm running into the
> same problem. 
> 
> The connection is successfully established. When pinging the endpoint behinde 
> the strongswan router I see icmp packets
> entering enc0. When listening for packets exiting the tunnel on the 
> strongswan side it seems like there aren't any. And
> I don't see a trace of what could have happend to these packets. Neither in 
> the firewall logs nor in the IPS logfiles.
> It's driving me nuts. 
> 
> I've put you in CC tobias@ because I know you're successfully running such a 
> setup. 
> 
> My configs: 
> 
> $ cat /etc/iked.conf
>   set fragmentation 
>   ikev2 'randomID' active esp \
>   from 0.0.0.0/0 to 10.0.3.100/32 \
>   local  peer 
>  \
>   ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 
> group curve25519 \
>   childsa enc aes-256-gcm prf hmac-sha2-512 group 
> curve25519 \
>   srcid   dstid  \
>   ikelifetime 7200 lifetime 3600
> 
> $ cat ipsec.conf
> conn randomID
> left=%defaultroute
> leftsubnet=10.0.3.100/32
> leftfirewall=yes
> lefthostaccess=yes
> right=185.165.169.190
> leftcert=/var/storage/certs/hostcert.pem
> rightcert=/var/storage/certs/.pem
> leftid=""
> rightid="""
> type=tunnel
> 
> 

Re: OpenIKED: Authentication question

[Tobias Heider]

On Wed, Jul 22, 2020 at 11:56:15AM +, Scheibel, Michael wrote:
> Hi, folks,
> 
> I have successfully set up an ESP tunnel between two OpenBSD 6.7 hosts using 
> OpenIKED but I have not copied any key material (public keys) from one host 
> to the other. Still, authentication succeeds.
> 
> This is how it looks like in the logs of the initiator:
> ca_validate_pubkey: valid public key in file pubkeys/fqdn/openbsd2.my.domain
> ikev2_getimsgdata: imsg 25 rspi 0x193c5f369533048e ispi 0xac6ce70df4e79168 
> initiator 1 sa valid type 11 data length 0
> ikev2_dispatch_cert: peer certificate is valid
> sa_stateflags: 0x003d -> 0x003f cert,certvalid,certreq,auth,authvalid,sa 
> (required 0x0032 certvalid,authvalid,sa)
> sa_stateok: VALID flags 0x0032, require 0x0032 certvalid,authvalid,sa
> spi=0xac6ce70df4e79168: sa_state: AUTH_SUCCESS -> VALID
> 
> The public key “openbsd2.my.domain” and its corresponding private key have 
> been generated on the initiator host itself. Therefore the initiator should 
> not be able to authenticate the responder using the key “openbsd2.my.domain”.
> 
> Is anyone able to explain this behavior? I am probably just missing something 
> here and would highly appreciate any hints.
> 
> Cheers,
> Michael

Hi Michael,

in order to understand what's going on it would help if you could send your 
iked.confs as well as
a list of files in /etc/iked on both hosts.
The log output suggests the peer was authenticated via certificate/CA, not raw 
public key.

Regards,
Tobias

> 
> __
> Sitz der Gesellschaft/Headquarter: TÜV Informationstechnik GmbH * 
> Langemarckstr. 20 * 45141 Essen, Germany
> Registergericht/Register Court: Amtsgericht/Local Court Essen * HRB 11687 * 
> USt.-IdNr./VAT No.: DE 176132277 * Steuer-Nr./Tax No.: 111/57062251
> Geschäftsführung/Management Board: Dirk Kretzschmar
> 
> 
> TÜV NORD GROUP
> Expertise for your Success
> 
> 
> Please visit our website: www.tuv-nord.com
> Besuchen Sie unseren Internetauftritt: 
> www.tuev-nord.de
> 

Re: iked wrongly processes traffic selectors

[Tobias Heider]

On Mon, Jul 20, 2020 at 12:03:57PM +0300, Антон Касимов wrote:
> I am using OpenBSD 6.7
> iked does not respect mixing ports in the source and the destination of
> traffic selectors.
> 
> Such policy in iked.conf
> ikev2 "epsilon" active \
> proto tcp \
> from ::::30 to :::10::2 port 8000 \
> from ::::30 port postgresql to ::::/48 \
> from ::::30 port postgresql to ::::/48 \
> peer d.d.d
> 
> Produces wrong flows (specifying only destination port from first selector):
> 
> flow esp in proto tcp from ::::/48 port 8000 to
> ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp in proto tcp from ::::/48 *port 8000* to
> ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp in proto tcp from ::::2 *port 8000* to
> ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp out proto tcp from ::::30 to ::::/48 port
> 8000  peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d::/48 *port
> 8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d:10::2 *port
> 8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> 
> -- 
> Антон Касимов / Anton Kasimov

Hi Anton,

thanks for the report.
Below is a diff that should fix your problem.

Index: parse.y
===
RCS file: /mount/openbsd/cvs/src/sbin/iked/parse.y,v
retrieving revision 1.102
diff -u -p -r1.102 parse.y
--- parse.y 25 Jun 2020 13:05:58 -  1.102
+++ parse.y 20 Jul 2020 20:06:53 -
@@ -344,6 +344,7 @@ struct ipsec_addr_wrap {
sa_family_t  af;
unsigned int type;
unsigned int action;
+   uint16_t port;
char*name;
struct ipsec_addr_wrap  *next;
struct ipsec_addr_wrap  *tail;
@@ -353,8 +354,6 @@ struct ipsec_addr_wrap {
 struct ipsec_hosts {
struct ipsec_addr_wrap  *src;
struct ipsec_addr_wrap  *dst;
-   uint16_t sport;
-   uint16_t dport;
 };
 
 struct ipsec_filters {
@@ -649,9 +648,9 @@ hosts   : FROM host port TO host port   
{
err(1, "hosts: calloc");
 
$$->src = $2;
-   $$->sport = $3;
+   $$->src->port = $3;
$$->dst = $5;
-   $$->dport = $6;
+   $$->dst->port = $6;
}
| TO host port FROM host port   {
struct ipsec_addr_wrap *ipa;
@@ -667,9 +666,9 @@ hosts   : FROM host port TO host port   
{
err(1, "hosts: calloc");
 
$$->src = $5;
-   $$->sport = $6;
+   $$->src->port = $6;
$$->dst = $2;
-   $$->dport = $3;
+   $$->dst->port = $3;
}
;
 
@@ -2936,14 +2935,14 @@ create_ike(char *name, int af, uint8_t i
flow->flow_src.addr_af = ipa->af;
flow->flow_src.addr_mask = ipa->mask;
flow->flow_src.addr_net = ipa->netaddress;
-   flow->flow_src.addr_port = hosts->sport;
+   flow->flow_src.addr_port = ipa->port;
 
memcpy(>flow_dst.addr, >address,
sizeof(ipb->address));
flow->flow_dst.addr_af = ipb->af;
flow->flow_dst.addr_mask = ipb->mask;
flow->flow_dst.addr_net = ipb->netaddress;
-   flow->flow_dst.addr_port = hosts->dport;
+   flow->flow_dst.addr_port = ipb->port;
 
ippn = ipa->srcnat;
if (ippn) {

Re: Missing description of the default proposals in iked.conf

[Tobias Heider]

On Fri, Jul 10, 2020 at 01:17:38PM +0300, Антон Касимов wrote:
> The descriptions of the ikesa and childsa options contain the following
> statements:
> 
> Possible values for auth, enc, prf, group, and the* default proposals* are
> described below in CRYPTO TRANSFORMS. If omitted, iked(8) will use the
> default proposals for the IKEv2 protocol.
> Possible values for auth, enc, group, esn, and the *default proposals* are
> described below in CRYPTO TRANSFORMS. If omitted, iked(8) will use the
> default proposals for the ESP or AH protocol.
> 
> 
> But CRYPTO TRANSFORMS has no description for default proposals.
> 

Thanks for noticing. I just added the info to the man page.

Re: IKEDv2 and alias addresses

[Tobias Heider]

On Sun, Jun 21, 2020 at 04:33:14PM -0400, Sonic wrote:
> On Sun, Jun 21, 2020 at 12:11 PM Patrick Wildt  wrote:
> > If you want to use a specific address for a policy, you can use the
> > "local" keyword to specify it.  This is part of the policy, not a global
> > option.
> >
> > Then iked(8) continues to losten on 0.0.0.0:500, but the policy will
> > only match if the IP address match to the one specified as "local".
> 
> My config is basically:
> Remote:
> ===
> local_gw="a.b.c.164"
> local_net="172.20.28.0/23"
> server_gw="x.y.z.45"
> server_net="172.26.62.0/23"
> state="active"
> 
> ikev2 'remote_rsa' $state esp \
> from $local_net to $server_net \
> local $local_gw peer $server_gw \
> dstid server.example.com
> ===
> Server:
> ===
> local_gw="x.y.z.45"
> local_net="172.26.62.0/23"
> remote_gw="a.b.c.164"
> remote_net="172.20.28.0/23"
> state="passive"
> 
> ikev2 'server_rsa' $state esp \
> from $local_net to $remote_net \
> local $local_gw peer $remote_gw \
> srcid server.example.com
> ===
> 
> Both outside nets are /29's and the .164 and .45 are aliases, with
> .161 and .41 being the main address. However in trouble shooting I
> kept seeing information moving on the main addresses and my pf.conf
> rules were configured for the alias addresses.
> 
> Being new to ikev2 setup I may have this all wrong.
> 
> Thanks!
> 

I tried to reproduce your bug (on current) but it seems to work as intended
for me.  It would certainly help to have a bit more info such as an iked log
and a tcpdump of your failed handshake as well as the used openbsd version.

Re: IKEv2 difference with 6.7

[Tobias Heider]

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

[Tobias Heider]

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

[Tobias Heider]

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

[Tobias Heider]

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 

Re: IKEv2 difference with 6.7

[Tobias Heider]

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

[Tobias Heider]

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

Re: iked keeps reconnecting every 8 minutes

[Tobias Heider]

On Thu, Jun 11, 2020 at 02:36:53PM +, Leclerc, Sebastien wrote:
> > I seems I got it wrong before.  Even when there was ESP traffic, iked is 
> > going
> > to start DPD when there hasn't been any incoming IKE message in the last
> > 5 minutes.
> > 
> > My advice would be to just disable DPD in iked for this specific case.
> > To do this you will have to patch it and build it from the sources.
> > Below is a diff that should do the trick.
> > 
> > Index: ikev2.c
> > ===
> > RCS file: /cvs/src/sbin/iked/ikev2.c,v
> > retrieving revision 1.231
> > diff -u -p -r1.231 ikev2.c
> > --- ikev2.c 9 Jun 2020 21:53:26 -   1.231
> > +++ ikev2.c 10 Jun 2020 11:02:39 -
> > @@ -4391,7 +4391,7 @@ ikev2_ike_sa_alive(struct iked *env, voi
> >  * SA, or if we haven't received an IKE message. but only if we
> >  * are not already waiting for an answer.
> >  */
> > -   if (((!foundin && foundout) || ikeidle) &&
> > +   if ((!foundin && foundout) &&
> > (sa->sa_stateflags & (IKED_REQ_CHILDSA|IKED_REQ_INF)) == 0) {
> > log_debug("%s: sending alive check", __func__);
> > ikev2_send_ike_e(env, sa, NULL, IKEV2_PAYLOAD_NONE,
> 
> Thank you very much, the patch did the trick. No reconnection since yesterday.
> As it is in production, this system is following syspatches only. If there 
> ever is a syspatch on iked for another problem, I assume I would have to 
> reapply this patch, right?
> 

Correct.  In that case you would do a cvs update to get the errata patch
and then reapply this diff.

Re: iked keeps reconnecting every 8 minutes

[Tobias Heider]

On Tue, Jun 09, 2020 at 08:13:53PM +, Leclerc, Sebastien wrote:
> > > > Before 6.7 iked didn't start DPD in this particular case.
> > > > It kicks in if the tunnel is up and there haven't been any incoming ESP 
> > > > packets
> > > > in the last 5 minutes.
> > > > A possible workaround would be to ping through the tunnel to have at 
> > > > least one
> > > > incoming packet every 5 minutes.
> > >
> > > There is definitely ESP packets continuously, as there are 3-8 RDP 
> > > sessions
> > > in this tunnel during workhours. That's why it's a problem, people get 
> > > their
> > > RDP session disconnected every 8 minutes.
> > >
> > 
> > If true that would certainly be a bug.
> > Could you try running iked with -dvv and look for ikev2_ike_sa_alive 
> > messages?
> > It should look like this:
> > 
> > ikev2_ike_sa_alive: incoming CHILD SA spi 0x last used 0 second(s) 
> > ago
> 
> spi=0x09ce404cdca4ee1d: ikev2_childsa_enable: loaded SPIs: 0x4cd06b6d, 
> 0x0e7dbe7d
> spi=0x09ce404cdca4ee1d: ikev2_childsa_enable: loaded flows: 
> ESP-192.168.1.0/24=192.168.100.0/24(0), 
> ESP-192.168.1.0/24=192.168.150.0/24(0), ESP-192.0.2.2/32=192.0.2.199/32(0)
> spi=0x09ce404cdca4ee1d: sa_state: VALID -> ESTABLISHED from 192.0.2.199:500 
> to 192.0.2.2:500 policy 'POLICYNAME'
> spi=0x09ce404cdca4ee1d: established peer 192.0.2.199:500[IPV4/192.0.2.199] 
> local 192.0.2.2:500[IPV4/192.0.2.2] policy 'POLICYNAME' as initiator
> ...
> ikev2_ike_sa_alive: incoming CHILD SA spi 0x0e7dbe7d last used 1 second(s) ago
> 
> I don't see the ikev2_ike_sa_alive message for the other SPI (0x4cd06b6d), is 
> it normal?

This is normal.

> And then it doesn't reply back :
> 
> ikev2_ike_sa_alive: IKE SA 0xed2d646c000 ispi 0x09ce404cdca4ee1d rspi 
> 0x714a5bb2f7ccc4d4 last received 300 second(s) ago
> ikev2_ike_sa_alive: sending alive check
> ikev2_msg_encrypt: decrypted length 4
> ikev2_msg_encrypt: padded length 16
> ikev2_msg_encrypt: length 5, padding 11, output length 44
> ikev2_next_payload: length 48 nextpayload NONE
> ikev2_msg_integr: message length 76
> ikev2_msg_integr: integrity checksum length 12
> ikev2_pld_parse: header ispi 0x09ce404cdca4ee1d rspi 0x714a5bb2f7ccc4d4 
> nextpayload SK version 0x20 exchange INFORMATIONAL flags 0x08 msgid 2 length 
> 76 response 0
> ikev2_pld_payloads: payload SK nextpayload NONE critical 0x00 length 48
> ikev2_msg_decrypt: IV length 16
> ikev2_msg_decrypt: encrypted payload length 16
> ikev2_msg_decrypt: integrity checksum length 12
> ikev2_msg_decrypt: integrity check succeeded
> ikev2_msg_decrypt: decrypted payload length 16/16 padding 11
> spi=0x09ce404cdca4ee1d: send INFORMATIONAL req 2 peer 192.0.2.199:500 local 
> 192.0.2.2:500, 76 bytes
> ...
> spi=0x09ce404cdca4ee1d: retransmit 1 INFORMATIONAL req 2 peer 192.0.2.199:500 
> local 192.0.2.2:500
> ...
> spi=0x09ce404cdca4ee1d: retransmit 2 INFORMATIONAL req 2 peer 192.0.2.199:500 
> local 192.0.2.2:500
> spi=0x09ce404cdca4ee1d: retransmit 3 INFORMATIONAL req 2 peer 192.0.2.199:500 
> local 192.0.2.2:500
> spi=0x09ce404cdca4ee1d: retransmit 4 INFORMATIONAL req 2 peer 192.0.2.199:500 
> local 192.0.2.2:500
> ...
> ikev2_ike_sa_alive: IKE SA 0xed2d646c000 ispi 0x09ce404cdca4ee1d rspi 
> 0x714a5bb2f7ccc4d4 last received 360 second(s) ago
> ...
> spi=0x09ce404cdca4ee1d: retransmit 5 INFORMATIONAL req 2 peer 192.0.2.199:500 
> local 192.0.2.2:500
> ...
> ikev2_ike_sa_alive: IKE SA 0xed2d646c000 ispi 0x09ce404cdca4ee1d rspi 
> 0x714a5bb2f7ccc4d4 last received 420 second(s) ago
> ...
> ikev2_msg_retransmit_timeout: retransmit limit reached for req 2
> spi=0x09ce404cdca4ee1d: sa_free: retransmit limit reached
> config_free_proposals: free 0xed2a4156f80
> config_free_proposals: free 0xed2a4156180
> config_free_childsas: free 0xed2c6179700
> config_free_childsas: free 0xed275c07400
> config_free_childsas: free 0xed33fcbba00
> config_free_childsas: free 0xed2c6177200
> sa_free_flows: free 0xed247848800
> sa_free_flows: free 0xed2b3308800
> sa_free_flows: free 0xed2e78cfc00
> sa_free_flows: free 0xed247849800
> sa_free_flows: free 0xed2e78cf000
> sa_free_flows: free 0xed247848c00
> 
> 
> > "ipsecctl -sa -v" shows you SA packet counters, if you find one that has
> > 0 input packets that's probably the cause.
> 
> All SAs have packet counters > 0, see those for this tunnel :
> 
> esp tunnel from 192.0.2.2 to 192.0.2.199 spi 0x4cd06b6a auth hmac-sha1 enc aes
> sa: spi 0x4cd06b6a auth hmac-sha1 enc aes
> state mature replay 64 flags 0x4
> lifetime_cur: alloc 0 bytes 501965 add 1591730080 first 1591730081
> lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0
> lifetime_soft: alloc 0 bytes 497679335 add 10011 first 0
> address_src: 192.0.2.2
> address_dst: 192.0.2.199
> identity_src: type prefix id 0: IPV4/192.0.2.2
> identity_dst: type prefix id 0: IPV4/192.0.2.199
> lifetime_lastuse: alloc 0 bytes 0 add 0 first 1591730260
> counter:
>   

Re: iked keeps reconnecting every 8 minutes

[Tobias Heider]

On Tue, Jun 09, 2020 at 06:29:05PM +, Leclerc, Sebastien wrote:
> > Before 6.7 iked didn't start DPD in this particular case.
> > It kicks in if the tunnel is up and there haven't been any incoming ESP 
> > packets
> > in the last 5 minutes.
> > A possible workaround would be to ping through the tunnel to have at least 
> > one
> > incoming packet every 5 minutes.
> 
> There is definitely ESP packets continuously, as there are 3-8 RDP sessions
> in this tunnel during workhours. That's why it's a problem, people get their
> RDP session disconnected every 8 minutes.
> 

If true that would certainly be a bug.
Could you try running iked with -dvv and look for ikev2_ike_sa_alive messages?
It should look like this:

ikev2_ike_sa_alive: incoming CHILD SA spi 0x last used 0 second(s) ago

"ipsecctl -sa -v" shows you SA packet counters, if you find one that has
0 input packets that's probably the cause.

Re: iked keeps reconnecting every 8 minutes

[Tobias Heider]

On Tue, Jun 09, 2020 at 01:11:38PM +, Leclerc, Sebastien wrote:
> > > > Jun  8 12:23:24 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: 
> > > > retransmit 1 INFORMATIONAL req 2
> > > peer 192.0.2.199:500 local 192.0.2.2:500
> > > > Jun  8 12:23:28 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: 
> > > > retransmit 2 INFORMATIONAL req 2
> > > peer 192.0.2.199:500 local 192.0.2.2:500
> > > > Jun  8 12:23:37 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: 
> > > > retransmit 3 INFORMATIONAL req 2
> > > peer 192.0.2.199:500 local 192.0.2.2:500
> > > > Jun  8 12:23:53 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: 
> > > > retransmit 4 INFORMATIONAL req 2
> > > peer 192.0.2.199:500 local 192.0.2.2:500
> > > > Jun  8 12:24:25 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: 
> > > > retransmit 5 INFORMATIONAL req 2
> > > peer 192.0.2.199:500 local 192.0.2.2:500
> > > > Jun  8 12:25:29 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: 
> > > > sa_free: retransmit limit
> > reached
> > >
> > > Those INFORMATIONAL messages are the dead peer detection. It looks like 
> > > the Watchguard
> > > firwall ignores them, which causes the reconnect after a retransmit 
> > > timeout (as intended).
> > >
> > > Can you see the outgoing INFORMATIONAL pings in tcpdump?
> > 
> > Is there a tcpdump filter I can use to see this? If I filter only by the 
> > other endpoint IP, I see
> > all the encrypted packets, without any way to know which ones are the 
> > INFORMATIONAL packets...
> 
> I found it, INFORMATIONAL packets are sent on the external interface :
> 
> # tcpdump -nnttti bge0 host 192.0.2.199 and udp port 500
> tcpdump: listening on bge0, link-type EN10MB
> Jun 09 08:56:38.482789 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> INFORMATIONAL
> cookie: 46a71107f0a9486e->bccb051ab894a056 msgid: 0002 len: 76
> Jun 09 08:58:36.363323 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> IKE_SA_INIT
> cookie: 844a443d5f49aaa5-> msgid:  len: 334
> Jun 09 08:58:36.399046 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange 
> IKE_SA_INIT
> cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid:  len: 296
> Jun 09 08:58:36.409161 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> IKE_AUTH
> cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0001 len: 252
> Jun 09 08:58:36.442159 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange 
> INFORMATIONAL
> cookie: 9225af3bb74cf5a1->b18ab2b3e82cdcdd msgid:  len: 76
> Jun 09 08:58:36.442161 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange 
> IKE_AUTH
> cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0001 len: 204
> Jun 09 09:03:36.498344 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> INFORMATIONAL
> cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76
> Jun 09 09:03:38.507692 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> INFORMATIONAL
> cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76
> Jun 09 09:03:42.517680 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> INFORMATIONAL
> cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76
> Jun 09 09:03:50.527778 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> INFORMATIONAL
> cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76
> Jun 09 09:04:06.537979 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> INFORMATIONAL
> cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76
> Jun 09 09:04:38.548773 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> INFORMATIONAL
> cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76
> Jun 09 09:06:36.448688 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> IKE_SA_INIT
> cookie: 883961cb08ca064c-> msgid:  len: 334
> Jun 09 09:06:36.487738 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange 
> IKE_SA_INIT
> cookie: 883961cb08ca064c->4485c3c2a69d42d1 msgid:  len: 296
> Jun 09 09:06:36.497831 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange 
> IKE_AUTH
> cookie: 883961cb08ca064c->4485c3c2a69d42d1 msgid: 0001 len: 252
> Jun 09 09:06:36.533002 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange 
> INFORMATIONAL
> cookie: bbdef3192a7832fc->8b3cbbe39d3ae970 msgid:  len: 76
> Jun 09 09:06:36.533004 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange 
> IKE_AUTH
> cookie: 883961cb08ca064c->4485c3c2a69d42d1 msgid: 0001 len: 204
> 
> Is there anything that may have changed between 6.6 and 6.7 concerning those 
> packets, that
> may cause the Watchguard to not accept them?
> 

Before 6.7 iked didn't start DPD in this particular case.
It kicks in if the tunnel is up and there haven't been any incoming ESP packets
in the last 5 minutes.
A possible workaround would be to ping through the tunnel to have at least one

Re: iked keeps reconnecting every 8 minutes

[Tobias Heider]

On Mon, Jun 08, 2020 at 05:28:48PM +, Leclerc, Sebastien wrote:
> After an upgrade to 6.7 on amd64 this weekend, iked keeps reconnecting every 
> 8 minutes, but only for one tunnel, to a Watchguard firewall. The tunnel has 
> been functioning properly for 5 years. Other tunnels to OpenBSD devices do 
> not reconnect every 8 minutes. I confirmed there a no dropped packets by pf. 
> Here is part of the log (anonymized) :
> 
> Jun  8 12:10:22 hv-fw-inf-02 iked[50153]: ikev2_init_ike_sa: initiating 
> "TUNNELNAME"
> Jun  8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: send 
> IKE_SA_INIT req 0 peer 192.0.2.199:500 local 192.0.2.2:500, 334 bytes
> Jun  8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: recv 
> IKE_SA_INIT res 0 peer 192.0.2.199:500 local 192.0.2.2:500, 296 bytes, policy 
> 'TUNNELNAME'
> Jun  8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: send 
> IKE_AUTH req 1 peer 192.0.2.199:500 local 192.0.2.2:500, 252 bytes
> Jun  8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: recv 
> IKE_AUTH res 1 peer 192.0.2.199:500 local 192.0.2.2:500, 204 bytes, policy 
> 'TUNNELNAME'
> Jun  8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: 
> ikev2_childsa_enable: loaded SPIs: 0x4cd06a6a, 0xa749d359
> Jun  8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: 
> ikev2_childsa_enable: loaded flows: ESP-10.0.1.0/24=10.0.100.0/24(0), 
> ESP-10.0.1.0/24=10.0.150.0/24(0), ESP-192.0.2.2/32=192.0.2.199/32(0)
> Jun  8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: established 
> peer 192.0.2.199:500[IPV4/192.0.2.199] local 192.0.2.2:500[IPV4/192.0.2.2] 
> policy 'TUNNELNAME' as initiator
> Jun  8 12:15:24 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit 
> 1 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500
> Jun  8 12:15:28 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit 
> 2 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500
> Jun  8 12:15:36 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit 
> 3 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500
> Jun  8 12:15:52 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit 
> 4 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500
> Jun  8 12:16:24 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit 
> 5 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500
> Jun  8 12:17:28 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: sa_free: 
> retransmit limit reached
> Jun  8 12:18:22 hv-fw-inf-02 iked[50153]: ikev2_init_ike_sa: initiating 
> "TUNNELNAME"
> Jun  8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: send 
> IKE_SA_INIT req 0 peer 192.0.2.199:500 local 192.0.2.2:500, 334 bytes
> Jun  8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: recv 
> IKE_SA_INIT res 0 peer 192.0.2.199:500 local 192.0.2.2:500, 296 bytes, policy 
> 'TUNNELNAME'
> Jun  8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: send 
> IKE_AUTH req 1 peer 192.0.2.199:500 local 192.0.2.2:500, 252 bytes
> Jun  8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: recv 
> IKE_AUTH res 1 peer 192.0.2.199:500 local 192.0.2.2:500, 204 bytes, policy 
> 'TUNNELNAME'
> Jun  8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: 
> ikev2_childsa_enable: loaded SPIs: 0x4cd06a6b, 0xf20c662c
> Jun  8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: 
> ikev2_childsa_enable: loaded flows: ESP-10.0.1.0/24=10.0.100.0/24(0), 
> ESP-10.0.1.0/24=10.0.150.0/24(0), ESP-192.0.2.2/32=192.0.2.199/32(0)
> Jun  8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: established 
> peer 192.0.2.199:500[IPV4/192.0.2.199] local 192.0.2.2:500[IPV4/192.0.2.2] 
> policy 'TUNNELNAME' as initiator
> Jun  8 12:23:24 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit 
> 1 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500
> Jun  8 12:23:28 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit 
> 2 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500
> Jun  8 12:23:37 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit 
> 3 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500
> Jun  8 12:23:53 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit 
> 4 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500
> Jun  8 12:24:25 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit 
> 5 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500
> Jun  8 12:25:29 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: sa_free: 
> retransmit limit reached
>  
> And here is the configuration of the tunnel : 
> 
> ikev2 "TUNNELNAME" active esp \
>   from 10.0.1.0/24 to 10.0.100.0/24 \
>   from 10.0.1.0/24 to 10.0.150.0/24 \
>   from 192.0.2.2/32 to 192.0.2.199/32 \
>   local 192.0.2.2 peer 192.0.2.199 \
>   ikesa auth hmac-sha1 enc aes-128 group grp5 \
>   childsa auth hmac-sha1 enc aes-128 group grp5 \
>   srcid 192.0.2.2 

Re: issue with IKEv2 setup

[Tobias Heider]

On Wed, Jun 03, 2020 at 02:07:52PM -0400, Sonic wrote:
> On Wed, Jun 3, 2020 at 1:49 PM Tobias Heider  wrote:
> > It does.  /etc/iked/pubkeys/fqdn/server2.domain is where the peer's public 
> > key
> > should be.
> 
> The peers public key is there, the peer, as far as I can tell is
> server1.domain, yet the example shows server2.domain.
> 

Ah true, there seems to be a typo in the faq.
Try setting dstid to 'server1.domain'.

Re: issue with IKEv2 setup

[Tobias Heider]

On Wed, Jun 03, 2020 at 01:09:02PM -0400, Sonic wrote:
> Following the FAQ at https://www.openbsd.org/faq/faq17.html I ran into
> the following problem with the server2 example:
> ===
> ikev2 'server2_rsa' active esp \
> from 10.0.2.0/24 to 10.0.1.0/24 \
> peer 192.0.2.1 \
> dstid server2.domain
> ===
> 
> ===
> # iked -dv
> set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/server2.domain
> ===
> 
> Is the above an error to be concerned with? Doesn't the system know
> that its pubkey exists as /etc/iked/local.pub ?

It does.  /etc/iked/pubkeys/fqdn/server2.domain is where the peer's public key
should be.

> 
> Should /etc/iked/local.pub be copied to /etc/iked/pubkeys/fqdn/server2.domain 
> ?
> 
> (of course I'm using the actual fqdn of the systems in question and
> literally serverX.domaIn)
> 
> No such error on the server1 example, although it seems that srcid is
> not checked for the pubkey as dstid is.
> 
> Chris
> 

>From https://www.openbsd.org/faq/faq17.html:

Building Site-to-site VPNs

This can be achieved by exchanging the default-provided RSA public keys:
/etc/iked/local.pub on the first system ("server1") should be copied to
/etc/iked/pubkeys/fqdn/server1.domain on the second system ("server2").
Then, /etc/iked/local.pub on the second system should be copied to
/etc/iked/pubkeys/fqdn/server2.domain on the first.
Replace "serverX.domain" with your own FQDN. 

Re: IKE Multi site-to-site fails

[Tobias Heider]

On Sun, May 03, 2020 at 01:07:56PM +0200, Florian Weber wrote:
> Good morning,
> 
> I am trying to connect to remote locations to our main responder. The issue
> I am facing is that I can connect each site individually without any issue,
> however, I cannot connect both sides at the same time. The sides are connect
> to the Internet via dial-up connections with dynamic IPs from the same
> provider. Hence, creating a specific peer rule for each site doesn't work.
> Is there a way to have both sites connect to the responder? With the confs
> as below, only site B can connect, while site A fails since it uses the
> "main_to_siteB" conf on the responder. If I add quick to the "main_to_siteA"
> conf on the responder, site A works but B fails as it uses the site A
> config. Responder and both initiators run on 6.6 stable.
> 
> Any help or suggestions are greatly appreciated.
> 
> Best,
> 
> Florian

Hi Florian,

the responder needs some way to know if an incoming handshake is meant for
policy 'main_to_siteA' or 'main_to_siteB'.  The peer's IP is not helpful in
this case as it is the same for both policies.
This is why IKEv2 uses IDs (as in srcid and dstid) to uniquely identify peers.

On the initiator side everything looks correct, A and B have unique srcids.
What seems to be missing is the dstid on the responder side which could be
understood as: For initiators sending the ID $dstid, match this policy.

Setting dstid to the matching initiators srcid should help:

ikev2 'main_to_siteA' passive ipcomp esp \
    from 0.0.0.0/0 to 10.8.2.1/32 \
    from 0.0.0.0/0 to 192.168.30.0/24 \
    from 0.0.0.0/0 to 192.168.37.0/24 \
    from 0.0.0.0/0 to 10.253.0.0/24 \
    local A.B.C.D peer $provider \
    srcid A.B.C.D dstid E.F.G.H \
    psk "siteApass" \
    tag "$name-$id"
 
ikev2 'main_to_siteB' passive ipcomp esp \
    from 0.0.0.0/0 to 10.8.1.1/32 \
    from 0.0.0.0/0 to 192.168.41.0/24 \
    from 0.0.0.0/0 to 192.168.47.0/24 \
    local A.B.C.D peer $provider \
    srcid A.B.C.D dstid I.J.K.L \
    psk "siteBpass" \
    tag "$name-$id"

Re: iked and rdomain

[Tobias Heider]

On Fri, Apr 17, 2020 at 02:37:57PM +0200, Florian Weber wrote:
> Good afternoon,
> 
> is it possible to have only traffic which is routed through a specific
> rdomain being encryped, i.e. have an enc interface in another rdomain and
> only the whole traffic that runs in that rdomain gets encryped?
> 
> Thank you for your help.
> 
> Best regards,
> 
> Florian
> 

Currently the only thing that should work out of the box is having iked
running in a non-default rdomain and then use ipsec only in this rdomain.

However, I have been working on better rdomain integration for
ipsec/iked lately and a working diff that should solve your problem
is currently waiting for testing over at tech@:
https://marc.info/?l=openbsd-tech=158677212723896=2

Feedback welcome ;)

Re: Restart single iked connections

[Tobias Heider]

I sent a diff to tech@ that should solve your problem:
https://marc.info/?l=openbsd-tech=158447623916319=2

On Sun, Jan 26, 2020 at 04:12:00PM +, Peter Müller wrote:
> Hello openbsd-misc,
> 
> I am strongly interested in this, too.
> 
> Since the iked manpage does not mention this, I suppose it is not possible.
> In combination with ifstated, however, this might result in a DoS scenario
> if one peer becomes unreachable - on purpose or by chance - and any other
> IPsec connections break down due to an iked restart, as Stephan already 
> pointed
> out.
> 
> So any advice on this is appreciated a lot. :-)
> 
> Thanks, and best regards,
> Peter Müller
> 
> 
> > Hi *,
> > 
> > I am in a situation where I've got hosts that handle IPsec connection
> > with multiple endpoints.
> > 
> > So I've wondered if it was possible to restart single connections
> > without rebuilding the rest of the connections.
> > For example Machine A has a tunnel to machine B and machine C.
> > The Tunnel to C is up and running as intended  but the tunnel to B is
> > broken (icmp echos don't return -> for example). How do I rebuilt the 
> > tunnel to B
> > without restarting iked for all connections and interrupting my tunnel to
> > C?
> > 
> > Thank you for your time.
> > 
> > g Stephan
> > 
> 

Re: [iked] differentiating policies by dstid

[Tobias Heider]

Hi Alexander,

the log tells us that both times the handshake ends in the successful
establishment of an IKE SA. Like you reported both match the policy 'clientA'
instead of A and B:

> Jul 15 11:06:45 server iked[12701]: sa_state: VALID -> ESTABLISHED from 
> 5.6.7.8:4500 to 1.2.3.4:4500 policy 'clientA'
> Jul 15 11:06:50 server iked[12701]: sa_state: VALID -> ESTABLISHED from 
> 5.6.7.8:1083 to 1.2.3.4:4500 policy 'clientA'

The reason seems to be this:
> Jul 15 11:06:45 server iked[12701]: ikev2_pld_id: id ASN1_DN//C=DE/ST=Lower 
> Saxony/L=Hanover/O=OpenBSD/OU=iked/CN=client1.example.com/emailAddress=r...@openbsd.org
>  length 165
> Jul 15 11:06:50 server iked[12701]: ikev2_pld_id: id ASN1_DN//C=DE/ST=Lower 
> Saxony/L=Hanover/O=OpenBSD/OU=iked/CN=client2.example.com/emailAddress=r...@openbsd.org
>  length 165
The iked server tries to match these IDs with the strings in the dstid
configuration field, in your case: "client1.example.com" and
"client1.example.com", which fails for obvious reasons.

You could try the following:
Set the dstid values to the full ASN1_DN strings:
/C=DE/ST=Lower 
Saxony/L=Hanover/O=OpenBSD/OU=iked/CN=client1.example.com/emailAddress=r...@openbsd.org
/C=DE/ST=Lower 
Saxony/L=Hanover/O=OpenBSD/OU=iked/CN=client2.example.com/emailAddress=r...@openbsd.org

If this does not work (I'm not sure the format of the identity payloads is
compatible) try setting the srcid explicitly to client1.example.com and
client2.example.com with type FQDN in the client configurations (and leave the
server dstid as it was before).

Regards,
Tobias

Re: [iked] differentiating policies by dstid

[Tobias Heider]

Hi Alexander,

On Fri, Jul 12, 2019 at 02:03:08PM +, Alexander Mischke wrote:
> I can connect fine using a single client, however using more than one client 
> breaks the connection for clientA while clientB is able to connect. I've been 
> testing this with two clients behind the SAME DSL modem, so to the server 
> they both appear to be comeing from the same IP.

As far as i can tell your server config does not contain any obvious errors
and I failed to reproduce what you're reporting with two iked clients.

Your servers iked log (e.G. by running iked with -dv) and the output of
`ipsecctl -s all` after the second client has connected would be helpful

Regards,
Tobias