Re: New tool to (quickly) check for available package upgrades
On Tue, Jun 16, 2020 at 04:59:07PM -0400, Jeremy O'Brien wrote: > Hey misc@, > > I wrote a quick little tool here: > https://github.com/neutralinsomniac/obsdpkgup in Go to show available package > upgrades from your configured mirror. > > It takes no more than a few seconds (the time it takes to download index.txt > from the package repo) to show you all packages that have received a version > bump. This tool *won't* show same-version package-rebuild upgrades, so it > shouldn't be used as a complete replacement to running 'pkg_add -u', but > rather as a companion to show when actual newer versions of packages are > released. I just noticed that in my 99% case, I was waiting anywhere from > 5-10 minutes for 'pkg_add -u' to complete checking all ~400 of my installed > packages, and it uses a considerable amount of bandwidth while doing so. > > As I understand it, the pkgtools detect same-version rebuilds by downloading > enough of every installed package tgz to check the metadata contained within > to determine if an upgrade is needed. If anyone knows of an alternative way > to determine when a same-version package install is required, I would love to > know of it. In the meantime, I hope someone else can make use of this tool as > well. The concept you need to understand is snapshot shearing. A full package snapshot is large enough that it's hard to guarantee that you will have a full snapshot on a mirror at any point in time. In fact, you will sometimes encounter a mix of two snapshots (not that often, recently, but still) Hence, the decision to not have a central index for all packages, but to keep (and trust) the actual meta-info within the packages proper. The only way to avoid that would be to have specific tools for mirroring, and to ask mirror sites to set aside twice as much room so that they can rotate snapshots. Now, each package has all dependency information in the packing-list... which allows pkg_add to know whether to update or not. We do a somewhat strict check, we have tried to relax the check at some point in the past, but this was causing more trouble than it was worth. The amount of data transmitted during pkg_add -u mostly depends on signify: you have to grab at least a full signed block, which is slightly over 64KB. On most modern systems, the bandwidth is not an issue, the number of RTT is more problematic. The way to speed pkg_add -u up would be to keep the connection alive, which means ditching ftp(1) and switching to specific code that talks modern http together with byte-ranges.
Re: Openbsd 6.6 amd64 stable bridge with 90 vlans does not forward packets after reboot
Hello, This Issue is resolved in OpenBSD6.7 Release and OpenBSD 6.7 Stable, I no longer have to manually restart the bridge interface after reboot Thanks On Fri, 20 Mar 2020 at 01:20, Tom Smyth wrote: > Hello, > > I have a box that I use to aggregate a number of vlans which are > isolated from each other(using port protection groups and bridged > onto a 10G interface ix0 > these are configured using a standard hostname.bridgefile as follows, > cat /etc/hostname.bridge101 > maxaddr 16384 timeout 300 > up > add ix0 -stp ix0 > add vlan604 protected vlan604 1 -stp vlan604 > add vlan4069 protected vlan4069 1 -stp vlan4069 > . > . > . > add vlan3982 protected vlan43982 1 -stp vlan3982 > > when I reboot the box ... the system does not seem to forward frames ) > > but if I run > sh /etc/netstart bridge101 > > then the bridge forwards the packets just fine. > > interface configs are as follows > cat /etc/hostname.ix0 > mtu 1700 up > > cat /etc/hostname.ix1 > mtu 1708 up > > cat /etc/hostname.vlan3982 > parent ix1 vnetid 3982 mtu 1700 up > > > ifconfig bridge101 yields similar results after reboot as opposed to > ifconfig bridge101 after restarting the interface > > the only differences I saw was the index > > after reboot the index of bridge101 was 6 > > but after restarting the bridge101 the index of bridge101 was 98 > (which sounds to me like perhaps the bridge was being started before > the vlans on bootup) > > > has anyone come across this issue before? > Thanks > > > > > -- > Kindest regards, > Tom Smyth. > -- Kindest regards, Tom Smyth.
Re: IKEv2 difference with 6.7
Hi, > What I see is that the initial message is received but ignored, so this > side here probably runs into some kind of error. > To find out what exactly causes this, a more verbose log would help. > You could manually start iked with -dvv and share the log for an > incoming IKE_SA_INIT request from 72.83.103.147:500 (best without the > grep because the following lines may contain the actual error messages). gateway# iked -dvv set_policy_auth_method: using rsa for peer /etc/iked/pubkeys/ipv4/66.63.5.250 set_policy: found pubkey for /etc/iked/pubkeys/ipv4/66.63.5.250 ikev2 "VPN" active tunnel esp inet from 72.83.103.147 to 66.63.5.250 local 72.83.103.147 peer 66.63.5.250 ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 esn,noesn lifetime 10800 bytes 536870912 rsa set_policy_auth_method: using rsa for peer /etc/iked/pubkeys/ipv4/66.63.5.250 set_policy: found pubkey for /etc/iked/pubkeys/ipv4/66.63.5.250 ikev2 "Flow" active tunnel esp inet from 66.63.44.66 to 0.0.0.0/0 from 66.63.44.90 to 0.0.0.0/0 from 66.63.44.96/28 to 0.0.0.0/0 from 66.63.44.67 to 66.63.0.0/18 from 66.63.44.79 to 45.7.36.0/22 from 66.63.44.79 to 185.40.64.0/22 from 66.63.44.79 to 43.229.64.0/22 from 66.63.44.79 to 162.249.72.0/21 from 66.63.44.79 to 104.160.128.0/19 from 66.63.44.79 to 192.64.168.0/21 from 66.63.44.79 to 103.240.224.0/22 from 66.63.44.65 to 66.63.5.245 from 66.63.44.65 to 66.63.5.250 local any peer 66.63.5.250 ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 esn,noesn lifetime 10800 bytes 536870912 rsa /etc/iked.conf: loaded 2 configuration rules ca_privkey_serialize: type RSA_KEY length 1191 ca_pubkey_serialize: type RSA_KEY length 270 ca_privkey_to_method: type RSA_KEY method RSA_SIG ca_getkey: received private key type RSA_KEY length 1191 ca_getkey: received public key type RSA_KEY length 270 ca_dispatch_parent: config reset config_getpolicy: received policy ca_reload: local cert type RSA_KEY config_getocsp: ocsp_url none config_getpolicy: received policy ikev2_dispatch_cert: updated local CERTREQ type RSA_KEY length 0 config_getpfkey: received pfkey fd 3 config_getcompile: compilation done config_getsocket: received socket fd 4 config_getsocket: received socket fd 5 config_getsocket: received socket fd 6 config_getsocket: received socket fd 7 config_getmobike: mobike config_getfragmentation: no fragmentation config_getnattport: nattport 4500 ikev2_init_ike_sa: initiating "VPN" ikev2_policy2id: srcid FQDN/gateway.ouellet.us length 22 ikev2_add_proposals: length 156 ikev2_next_payload: length 160 nextpayload KE ikev2_next_payload: length 40 nextpayload NONCE ikev2_next_payload: length 36 nextpayload NOTIFY ikev2_nat_detection: local source 0xe6b00a86abde210d 0x 72.83.103.147:500 ikev2_next_payload: length 28 nextpayload NOTIFY ikev2_nat_detection: local destination 0xe6b00a86abde210d 0x 66.63.5.250:500 ikev2_next_payload: length 28 nextpayload NOTIFY ikev2_next_payload: length 14 nextpayload NONE ikev2_pld_parse: header ispi 0xe6b00a86abde210d rspi 0x nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 334 response 0 ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 160 ikev2_pld_sa: more 0 reserved 0 length 156 proposal #1 protoid IKE spisize 0 xforms 17 spi 0 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 192 total 4 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256 ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id CURVE25519 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_521 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_384 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_256 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_4096 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_3072 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_1536 ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_1024
Re: IKEv2 difference with 6.7
On Tue, Jun 16, 2020 at 05:08:47PM -0400, Daniel Ouellet wrote: > > The retransmits tell us that the peer doesn't answer. Or, to be more > > precise, it doesn't receive *any* message from the peer. Can you have > > a look at the peer's logs? Does the peer see these packets but chooses > > not to reply? Is the peer also an OpenBSD? 6.6? 6.7? > > Not a big deal, but yes the remote received and send reply back. I > pointed it out in my reply as well. > > "Now if I put the iked 6.7 binary instead, I see the traffic going out, > enter the remote tunnel, getting out of the tunnel to come back, but > never coming in the gateway unit." > > Here is the logs from the remote device. I filter by the source IP to > reduce the logs as there is a lots of different clients on that box. What I see is that the initial message is received but ignored, so this side here probably runs into some kind of error. To find out what exactly causes this, a more verbose log would help. You could manually start iked with -dvv and share the log for an incoming IKE_SA_INIT request from 72.83.103.147:500 (best without the grep because the following lines may contain the actual error messages). Another thing i notice is that this log seems to be from an older iked version. Could you give me a hint what iked version we're looking at so i can try to reproduce the problem? > > And you can see the reply as well at Jun 16 16:39:48 below. > > # tail -f /var/log/daemon | grep 72.83.103.147 > Jun 16 16:36:27 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:36:27 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:36:43 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:36:43 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:37:15 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:37:15 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:05 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:05 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:11 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:11 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:19 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:19 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:35 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:35 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:39:48 tunnel iked[5075]: ikev2_msg_send: CREATE_CHILD_SA > request from 66.63.5.250:500 to 72.83.103.147:500 msgid 0, 256 bytes > Jun 16 16:40:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > Jun 16 16:40:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from > initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, > 278 bytes > > > > If you can't look at the looks, you could tcpdump on both sides port 500 > > and check if a) the packet arrives at the peer b) the peer tries to > > respond. > > Here with the 6.7 binary: > > gateway$ doas tcpdump -nnttti re0 host 66.63.5.250 and udp port 500 > tcpdump: listening on re0, link-type EN10MB > Jun 16 16:51:53.161393 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0 > exchange IKE_SA_INIT > cookie: 5910d1be1404a0fb-> msgid:
Re: IKEv2 difference with 6.7
On 2020-06-12, Tobias Heider wrote: > Probably related to the following change documented in > https://www.openbsd.org/faq/upgrade67.html: > > iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by iked(8) > or > isakmpd(8) was changed from "use" to "require". This means unencrypted traffic > matching the flows will no longer be accepted. Flows of type "use" can still > be > set up manually in ipsec.conf(5). > > The problem is that the incoming packet on 10.200.200.3 matches the installed > IPsec flow which only accepts encrypted packets. > > Just leaving this for the list archive, if anyone needs it this is how you can reverse that change: Index: pfkey.c === RCS file: /cvs/src/sbin/iked/pfkey.c,v retrieving revision 1.65 diff -u -p -r1.65 pfkey.c --- pfkey.c 13 May 2020 18:28:51 - 1.65 +++ pfkey.c 16 Jun 2020 22:47:54 - @@ -280,7 +280,9 @@ pfkey_flow(int sd, uint8_t satype, uint8 sa_flowtype.sadb_protocol_exttype = SADB_X_EXT_FLOW_TYPE; sa_flowtype.sadb_protocol_len = sizeof(sa_flowtype) / 8; sa_flowtype.sadb_protocol_direction = flow->flow_dir; - sa_flowtype.sadb_protocol_proto = SADB_X_FLOW_TYPE_REQUIRE; + sa_flowtype.sadb_protocol_proto = + (flow->flow_dir == IPSP_DIRECTION_IN ? + SADB_X_FLOW_TYPE_USE : SADB_X_FLOW_TYPE_REQUIRE); bzero(_protocol, sizeof(sa_protocol)); sa_protocol.sadb_protocol_exttype = SADB_X_EXT_PROTOCOL;
Re: New tool to (quickly) check for available package upgrades
On 2020-06-16, Jeremy O'Brien wrote: > On Tue, Jun 16, 2020, at 17:19, Daniel Jakots wrote: >> I think if I wanted to compare packages between a machine of mine and a >> mirror, I would compare the quirks package signature timestamps. On >> your machine you can find it with >> $ grep digital-signature /var/db/pkg/quirks*/+CONTENTS >> and on the mirror, you need to fetch the quirks-XXX.tgz (I guess you >> can find the XXX with the index.txt) and then look for the +CONTENTS >> file. I have this which I use sometimes. #!/bin/sh old=`pkg_info -f quirks | sed -En '/@digital-sig/ s/(.*signify2:|:external)//gp'` new=`PKG_DBDIR=/var/empty pkg_info -f quirks | sed -En '/@digital-sig/ s/(.*signify2:|:external)//gp'` if [[ $old == $new ]]; then echo "Already up-to-date: $old" else echo "Updating: $old -> $new" pkg_add -u fi > I'm not sure I'm following. What helpful information does this convey, > exactly? It's my understanding that the quirks package specifies mainly > package obsolescence and stem-changes. It's a quick way to check if a new package build is available. But it does rely on you not installing new packages without doing a pkg_add -u (because that will cause the local quirks package to be updated). > As I understand it, the pkgtools detect same-version rebuilds by > downloading enough of every installed package tgz to check the metadata > contained within to determine if an upgrade is needed. Every package is rebuilt in *every* ports build so it's not so much detecting whether there was a same-version rebuild, but whether you need to install it. > If anyone knows > of an alternative way to determine when a same-version package install > is required, I would love to know of it. That is the only way to check. The packing list at the start of each package includes the information about library versions it was built against (this is called the "signature" - unrelated to crypto signature - see it with pkg_info -S $somepkg). This is needed to decide whether you need to update that package.
Re: New tool to (quickly) check for available package upgrades
On Tue, Jun 16, 2020, at 17:19, Daniel Jakots wrote: > I think if I wanted to compare packages between a machine of mine and a > mirror, I would compare the quirks package signature timestamps. On > your machine you can find it with > $ grep digital-signature /var/db/pkg/quirks*/+CONTENTS > and on the mirror, you need to fetch the quirks-XXX.tgz (I guess you > can find the XXX with the index.txt) and then look for the +CONTENTS > file. > > Cheers, > Daniel > I'm not sure I'm following. What helpful information does this convey, exactly? It's my understanding that the quirks package specifies mainly package obsolescence and stem-changes.
Re: New tool to (quickly) check for available package upgrades
On Tue, 16 Jun 2020 16:59:07 -0400, "Jeremy O'Brien" wrote: > I wrote a quick little tool here: > https://github.com/neutralinsomniac/obsdpkgup in Go to show available > package upgrades from your configured mirror. > > It takes no more than a few seconds (the time it takes to download > index.txt from the package repo) to show you all packages that have > received a version bump. This tool *won't* show same-version > package-rebuild upgrades, so it shouldn't be used as a complete > replacement to running 'pkg_add -u', but rather as a companion to > show when actual newer versions of packages are released. I just > noticed that in my 99% case, I was waiting anywhere from 5-10 minutes > for 'pkg_add -u' to complete checking all ~400 of my installed > packages, and it uses a considerable amount of bandwidth while doing > so. > > As I understand it, the pkgtools detect same-version rebuilds by > downloading enough of every installed package tgz to check the > metadata contained within to determine if an upgrade is needed. If > anyone knows of an alternative way to determine when a same-version > package install is required, I would love to know of it. In the > meantime, I hope someone else can make use of this tool as well. I think if I wanted to compare packages between a machine of mine and a mirror, I would compare the quirks package signature timestamps. On your machine you can find it with $ grep digital-signature /var/db/pkg/quirks*/+CONTENTS and on the mirror, you need to fetch the quirks-XXX.tgz (I guess you can find the XXX with the index.txt) and then look for the +CONTENTS file. Cheers, Daniel
Re: IKEv2 difference with 6.7
> The retransmits tell us that the peer doesn't answer. Or, to be more > precise, it doesn't receive *any* message from the peer. Can you have > a look at the peer's logs? Does the peer see these packets but chooses > not to reply? Is the peer also an OpenBSD? 6.6? 6.7? Not a big deal, but yes the remote received and send reply back. I pointed it out in my reply as well. "Now if I put the iked 6.7 binary instead, I see the traffic going out, enter the remote tunnel, getting out of the tunnel to come back, but never coming in the gateway unit." Here is the logs from the remote device. I filter by the source IP to reduce the logs as there is a lots of different clients on that box. And you can see the reply as well at Jun 16 16:39:48 below. # tail -f /var/log/daemon | grep 72.83.103.147 Jun 16 16:36:27 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:36:27 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:36:43 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:36:43 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:37:15 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:37:15 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:05 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:05 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:11 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:11 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:19 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:19 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:35 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:35 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:39:48 tunnel iked[5075]: ikev2_msg_send: CREATE_CHILD_SA request from 66.63.5.250:500 to 72.83.103.147:500 msgid 0, 256 bytes Jun 16 16:40:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes Jun 16 16:40:07 tunnel iked[5075]: ikev2_recv: IKE_SA_INIT request from initiator 72.83.103.147:500 to 66.63.5.250:500 policy 'Vadim-flow' id 0, 278 bytes > If you can't look at the looks, you could tcpdump on both sides port 500 > and check if a) the packet arrives at the peer b) the peer tries to > respond. Here with the 6.7 binary: gateway$ doas tcpdump -nnttti re0 host 66.63.5.250 and udp port 500 tcpdump: listening on re0, link-type EN10MB Jun 16 16:51:53.161393 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0 exchange IKE_SA_INIT cookie: 5910d1be1404a0fb-> msgid: len: 278 Jun 16 16:51:53.178950 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0 exchange IKE_SA_INIT cookie: 1c613d84d5a295ac-> msgid: len: 278 Jun 16 16:51:55.183540 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0 exchange IKE_SA_INIT cookie: 5910d1be1404a0fb-> msgid: len: 278 Jun 16 16:51:55.183697 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0 exchange IKE_SA_INIT cookie: 1c613d84d5a295ac-> msgid: len: 278 Jun 16 16:51:59.193888 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0 exchange IKE_SA_INIT cookie: 5910d1be1404a0fb-> msgid: len: 278 Jun 16 16:51:59.194092 72.83.103.147.500 > 66.63.5.250.500: isakmp v2.0 exchange IKE_SA_INIT cookie:
New tool to (quickly) check for available package upgrades
Hey misc@, I wrote a quick little tool here: https://github.com/neutralinsomniac/obsdpkgup in Go to show available package upgrades from your configured mirror. It takes no more than a few seconds (the time it takes to download index.txt from the package repo) to show you all packages that have received a version bump. This tool *won't* show same-version package-rebuild upgrades, so it shouldn't be used as a complete replacement to running 'pkg_add -u', but rather as a companion to show when actual newer versions of packages are released. I just noticed that in my 99% case, I was waiting anywhere from 5-10 minutes for 'pkg_add -u' to complete checking all ~400 of my installed packages, and it uses a considerable amount of bandwidth while doing so. As I understand it, the pkgtools detect same-version rebuilds by downloading enough of every installed package tgz to check the metadata contained within to determine if an upgrade is needed. If anyone knows of an alternative way to determine when a same-version package install is required, I would love to know of it. In the meantime, I hope someone else can make use of this tool as well. Thanks! Jeremy
Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
> > -- Forwarded message -- > From: Kevin Chadwick > To: misc@openbsd.org > Cc: > Bcc: > Date: Sun, 14 Jun 2020 13:58:39 + > Subject: Thoughts or links on optimally secure defaults for pf.conf and > fstab, whilst aiming to minimise support issues. > We are basing the server part of our products on OpenBSD. > > We care more about reducing support issues than say performance. > > We will have batteries but I hope to deploy some kind of root partition > redundancy, for upgrades. > > However, Is sync or softdep a better default for the best chance of avoiding > manual fsck/support issues? Hello, I just recently got to use OpenBSD (before FreeBSD, before that Linux) and what I found out about recently is FuguIta [1], it seems to be a OpenBSD Live System, where you can create an encrypted partition and save state data to it (etc, var, etc.), then read that back after boot into memory, with that you could have memory only solution going, which, as they say on their website, can work with as little as 64MB of ram (without X use). Now I imagen if you distribute your software on top of OpenBSD, you could manage to use FuguIta to create your own install system, as you control the hardware, you can configure the boot without user interaction (on their website they describe how to create your own system. So, If I needed more resilience against power outtages, I would give fuguIta a try, but of course it depends on your configuration and the software you are running / service you are providing. Best Rai [1] http://fuguita.org
Re: IKEv2 difference with 6.7
On Tue, Jun 16, 2020 at 02:11:21PM -0400, Daniel Ouellet wrote: > > > On 6/16/20 1:35 PM, Patrick Wildt wrote: > > On Tue, Jun 16, 2020 at 01:09:32PM -0400, Daniel Ouellet wrote: > >> Hi Tobias, > >> > >> I put below the full configuration and the flows as well with the 6.6 > >> binary and switch to the 6.7 binary without any other changes as well as > >> the full config. > >> > >> The config may be a bit weird at first as I tunnel routable IP's over > >> the iked over a Verizon Fios line. You can't get routable IP's from Fios > >> and I have needs for it. So that was my way around it for years now. > >> > >> Anyway, here below: > >> > >> gateway$ doas cat /etc/ipsec.conf > >> flow esp out from ::/0 to ::/0 type deny > >> flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass > >> flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass > >> flow esp from 66.63.44.67 to 66.63.44.97 type bypass > >> flow esp from 66.63.44.90 to 66.63.44.97 type bypass > >> > >> (This above was to allow the two local subnet to take to one an other as > >> they are in different dmz. I can delete that config and it changed > >> nothing anyway. Just wanted to write why in case you wonder.) > >> > >> gateway$ doas cat /etc/iked.conf > >> # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in > >> Ashburn. > >> ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com > >> > >> ikev2 "Flow" active \ > >> from re1 to tunnel.realconnect.com \ > >> from re1 to stats.realconnect.com \ > >> from 66.63.44.66 to 0.0.0.0/0 \ > >> from 66.63.44.67 to 66.63.0.0/18 \ > >> from home.ouellet.us to 0.0.0.0/0 \ > >> from 66.63.44.96/28 to 0.0.0.0/0 \ > >>from 66.63.44.79 to 43.229.64.0/22 \ > >>from 66.63.44.79 to 45.7.36.0/22 \ > >>from 66.63.44.79 to 103.240.224.0/22 \ > >>from 66.63.44.79 to 104.160.128.0/19 \ > >>from 66.63.44.79 to 162.249.72.0/21 \ > >>from 66.63.44.79 to 185.40.64.0/22 \ > >>from 66.63.44.79 to 192.64.168.0/21 \ > >> peer tunnel.realconnect.com > >> > >> (Here above for the 66.63.44.79, again a weird stuff, that's only for my > >> older son. When he play LoL over Fios it suck! But when I tunnel it to > >> my tunnel and then directly to Equinix where Riot is and I peer at, all > >> is great and hard to believe I am sure, but latency is much lower. Again > >> not relevant, just in case you wonder. I know, it's stupid, but I do a > >> lots of work from home and I need to keep the family happy too. (;) > >> > >> On 6/16/20 6:09 AM, Tobias Heider wrote: > >>> Hi Daniel, > >>> > >>> On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote: > > Probably related to the following change documented in > > https://www.openbsd.org/faq/upgrade67.html: > > > > iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by > > iked(8) or > > isakmpd(8) was changed from "use" to "require". This means unencrypted > > traffic > > matching the flows will no longer be accepted. Flows of type "use" can > > still be > > set up manually in ipsec.conf(5). > > I have what appear to be similar problem. I used iked form 5.6 all the > way to 6.6 no problem, wel some, but I worked it out. All in archive. > > But going from 6.6 to 6.7 I can't get it to work anymore. Nothing > changed, same configuration, just a sysupgrade and that's it. > > I read this and I can understand the words, but may be I am think, but I > don't understand what to do with it. > >>> > >>> The default behavior if IPsec flows was changed to not accept unencrypted > >>> packets matching a registered flow. > >>> You can list your flows with 'ipsecctl -sf'. > >> > >> gateway$ doas ipsecctl -sf > >> flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 43.229.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 45.7.36.0/22 to 66.63.44.79 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid > >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > >> flow esp in from 66.63.5.250 to
Re: IKEv2 difference with 6.7
Hi guys, First of all, thanks for the amazing work you've done with 6.7! That said, I've got the same issue here after I updated to 6.7. The VPN keeps cutting off every 10 minutes or so. Is there any way I could fix that ? Here's my configuration: local_gw="203.0.113.1" local_network="198.51.100.0/24" remote_gw="203.0.113.2" remote_network="192.0.2.0/26" remote_network2="192.0.2.64/26" ikev2 active esp \ from $local_gw to $remote_gw \ from $local_network to $remote_network \ from $local_network to $remote_network2 \ peer $remote_gw \ ikesa enc aes-128 auth hmac-sha1 prf hmac-sha1 group modp1536 \ childsa auth hmac-sha1 enc aes-128 group modp1536 \ ikelifetime 86400 lifetime 43200 \ psk "X" That's what I can see in the logs: Jun 16 08:07:00 vpn00 iked[31977]: ikev2_init_ike_sa: initiating "policy1" Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: send IKE_SA_INIT req 0 peer 203.0.113.2:500 local 0.0.0.0:500, 382 bytes Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: recv IKE_SA_INIT res 0 peer 203.0.113.2:500 local 203.0.113.1:500, 352 bytes, policy 'policy1' Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: send IKE_AUTH req 1 peer 203.0.113.2:4500 local 203.0.113.1:4500, 284 bytes, NAT-T Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: recv IKE_AUTH res 1 peer 203.0.113.2:4500 local 203.0.113.1:4500, 252 bytes, policy 'policy1' Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: ikev2_childsa_enable: loaded SPIs: 0xae51c8bb, 0x3ab61433 Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: ikev2_childsa_enable: loaded flows: ESP-198.51.100.0/24=192.0.2.64/26(0), ESP-198.51.100.0/24=192.0.2.0/26(0), ESP-203.0.113.1/32=203.0.113.2/32(0) Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: established peer 203.0.113.2:4500[IPV4/203.0.113.2] local 203.0.113.1:4500[FQDN/vpn00.example.net] policy 'policy1' as initiator Jun 16 08:12:02 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 1 INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 Jun 16 08:12:06 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 2 INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 Jun 16 08:12:14 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 3 INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 Jun 16 08:12:30 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 4 INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 Jun 16 08:13:02 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 5 INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 Jun 16 08:14:06 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: sa_free: retransmit limit reached Jun 16 08:15:00 vpn00 iked[31977]: ikev2_init_ike_sa: initiating "policy1" Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: send IKE_SA_INIT req 0 peer 203.0.113.2:500 local 0.0.0.0:500, 382 bytes Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: recv IKE_SA_INIT res 0 peer 203.0.113.2:500 local 203.0.113.1:500, 352 bytes, policy 'policy1' Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: send IKE_AUTH req 1 peer 203.0.113.2:500 local 203.0.113.1:500, 284 bytes Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: recv IKE_AUTH res 1 peer 203.0.113.2:500 local 203.0.113.1:500, 252 bytes, policy 'policy1' Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: ikev2_childsa_enable: loaded SPIs: 0xae51c8bd, 0x7009bc39 Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: ikev2_childsa_enable: loaded flows: ESP-198.51.100.0/24=192.0.2.64/26(0), ESP-198.51.100.0/24=192.0.2.0/26(0), ESP-203.0.113.1/32=203.0.113.2/32(0) Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: established peer 203.0.113.2:500[IPV4/203.0.113.2] local 203.0.113.1:500[FQDN/vpn00.example.net] policy 'policy1' as initiator Jun 16 08:16:02 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 1 INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 Jun 16 08:16:06 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 2 INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 Jun 16 08:16:14 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 3 INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 Jun 16 08:16:30 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 4 INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 Jun 16 08:17:02 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 5 INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 Jun 16 08:18:06 vpn00 iked[31977]: spi=0x3f6d5768feb36565: sa_free: retransmit limit reached On 2020-06-16 02:55, Daniel Ouellet wrote: Just for the records, I just took a copy of iked version 6.6 and used that instead of 6.7 and all is good. I saved the 6.7 version. gateway# ls -al /sbin/iked* -r-xr-xr-x
Re: IKEv2 difference with 6.7
On 6/16/20 1:35 PM, Patrick Wildt wrote: > On Tue, Jun 16, 2020 at 01:09:32PM -0400, Daniel Ouellet wrote: >> Hi Tobias, >> >> I put below the full configuration and the flows as well with the 6.6 >> binary and switch to the 6.7 binary without any other changes as well as >> the full config. >> >> The config may be a bit weird at first as I tunnel routable IP's over >> the iked over a Verizon Fios line. You can't get routable IP's from Fios >> and I have needs for it. So that was my way around it for years now. >> >> Anyway, here below: >> >> gateway$ doas cat /etc/ipsec.conf >> flow esp out from ::/0 to ::/0 type deny >> flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass >> flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass >> flow esp from 66.63.44.67 to 66.63.44.97 type bypass >> flow esp from 66.63.44.90 to 66.63.44.97 type bypass >> >> (This above was to allow the two local subnet to take to one an other as >> they are in different dmz. I can delete that config and it changed >> nothing anyway. Just wanted to write why in case you wonder.) >> >> gateway$ doas cat /etc/iked.conf >> # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in >> Ashburn. >> ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com >> >> ikev2 "Flow" active \ >> from re1 to tunnel.realconnect.com \ >> from re1 to stats.realconnect.com \ >> from 66.63.44.66 to 0.0.0.0/0 \ >> from 66.63.44.67 to 66.63.0.0/18 \ >> from home.ouellet.us to 0.0.0.0/0 \ >> from 66.63.44.96/28 to 0.0.0.0/0 \ >> from 66.63.44.79 to 43.229.64.0/22 \ >> from 66.63.44.79 to 45.7.36.0/22 \ >> from 66.63.44.79 to 103.240.224.0/22 \ >> from 66.63.44.79 to 104.160.128.0/19 \ >> from 66.63.44.79 to 162.249.72.0/21 \ >> from 66.63.44.79 to 185.40.64.0/22 \ >> from 66.63.44.79 to 192.64.168.0/21 \ >> peer tunnel.realconnect.com >> >> (Here above for the 66.63.44.79, again a weird stuff, that's only for my >> older son. When he play LoL over Fios it suck! But when I tunnel it to >> my tunnel and then directly to Equinix where Riot is and I peer at, all >> is great and hard to believe I am sure, but latency is much lower. Again >> not relevant, just in case you wonder. I know, it's stupid, but I do a >> lots of work from home and I need to keep the family happy too. (;) >> >> On 6/16/20 6:09 AM, Tobias Heider wrote: >>> Hi Daniel, >>> >>> On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote: > Probably related to the following change documented in > https://www.openbsd.org/faq/upgrade67.html: > > iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by > iked(8) or > isakmpd(8) was changed from "use" to "require". This means unencrypted > traffic > matching the flows will no longer be accepted. Flows of type "use" can > still be > set up manually in ipsec.conf(5). I have what appear to be similar problem. I used iked form 5.6 all the way to 6.6 no problem, wel some, but I worked it out. All in archive. But going from 6.6 to 6.7 I can't get it to work anymore. Nothing changed, same configuration, just a sysupgrade and that's it. I read this and I can understand the words, but may be I am think, but I don't understand what to do with it. >>> >>> The default behavior if IPsec flows was changed to not accept unencrypted >>> packets matching a registered flow. >>> You can list your flows with 'ipsecctl -sf'. >> >> gateway$ doas ipsecctl -sf >> flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 43.229.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 45.7.36.0/22 to 66.63.44.79 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 66.63.5.250 to 72.83.103.147 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow esp in from 103.240.224.0/22 to 66.63.44.79 peer 66.63.5.250 srcid >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use >> flow
Re: IKEv2 difference with 6.7
On Tue, Jun 16, 2020 at 01:09:32PM -0400, Daniel Ouellet wrote: > Hi Tobias, > > I put below the full configuration and the flows as well with the 6.6 > binary and switch to the 6.7 binary without any other changes as well as > the full config. > > The config may be a bit weird at first as I tunnel routable IP's over > the iked over a Verizon Fios line. You can't get routable IP's from Fios > and I have needs for it. So that was my way around it for years now. > > Anyway, here below: > > gateway$ doas cat /etc/ipsec.conf > flow esp out from ::/0 to ::/0 type deny > flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass > flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass > flow esp from 66.63.44.67 to 66.63.44.97 type bypass > flow esp from 66.63.44.90 to 66.63.44.97 type bypass > > (This above was to allow the two local subnet to take to one an other as > they are in different dmz. I can delete that config and it changed > nothing anyway. Just wanted to write why in case you wonder.) > > gateway$ doas cat /etc/iked.conf > # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in > Ashburn. > ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com > > ikev2 "Flow" active \ > from re1 to tunnel.realconnect.com \ > from re1 to stats.realconnect.com \ > from 66.63.44.66 to 0.0.0.0/0 \ > from 66.63.44.67 to 66.63.0.0/18 \ > from home.ouellet.us to 0.0.0.0/0 \ > from 66.63.44.96/28 to 0.0.0.0/0 \ > from 66.63.44.79 to 43.229.64.0/22 \ > from 66.63.44.79 to 45.7.36.0/22 \ > from 66.63.44.79 to 103.240.224.0/22 \ > from 66.63.44.79 to 104.160.128.0/19 \ > from 66.63.44.79 to 162.249.72.0/21 \ > from 66.63.44.79 to 185.40.64.0/22 \ > from 66.63.44.79 to 192.64.168.0/21 \ > peer tunnel.realconnect.com > > (Here above for the 66.63.44.79, again a weird stuff, that's only for my > older son. When he play LoL over Fios it suck! But when I tunnel it to > my tunnel and then directly to Equinix where Riot is and I peer at, all > is great and hard to believe I am sure, but latency is much lower. Again > not relevant, just in case you wonder. I know, it's stupid, but I do a > lots of work from home and I need to keep the family happy too. (;) > > On 6/16/20 6:09 AM, Tobias Heider wrote: > > Hi Daniel, > > > > On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote: > >>> Probably related to the following change documented in > >>> https://www.openbsd.org/faq/upgrade67.html: > >>> > >>> iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by > >>> iked(8) or > >>> isakmpd(8) was changed from "use" to "require". This means unencrypted > >>> traffic > >>> matching the flows will no longer be accepted. Flows of type "use" can > >>> still be > >>> set up manually in ipsec.conf(5). > >> > >> I have what appear to be similar problem. I used iked form 5.6 all the > >> way to 6.6 no problem, wel some, but I worked it out. All in archive. > >> > >> But going from 6.6 to 6.7 I can't get it to work anymore. Nothing > >> changed, same configuration, just a sysupgrade and that's it. > >> > >> I read this and I can understand the words, but may be I am think, but I > >> don't understand what to do with it. > > > > The default behavior if IPsec flows was changed to not accept unencrypted > > packets matching a registered flow. > > You can list your flows with 'ipsecctl -sf'. > > gateway$ doas ipsecctl -sf > flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 43.229.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 45.7.36.0/22 to 66.63.44.79 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 66.63.5.250 to 72.83.103.147 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 103.240.224.0/22 to 66.63.44.79 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use > flow esp in from 104.160.128.0/19 to 66.63.44.79 peer 66.63.5.250 srcid > FQDN/gateway.ouellet.us dstid
Re: IKEv2 difference with 6.7
Hi Tobias, I put below the full configuration and the flows as well with the 6.6 binary and switch to the 6.7 binary without any other changes as well as the full config. The config may be a bit weird at first as I tunnel routable IP's over the iked over a Verizon Fios line. You can't get routable IP's from Fios and I have needs for it. So that was my way around it for years now. Anyway, here below: gateway$ doas cat /etc/ipsec.conf flow esp out from ::/0 to ::/0 type deny flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass flow esp from 66.63.44.67 to 66.63.44.97 type bypass flow esp from 66.63.44.90 to 66.63.44.97 type bypass (This above was to allow the two local subnet to take to one an other as they are in different dmz. I can delete that config and it changed nothing anyway. Just wanted to write why in case you wonder.) gateway$ doas cat /etc/iked.conf # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in Ashburn. ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com ikev2 "Flow" active \ from re1 to tunnel.realconnect.com \ from re1 to stats.realconnect.com \ from 66.63.44.66 to 0.0.0.0/0 \ from 66.63.44.67 to 66.63.0.0/18 \ from home.ouellet.us to 0.0.0.0/0 \ from 66.63.44.96/28 to 0.0.0.0/0 \ from 66.63.44.79 to 43.229.64.0/22 \ from 66.63.44.79 to 45.7.36.0/22 \ from 66.63.44.79 to 103.240.224.0/22 \ from 66.63.44.79 to 104.160.128.0/19 \ from 66.63.44.79 to 162.249.72.0/21 \ from 66.63.44.79 to 185.40.64.0/22 \ from 66.63.44.79 to 192.64.168.0/21 \ peer tunnel.realconnect.com (Here above for the 66.63.44.79, again a weird stuff, that's only for my older son. When he play LoL over Fios it suck! But when I tunnel it to my tunnel and then directly to Equinix where Riot is and I peer at, all is great and hard to believe I am sure, but latency is much lower. Again not relevant, just in case you wonder. I know, it's stupid, but I do a lots of work from home and I need to keep the family happy too. (;) On 6/16/20 6:09 AM, Tobias Heider wrote: > Hi Daniel, > > On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote: >>> Probably related to the following change documented in >>> https://www.openbsd.org/faq/upgrade67.html: >>> >>> iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by >>> iked(8) or >>> isakmpd(8) was changed from "use" to "require". This means unencrypted >>> traffic >>> matching the flows will no longer be accepted. Flows of type "use" can >>> still be >>> set up manually in ipsec.conf(5). >> >> I have what appear to be similar problem. I used iked form 5.6 all the >> way to 6.6 no problem, wel some, but I worked it out. All in archive. >> >> But going from 6.6 to 6.7 I can't get it to work anymore. Nothing >> changed, same configuration, just a sysupgrade and that's it. >> >> I read this and I can understand the words, but may be I am think, but I >> don't understand what to do with it. > > The default behavior if IPsec flows was changed to not accept unencrypted > packets matching a registered flow. > You can list your flows with 'ipsecctl -sf'. gateway$ doas ipsecctl -sf flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 43.229.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 45.7.36.0/22 to 66.63.44.79 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 66.63.5.250 to 72.83.103.147 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 103.240.224.0/22 to 66.63.44.79 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 104.160.128.0/19 to 66.63.44.79 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 162.249.72.0/21 to 66.63.44.79 peer 66.63.5.250 srcid FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use flow esp in from 185.40.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid
Re: IKEv2 difference with 6.7
Hi, On Tue, Jun 16, 2020 at 03:25:12PM +0200, tris...@pilat.me wrote: > Hi guys, > > First of all, thanks for the amazing work you've done with 6.7! > > That said, I've got the same issue here after I updated to 6.7. The VPN > keeps cutting off every 10 minutes or so. Is there any way I could fix that > ? This sound like a different problem. The unanswered INFORMATIONAL messages are used to check if the peer is still there. After they go unanswered the connection is restarted. May I ask which IKE implementation is running on the peer? You can try https://marc.info/?l=openbsd-misc=159178866010830=2 to see if disabling DPD would actually solve your problem. > > Here's my configuration: > > local_gw="203.0.113.1" > local_network="198.51.100.0/24" > > remote_gw="203.0.113.2" > remote_network="192.0.2.0/26" > remote_network2="192.0.2.64/26" > > ikev2 active esp \ > from $local_gw to $remote_gw \ > from $local_network to $remote_network \ > from $local_network to $remote_network2 \ > peer $remote_gw \ > ikesa enc aes-128 auth hmac-sha1 prf hmac-sha1 group modp1536 \ > childsa auth hmac-sha1 enc aes-128 group modp1536 \ > ikelifetime 86400 lifetime 43200 \ > psk "X" > > That's what I can see in the logs: > > Jun 16 08:07:00 vpn00 iked[31977]: ikev2_init_ike_sa: initiating "policy1" > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: send IKE_SA_INIT > req 0 peer 203.0.113.2:500 local 0.0.0.0:500, 382 bytes > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: recv IKE_SA_INIT > res 0 peer 203.0.113.2:500 local 203.0.113.1:500, 352 bytes, policy > 'policy1' > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: send IKE_AUTH req > 1 peer 203.0.113.2:4500 local 203.0.113.1:4500, 284 bytes, NAT-T > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: recv IKE_AUTH res > 1 peer 203.0.113.2:4500 local 203.0.113.1:4500, 252 bytes, policy 'policy1' > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: > ikev2_childsa_enable: loaded SPIs: 0xae51c8bb, 0x3ab61433 > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: > ikev2_childsa_enable: loaded flows: ESP-198.51.100.0/24=192.0.2.64/26(0), > ESP-198.51.100.0/24=192.0.2.0/26(0), ESP-203.0.113.1/32=203.0.113.2/32(0) > Jun 16 08:07:00 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: established peer > 203.0.113.2:4500[IPV4/203.0.113.2] local > 203.0.113.1:4500[FQDN/vpn00.example.net] policy 'policy1' as initiator > Jun 16 08:12:02 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 1 > INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 > Jun 16 08:12:06 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 2 > INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 > Jun 16 08:12:14 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 3 > INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 > Jun 16 08:12:30 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 4 > INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 > Jun 16 08:13:02 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: retransmit 5 > INFORMATIONAL req 2 peer 203.0.113.2:4500 local 203.0.113.1:4500 > Jun 16 08:14:06 vpn00 iked[31977]: spi=0x462d6a0792f85aa5: sa_free: > retransmit limit reached > Jun 16 08:15:00 vpn00 iked[31977]: ikev2_init_ike_sa: initiating "policy1" > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: send IKE_SA_INIT > req 0 peer 203.0.113.2:500 local 0.0.0.0:500, 382 bytes > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: recv IKE_SA_INIT > res 0 peer 203.0.113.2:500 local 203.0.113.1:500, 352 bytes, policy > 'policy1' > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: send IKE_AUTH req > 1 peer 203.0.113.2:500 local 203.0.113.1:500, 284 bytes > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: recv IKE_AUTH res > 1 peer 203.0.113.2:500 local 203.0.113.1:500, 252 bytes, policy 'policy1' > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: > ikev2_childsa_enable: loaded SPIs: 0xae51c8bd, 0x7009bc39 > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: > ikev2_childsa_enable: loaded flows: ESP-198.51.100.0/24=192.0.2.64/26(0), > ESP-198.51.100.0/24=192.0.2.0/26(0), ESP-203.0.113.1/32=203.0.113.2/32(0) > Jun 16 08:15:00 vpn00 iked[31977]: spi=0x3f6d5768feb36565: established peer > 203.0.113.2:500[IPV4/203.0.113.2] local > 203.0.113.1:500[FQDN/vpn00.example.net] policy 'policy1' as initiator > Jun 16 08:16:02 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 1 > INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 > Jun 16 08:16:06 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 2 > INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 > Jun 16 08:16:14 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 3 > INFORMATIONAL req 2 peer 203.0.113.2:500 local 203.0.113.1:500 > Jun 16 08:16:30 vpn00 iked[31977]: spi=0x3f6d5768feb36565: retransmit 4 > INFORMATIONAL req 2 peer
[www] LibreSSL 3.1.3: wrong date of release
Hi, the date of release should be updated. Cheers, Alex Index: libressl/index.html === RCS file: /cvs/www/libressl/index.html,v retrieving revision 1.104 diff -u -p -r1.104 index.html --- libressl/index.html 16 Jun 2020 02:06:47 - 1.104 +++ libressl/index.html 16 Jun 2020 11:32:06 - @@ -39,7 +39,8 @@ -https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.1.3-relnotes.txt;>LibreSSL 3.1.3 released May 20th, 2020 +https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.1.3-relnotes.txt;>LibreSSL 3.1.3 +released Juni 16th, 2020 LibreSSL is a version of the TLS/crypto stack forked from
Re: IKEv2 difference with 6.7
On Fri, Jun 12, 2020 at 09:27:18PM +0200, Tobias Heider wrote: > On Fri, Jun 12, 2020 at 03:31:56PM +0200, Patrik Ragnarsson wrote: > > Hi, > > > > We have two OpenBSD machines acting as gateways for our network using > > CARP and IPsec (IKEv2). > > > > When the machines were running OpenBSD 6.6, from an IPSec client, you > > were able to reach the passive gateway while being connected to the > > active gateway. On OpenBSD 6.7, it seems this is no longer possible. > > > > The setup looks like this: > > > > - The two servers share using CARP (carp10 > > (carpdev trunk1)) > > - The two servers share 10.200.200.1 using CARP (carp20 (carpdev > > vlan2000)) > > - The active (MASTER) gateway has 10.200.200.2 (vlan2000 (parent trunk0)) > > - The passive (BACKUP) gateway has 10.200.200.3 (vlan2000 (parent trunk0)) > > > > iked.conf looks like this on both machines: > > > > $ cat /etc/iked.conf > > local_endpoint = "" > > roadwarrior_net = "10.100.100.0/24" > > > > ikev2 "roadwarrior-psk" ipcomp esp \ > > from 10.200.200.0/24 to 0.0.0.0/0 \ > > peer any local $local_endpoint \ > > srcid $local_endpoint \ > > psk "" \ > > config address $roadwarrior_net \ > > config netmask 255.255.255.0\ > > tag "$name-$id" > > > > sasyncd.conf from the active gateway: > > > > $ cat /etc/sasyncd.conf > > interface carp10 > > listen on 10.200.200.2 > > peer 10.200.200.3 > > control iked > > sharedkey > > > > sasyncd.conf from the passive gateway: > > > > $ cat /etc/sasyncd.conf > > interface carp10 > > listen on 10.200.200.3 > > peer 10.200.200.2 > > control iked > > sharedkey > > > > The PF rules on both gateways looks like this: > > > > block drop log all > > pass on vlan2000 proto carp all keep state (no-sync) > > pass on trunk1 proto carp all keep state (no-sync) > > pass on vlan2000 all no state > > pass out on trunk1 all flags S/SA > > pass in on trunk1 inet proto tcp from any to (trunk1:0) port = 22 > > flags S/SA keep state (no-sync) > > pass in on trunk1 inet proto udp from any to (trunk1:0) port > > 6:61000 keep state (no-sync) > > pass out on trunk1:0 all flags S/SA keep state (no-sync) > > pass in on trunk1 inet proto icmp all > > block return in on trunk1 proto udp from any to any port 33434:33534 > > pass out on trunk1 from (vlan2000:network) to any flags S/SA > > nat-to (carp10:0) > > pass in on trunk1 inet proto udp from any to port > > = 500 > > pass in on trunk1 inet proto udp from any to > > port = 4500 > > pass out on trunk1 inet proto udp from to any > > port = 500 > > pass out on trunk1 inet proto udp from to any > > port = 4500 > > pass in on trunk1 inet proto esp from any to > > pass out on trunk1 inet proto esp from to any > > pass in on enc0 inet from 10.100.100.0/24 to 10.200.200.0/24 flags > > S/SA keep state (if-bound) > > pass in on enc0 inet proto ipencap from any to > IP> keep state (if-bound) > > pass out on enc0 inet from 10.200.200.0/24 to 10.100.100.0/24 > > flags S/SA keep state (if-bound) > > pass out on enc0 inet proto ipencap from to > > any keep state (if-bound) > > > > On both gateways, I can see that the same flows and SAs have been > > created after the client have connected to the VPN. (ipsecctl -s all) > > > > A client (macOS) can reach 10.200.200.1 and 10.200.200.2 (and other > > servers in 10.200.200.0/24) but not 10.200.200.3: > > > > $ ping -c5 10.200.200.3 > > PING 10.200.200.3 (10.200.200.3): 56 data bytes > > Request timeout for icmp_seq 0 > > Request timeout for icmp_seq 1 > > Request timeout for icmp_seq 2 > > Request timeout for icmp_seq 3 > > > > --- 10.200.200.3 ping statistics --- > > 5 packets transmitted, 0 packets received, 100.0% packet loss > > > > I can see the ICMP echo requests reach the vlan2000 interface on the > > passive gateway (tcpdump -netti vlan2000 icmp) > > > > 1591718254.738903 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > 1591718255.740275 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > 1591718256.740455 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > 1591718257.743593 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > > > Running iked in the foreground (iked -dv) on the passive gateway, I > > can see the following when I try to ping 10.200.200.3 from the client: > > > > pfkey_process: acquire request (peer ) > > pfkey_process: flow in from 10.200.200.0/255.255.255.0 to > > 10.100.100.173/255.255.255.255 via > > ikev2_acquire_sa: flow wasn't found > > > > I've also tried disabling PF on the
Re: IKEv2 difference with 6.7
Hi Daniel, On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote: > > Probably related to the following change documented in > > https://www.openbsd.org/faq/upgrade67.html: > > > > iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by > > iked(8) or > > isakmpd(8) was changed from "use" to "require". This means unencrypted > > traffic > > matching the flows will no longer be accepted. Flows of type "use" can > > still be > > set up manually in ipsec.conf(5). > > I have what appear to be similar problem. I used iked form 5.6 all the > way to 6.6 no problem, wel some, but I worked it out. All in archive. > > But going from 6.6 to 6.7 I can't get it to work anymore. Nothing > changed, same configuration, just a sysupgrade and that's it. > > I read this and I can understand the words, but may be I am think, but I > don't understand what to do with it. The default behavior if IPsec flows was changed to not accept unencrypted packets matching a registered flow. You can list your flows with 'ipsecctl -sf'. > > I see the require type modifier in ipsec.conf man page, not into > iked.conf man page. > > Do you mean what ever rules we had in iked.conf needs to be in > ipsec.conf now? No, that won't work. > > I am really sorry if I don't follow the meaning or what you tried to > say, but how can this be fix, or changed? > To help you I will need to know a bit more about your setup. In particular the architecture of your network, your iked.conf and the output of 'ipsecctl -sa' would be helpful. A more detailed description of what exactly does not work would also help. > My guess is that it is simple and I don't think about it properly, but I > am hitting a road block trying to figure it out. > > I am a bit at a lost and any clue stick would be greatly appreciated. > > Thanks > > Daniel > - Tobias
Re: mpd: failed to open default sndio device
On 2020-06-15, James wrote: > Did you find a solution to this? Copying ~/.sndio/cookie into _mpd's > home directory did not fix this error for me. > > On Fri, Oct 18, 2019 at 02:34:48PM +0300, Кирилл wrote: >>Hello. >>After install mpd: >>$ mpc play >>Antimatter - Over Your Shoulder >>[paused] #1/7 0:00/4:41 (0%) >>volume:100% repeat: off random: off single: off consume: off >>ERROR: Failed to open "sndio output" (sndio); Failed to open default sndio >>device >> >>dmesg: >>https://pastebin.com/y5A81Cqh > > Check all steps of /usr/local/share/doc/pkg-readmes/mpd
