Re: Usage of global tables and anchors in PF

[Jacob Leifman]

On 20 Jun 2017 at 14:17, Alen Mistric wrote:

> Howdy!
> 
> I have a global table defined in pf.conf that I would like to use in
> both the main rule set and inside an anchor. However, I keep getting
> a namespace collision when I reload the configuration file. I can't
> quite figure out from reading the man pages if you're not supposed
> to use a global table inside an anchor or if I'm just doing it the
> wrong way. Any ideas?

Unfortunately, this is a known limitation in current PF -- you can use global 
tables 
in an anchor strictly in read-only mode. Any attempt to modify a table within 
an 
anchor results in the creation of an anchor-local table with identical name 
which 
also prevents any subsequent access to the global table.

> 
> table  persist
> block quick from 
> 
> pass in proto tcp to port ssh modulate state \
>   (max-src-conn-rate 5/3, overload  flush global)
> 
> anchor "ftp" {
>   pass in proto tcp to port ftp modulate state \
> (max-src-conn 2, overload  flush global )
>   pass in proto tcp to port { 4:5 }
>   pass out proto tcp to port ftp
> }
> 

Re: relayd(8) dosn´t listen

[Stuart Henderson]

On 2017-06-20, miraculli .  wrote:
> For every aiohttp instance I created one vether(4) and assigned 10.0.0.x/24
> to it

Don't put addresses from the same /24 onto a bunch of different
interfaces. Use one /24 and the others should be /32 aliases, all on a
single interface.

> Right now the main problem is that relayd(8) dosen´t listen (on 0.0.0.0:80),
> as httpd does for example. What I´m missing here?

Your expectations don't match your current config. You would get that
behaviour with a "relay" but you use "redirect" so relayd isn't supposed
to bind to a port itself, instead it adds a PF rdr-to rule to the relayd
anchor to forward traffic to the relevant backend.

- from relayd.conf(5) :-

 Redirections
   Redirections are translated to pf(4) rdr-to rules for stateful
   forwarding to a target host from a health-checked table on layer 3.

 Relays
   Relays allow application layer load balancing, TLS acceleration,
   and general purpose TCP proxying on layer 7.

Re: Libressl issue verifying self-signed certs with tls-auth and Openvpn

[Andrew Lemin]

Hi,

Sadly in my testing it seems that CVE-2017-8301 (
http://seclists.org/oss-sec/2017/q2/145) is still broken with the
latest LibreSSL
(2.5.4) and OpenVPN 2.4.2.

Here is someone else reporting the same issue;
https://discourse.trueos.org/t/libre-openssl-tls-error-when-using-openvpn/1358/4

Of course I may have gotten this wrong somewhere, but for now it seems not
possible to use OpenVPN as a client with TLS static certificate based
server on OpenBSD.

Hope this helps clarify for anyone else finding the same issue until some
clever person does a fix.


Error same with latest;

Tue Jun 20 22:51:15 2017 OpenVPN 2.4.2 x86_64-unknown-openbsd6.1 [SSL
(OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jun 20 2017

Tue Jun 20 22:51:15 2017 library versions: LibreSSL 2.5.4, LZO 2.10

.

.

Tue Jun 20 22:52:08 2017 VERIFY ERROR: depth=0, error=self signed
certificate: < Cert Info >

Tue Jun 20 22:52:08 2017 OpenSSL: error:14007086:SSL
routines:CONNECT_CR_CERT:certificate verify failed

Tue Jun 20 22:52:08 2017 TLS_ERROR: BIO read tls_read_plaintext error

Tue Jun 20 22:52:08 2017 TLS Error: TLS object -> incoming plaintext read
error

Tue Jun 20 22:52:08 2017 TLS Error: TLS handshake failed

Tue Jun 20 22:52:08 2017 SIGUSR1[soft,tls-error] received, process
restarting

On Tue, Jun 20, 2017 at 8:49 PM, Andy Lemin  wrote:

> I've just found this hint on GitHub for the Openvpn compile options for
> Libressl;
> https://gist.github.com/gsora/2b3e9eb31c15a356c7662b0f960e2995
>
> So will try a build later tonight and share back here if that CVE is fixed.
>
> Would prefer to rebuild with the same options as the packaged binary, and
> it occurred to me that I don't know how to find that on OpenBSD?
>
> Thanks again :)
>
>
> Sent from a teeny tiny keyboard, so please excuse typos
>
> On 20 Jun 2017, at 20:23, Andrew Lemin  wrote:
>
> Hi Misc,
>
> Has anyone else come across any issues recently with Openvpn, Libressl and
> TLS on OpenBSD 6.1?
>
> I am using an .ovpn file with TLS auth static key and cert inline within
> the file, to connect to VPN service. Running openvpn binary from command
> line without any special params, just .ovpn file.
>
> I have tested this is working fine on a Linux server with same config
> (using Openssl), so the server side, CA and cert are fine etc.
>
> I noticed on the Linux server the line; "Control Channel Authentication:
> tls-auth using INLINE static key file", but I do not see this debug on the
> OpenBSD version. Wondered if Libressl is not negotiating tls properly.
>
>
> I have since found CVE-2017-8301 which I believe is related. And confirmed
> that OpenBSD 6.1 seems to be running LibreSSL version 2.5.2
>
> The CVE shows issue known between 2.5.1 and 2.5.3, and looking at the
> OpenBSD trees I can see 2.5.4 was cut around 1st of May..
>
> I used MTier to grab all major patches etc, but LibreSSL not in patch list
> yet. openvpn did have a minor.
>
> So downloaded Libressl 2.5.4 source, compiled and installed as per INSTALL
> etc.. However notice that openvpn is still linking to 2.5.2.
>
> It would be great if someone would be kind enough to confirm if this CVE
> is indeed the same issue, and if 2.5.4 includes the relevant fixes for it?
>
> And if yes, a gentle nudge as to how to get openvpn to link to the 2.5.4
> install?
>
> Thanks for your time.
> Kind regards, Andy Lemin
>
>
>
> Sent from a teeny tiny keyboard, so please excuse typos
>
>

Re: bug tracking system for OpenBSD

[Theo de Raadt]

> Kai Wetlesen wrote:
> > What would a potential curator of a bug tracker need
> > to do besides spin up a server, install, and maintain
> > the chosen (or written) software?
> 
> not underestimate the effort involved.
> 
> so this has come up before, and the answer remains the same. anyone can setup
> a bug tracker, and feed bugs into it. close the ones that get fixed,
> categorize the rest, etc.. do that for a few months and see how it goes.
> 
> i'm not really interested in looking at an empty bug database. nor one that's
> filled with crap. so yeah, there's a bootstrapping problem.
> 
> you don't have to announce your bug database the first day you set it up. in
> fact, it's better not to. but in a few months time, when somebody inevitably
> asks misc how do i contribute, where's the todo list, you'll have this handy
> list of unresolved bugs to point them at.
> 
> like a lot of projects that seem really easy, you'd think somebody would just
> do it if it were that simple. but the idea that nobody wants to chance
> investing time in a deadend project suggests they kind of know the time
> investment isn't just a saturday afternoon.
> 

Indeed, this thread is full of volunteers, isn't it?

Why haven't one of you already started doing it?

(not including Ted, Ingo, or Antoine, or myself)

Re: bug tracking system for OpenBSD

[Ted Unangst]

Kai Wetlesen wrote:
> What would a potential curator of a bug tracker need
> to do besides spin up a server, install, and maintain
> the chosen (or written) software?

not underestimate the effort involved.

so this has come up before, and the answer remains the same. anyone can setup
a bug tracker, and feed bugs into it. close the ones that get fixed,
categorize the rest, etc.. do that for a few months and see how it goes.

i'm not really interested in looking at an empty bug database. nor one that's
filled with crap. so yeah, there's a bootstrapping problem.

you don't have to announce your bug database the first day you set it up. in
fact, it's better not to. but in a few months time, when somebody inevitably
asks misc how do i contribute, where's the todo list, you'll have this handy
list of unresolved bugs to point them at.

like a lot of projects that seem really easy, you'd think somebody would just
do it if it were that simple. but the idea that nobody wants to chance
investing time in a deadend project suggests they kind of know the time
investment isn't just a saturday afternoon.

Re: Libressl issue verifying self-signed certs with tls-auth and Openvpn

[Andy Lemin]

I've just found this hint on GitHub for the Openvpn compile options for 
Libressl;
https://gist.github.com/gsora/2b3e9eb31c15a356c7662b0f960e2995

So will try a build later tonight and share back here if that CVE is fixed.

Would prefer to rebuild with the same options as the packaged binary, and it 
occurred to me that I don't know how to find that on OpenBSD?

Thanks again :)


Sent from a teeny tiny keyboard, so please excuse typos

> On 20 Jun 2017, at 20:23, Andrew Lemin  wrote:
> 
> Hi Misc,
> 
> Has anyone else come across any issues recently with Openvpn, Libressl and 
> TLS on OpenBSD 6.1?
> 
> I am using an .ovpn file with TLS auth static key and cert inline within the 
> file, to connect to VPN service. Running openvpn binary from command line 
> without any special params, just .ovpn file.
> 
> I have tested this is working fine on a Linux server with same config (using 
> Openssl), so the server side, CA and cert are fine etc.
> 
> I noticed on the Linux server the line; "Control Channel Authentication: 
> tls-auth using INLINE static key file", but I do not see this debug on the 
> OpenBSD version. Wondered if Libressl is not negotiating tls properly.
> 
> 
> I have since found CVE-2017-8301 which I believe is related. And confirmed 
> that OpenBSD 6.1 seems to be running LibreSSL version 2.5.2
> 
> The CVE shows issue known between 2.5.1 and 2.5.3, and looking at the OpenBSD 
> trees I can see 2.5.4 was cut around 1st of May..
> 
> I used MTier to grab all major patches etc, but LibreSSL not in patch list 
> yet. openvpn did have a minor.
> 
> So downloaded Libressl 2.5.4 source, compiled and installed as per INSTALL 
> etc.. However notice that openvpn is still linking to 2.5.2.
> 
> It would be great if someone would be kind enough to confirm if this CVE is 
> indeed the same issue, and if 2.5.4 includes the relevant fixes for it?
> 
> And if yes, a gentle nudge as to how to get openvpn to link to the 2.5.4 
> install?
> 
> Thanks for your time.
> Kind regards, Andy Lemin
> 
> 
> 
> Sent from a teeny tiny keyboard, so please excuse typos

relayd(8) dosn´t listen

[miraculli .]

Hi misc,

I try to setup relayd(8) as load balancer for two Python3.6 based aiohttp
web-servers on -stable. Right now I´m just playing around to get into it
so everything runs inside a VirtualBox Instance.
For every aiohttp instance I created one vether(4) and assigned 10.0.0.x/24
to it and start each aiohttp-server manually with it´s own host-IP on port
8080.
Mostly I followed the examples within "Relayd and Httpd Mastery"
by Marcus W. Lucas. There is no problem with this aiohttp-servers and
vether(4)
because relayd(8) successfully does the health check with
'check http "/" code 200'
Right now the main problem is that relayd(8) dosen´t listen (on 0.0.0.0:80),
as httpd does for example. What I´m missing here?

Thanks for your support!

Here are my configs and some further info that should be helpful:

$ doas cat /etc/sysctl.conf
net.inet.ip.forwarding=1



$ doas ifconfig vether
vether0: flags=8843 mtu 1500
lladdr fe:e1:ba:d0:f5:6f
index 5 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255
vether1: flags=8843 mtu 1500
lladdr fe:e1:ba:d1:22:b2
index 6 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255

---

[start two aiohttp servers]
# python3.6 -m aiohttp.web -H 10.0.0.1 -P 8080 main:init &

[1] 53857

# python3.6 -m aiohttp.web -H 10.0.0.2 -P 8080 main:init &
[2] 39992


$ curl -I 10.0.0.1:8080
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 14
Date: Tue, 20 Jun 2017 21:03:41 GMT
Server: Python/3.6 aiohttp/2.1.0

$ curl -I 10.0.0.2:8080
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 14
Date: Tue, 20 Jun 2017 21:03:50 GMT
Server: Python/3.6 aiohttp/2.1.0

$ doas cat /etc/pf.conf:

set block-policy return
set loginterface egress
set skip on lo
match in all scrub (no-df random-id max-mss 1440)
anchor "relayd/*"
match out on egress inet from !(egress:network) to any nat-to (egress:0)
block all
pass out quick inet

$ doas cat /etc/relayd.conf
ext_if="0.0.0.0"
aio1="10.0.0.1"
aio2="10.0.0.2"
table  { $aio1, $aio2 }
# interval 10
# timeout 1000
# prefork 1

redirect www {
listen on $ext_if tcp port 80
forward to  port 8080 check http "/" code 200
}

$ doas relayd -n
configuration OK

$ doas relayd -dvv
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
pfe: filter init done
startup
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
relayd_tls_ticket_rekey: rekeying tickets
init_tables: created 1 tables
hce_notify_done: 10.0.0.1 (http code ok)
host 10.0.0.1, check http code (17ms,http code ok), state unknown -> up,
availability 100.00%
hce_notify_done: 10.0.0.2 (http code ok)
host 10.0.0.2, check http code (21ms,http code ok), state unknown -> up,
availability 100.00%
pfe_dispatch_hce: state 1 for host 1 10.0.0.1
pfe_dispatch_hce: state 1 for host 2 10.0.0.2
table www: 2 added, 0 deleted, 0 changed, 0 killed
pfe_sync: enabling ruleset
sync_ruleset: rule added to anchor "relayd/www"
hce_notify_done: 10.0.0.1 (http code ok)
hce_notify_done: 10.0.0.2 (http code ok)
[...]

---

$ netstat -na -f inet | grep LISTEN
tcp  0  0  127.0.0.1.25*.*LISTEN
tcp  0  0  *.22 *.*
 LISTEN
tcp  0  0  10.0.0.2.8080  *.*LISTEN
tcp  0  0  10.0.0.1.8080  *.*LISTEN

---

$ doas dmesg
OpenBSD 6.1 (GENERIC) #9: Mon Jun 12 20:33:41 CEST 2017
rob...@syspatch-61-amd64.openbsd.org:
/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 2130640896 (2031MB)
avail mem = 2061524992 (1966MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz, 2214.92 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,MWAIT,SSSE3,NXE,LONG,LAHF
cpu0: 4MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 1000MHz
cpu0: mwait min=64, max=64
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
"PNP0303" at acpi0 not configured
"PNP0F03" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "1" serial 0 type VBOX oem 

Libressl issue verifying self-signed certs with tls-auth and Openvpn

[Andrew Lemin]

Hi Misc,

Has anyone else come across any issues recently with Openvpn, Libressl and
TLS on OpenBSD 6.1?

I am using an .ovpn file with TLS auth static key and cert inline within
the file, to connect to VPN service. Running openvpn binary from command
line without any special params, just .ovpn file.

I have tested this is working fine on a Linux server with same config
(using Openssl), so the server side, CA and cert are fine etc.

I noticed on the Linux server the line; "Control Channel Authentication:
tls-auth using INLINE static key file", but I do not see this debug on the
OpenBSD version. Wondered if Libressl is not negotiating tls properly.


I have since found CVE-2017-8301 which I believe is related. And confirmed
that OpenBSD 6.1 seems to be running LibreSSL version 2.5.2

The CVE shows issue known between 2.5.1 and 2.5.3, and looking at the
OpenBSD trees I can see 2.5.4 was cut around 1st of May..

I used MTier to grab all major patches etc, but LibreSSL not in patch list
yet. openvpn did have a minor.

So downloaded Libressl 2.5.4 source, compiled and installed as per INSTALL
etc.. However notice that openvpn is still linking to 2.5.2.

It would be great if someone would be kind enough to confirm if this CVE is
indeed the same issue, and if 2.5.4 includes the relevant fixes for it?

And if yes, a gentle nudge as to how to get openvpn to link to the 2.5.4
install?

Thanks for your time.
Kind regards, Andy Lemin



Sent from a teeny tiny keyboard, so please excuse typos

Re: inet6 packet filter question: link local address vs antispoof

[Harald Dunkel]

Hi Martin,

the host I had used for testing is off, so I had to switch. After
disabling the packet filter I see:

# tcpdump -i re0 -env icmp6
tcpdump: listening on re0, link-type EN10MB
20:58:08.865529 20:cf:30:e8:0d:58 52:54:00:2e:f3:25 86dd 118: 
fe80::22cf:30ff:fee8:d58 > fe80::5054:ff:fe2e:f325: icmp6: echo request 
(id:794e seq:49) [flowlabel 0x32128] (len 64, hlim 64)
20:58:08.865643 52:54:00:2e:f3:25 20:cf:30:e8:0d:58 86dd 118: ::1 > 
fe80::22cf:30ff:fee8:d58: icmp6: echo reply (id:794e seq:49) (len 64, hlim 64)
20:58:09.889659 20:cf:30:e8:0d:58 52:54:00:2e:f3:25 86dd 118: 
fe80::22cf:30ff:fee8:d58 > fe80::5054:ff:fe2e:f325: icmp6: echo request 
(id:794e seq:50) [flowlabel 0x32128] (len 64, hlim 64)
20:58:09.889738 52:54:00:2e:f3:25 20:cf:30:e8:0d:58 86dd 118: ::1 > 
fe80::22cf:30ff:fee8:d58: icmp6: echo reply (id:794e seq:50) (len 64, hlim 64)
20:58:10.913592 20:cf:30:e8:0d:58 52:54:00:2e:f3:25 86dd 118: 
fe80::22cf:30ff:fee8:d58 > fe80::5054:ff:fe2e:f325: icmp6: echo request 
(id:794e seq:51) [flowlabel 0x32128] (len 64, hlim 64)
20:58:10.913704 52:54:00:2e:f3:25 20:cf:30:e8:0d:58 86dd 118: ::1 > 
fe80::22cf:30ff:fee8:d58: icmp6: echo reply (id:794e seq:51) (len 64, hlim 64)
20:58:11.864126 00:20:4e:6c:8c:3b 33:33:00:00:00:02 86dd 70: 
fe80::220:4eff:fe6c:8c3b > ff02::2: icmp6: router solicitation (src lladdr: 
00:20:4e:6c:8c:3b) [icmp6 cksum ok] (len 16, hlim 255)
20:58:11.937665 20:cf:30:e8:0d:58 52:54:00:2e:f3:25 86dd 118: 
fe80::22cf:30ff:fee8:d58 > fe80::5054:ff:fe2e:f325: icmp6: echo request 
(id:794e seq:52) [flowlabel 0x32128] (len 64, hlim 64)
20:58:11.937743 52:54:00:2e:f3:25 20:cf:30:e8:0d:58 86dd 118: ::1 > 
fe80::22cf:30ff:fee8:d58: icmp6: echo reply (id:794e seq:52) (len 64, hlim 64)
^C
161 packets received by filter
0 packets dropped by kernel
# route -n show -inet6
Routing tables

Internet6:
DestinationGatewayFlags   Refs  
Use   Mtu  Prio Iface
::/96  ::1UGRS   0  
  0 32768 8 lo0
::/104 ::1UGRS   0  
  0 32768 8 lo0
::1::1UHhl  14  
294 32768 1 lo0
::127.0.0.0/104::1UGRS   0  
  0 32768 8 lo0
::224.0.0.0/100::1UGRS   0  
  0 32768 8 lo0
::255.0.0.0/104::1UGRS   0  
  0 32768 8 lo0
:::0.0.0.0/96  ::1UGRS   0  
  0 32768 8 lo0
2002::/24  ::1UGRS   0  
  0 32768 8 lo0
2002:7f00::/24 ::1UGRS   0  
  0 32768 8 lo0
2002:e000::/20 ::1UGRS   0  
  0 32768 8 lo0
2002:ff00::/24 ::1UGRS   0  
  0 32768 8 lo0
fe80::/10  ::1UGRS   0  
424 32768 8 lo0
fec0::/10  ::1UGRS   0  
  0 32768 8 lo0
fe80::%re0/64  fe80::5054:ff:fe2e:f325%re0UCn2  
  2 - 4 re0
fe80::22cf:30ff:fee8:d58%re0   20:cf:30:e8:0d:58  UHLc   0  
 73 - 3 re0
fe80::5054:ff:fe2e:f325%re052:54:00:2e:f3:25  UHLl   0  
153 - 1 re0
fe80::56be:f7ff:fe09:30bd%re0  54:be:f7:09:30:bd  UHLc   0  
109 - 3 re0
fe80::1%lo0fe80::1%lo0UHl0  
  0 32768 1 lo0
ff01::/16  ::1UGRS   0  
  1 32768 8 lo0
ff01::%re0/32  fe80::5054:ff:fe2e:f325%re0Um 0  
  0 - 4 re0
ff01::%lo0/32  ::1Um 0  
  1 32768 4 lo0
ff02::/16  ::1UGRS   0  
  1 32768 8 lo0
ff02::%re0/32  fe80::5054:ff:fe2e:f325%re0Um 0  
  0 - 4 re0
ff02::%lo0/32  ::1Um 0  
  1 32768 4 lo0


Unfortunately I don't have a test host running 6.0 at the moment.


Regards

Harri

Re: Stack clash and OpenBSD

[Mike Coddington]

On Tue, Jun 20, 2017 at 11:49:52AM -0400, Mike wrote:
> 
> Does 008: SECURITY FIX: May 19, 2017 fix the Stack Clash bug?
> 
> Or is a fix forthcoming?

Yes, it does. Here's the CVE, and the patch is linked from there.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000372


Thanks to the OpenBSD developers for creating syspatch, or I'd be stuck
waiting for 6.2!

Time to donate to the OpenBSD foundation... be right back :)

-- 
To find a friend one must close one eye; to keep him -- two.
-- Norman Douglas

Re: Stack clash and OpenBSD

[Mike]

On 6/20/2017 11:29 AM, Luis Coronado wrote:
> If you run -current most likely you already have the patched code, if you
> run -stable 6.1 follow https://www.openbsd.org/faq/faq10.html#Patches:
> 
> "If you're running the -release branch of OpenBSD, you can simply use the
> syspatch(8)  utility to upgrade any files
> in need of security or reliability fixes. This is the quickest and easiest
> method to get the base system up to date. Note that binary patches are only
> available for the amd64 and i386 architectures."
> 
> -l
> 
> On Tue, Jun 20, 2017 at 9:12 AM, Jasper Siepkes 
> wrote:
> 
>> Hi all,
>>
>> I'm trying to determine which action I should take in response to the Stack
>> Clash thing  https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
>> . I
>> suspect that "008: SECURITY FIX: May 19, 2017"
>> (https://www.openbsd.org/errata61.html) is the mitigation for OpenBSD 6.1?
>>
>> On a related note; Does anyone know where can I order my Stack Clash
>> t-shirts
>> and mugs? I'm also really disappointed there is no clever flashy logo :-(.
>>
>> Kind regards,
>>
>> Jasper
>>


Does 008: SECURITY FIX: May 19, 2017 fix the Stack Clash bug?

Or is a fix forthcoming?

Re: Stack clash and OpenBSD

[Luis Coronado]

If you run -current most likely you already have the patched code, if you
run -stable 6.1 follow https://www.openbsd.org/faq/faq10.html#Patches:

"If you're running the -release branch of OpenBSD, you can simply use the
syspatch(8)  utility to upgrade any files
in need of security or reliability fixes. This is the quickest and easiest
method to get the base system up to date. Note that binary patches are only
available for the amd64 and i386 architectures."

-l

On Tue, Jun 20, 2017 at 9:12 AM, Jasper Siepkes 
wrote:

> Hi all,
>
> I'm trying to determine which action I should take in response to the Stack
> Clash thing  https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
> . I
> suspect that "008: SECURITY FIX: May 19, 2017"
> (https://www.openbsd.org/errata61.html) is the mitigation for OpenBSD 6.1?
>
> On a related note; Does anyone know where can I order my Stack Clash
> t-shirts
> and mugs? I'm also really disappointed there is no clever flashy logo :-(.
>
> Kind regards,
>
> Jasper
>
>

Stack clash and OpenBSD

[Jasper Siepkes]

Hi all,

I'm trying to determine which action I should take in response to the Stack
Clash thing  https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt . I
suspect that "008: SECURITY FIX: May 19, 2017"
(https://www.openbsd.org/errata61.html) is the mitigation for OpenBSD 6.1?

On a related note; Does anyone know where can I order my Stack Clash t-shirts
and mugs? I'm also really disappointed there is no clever flashy logo :-(.

Kind regards,

Jasper

Re: bug tracking system for OpenBSD

[Stefan Sperling]

On Mon, Jun 19, 2017 at 07:01:13PM +0200, Philipp Buehler wrote:
> Am 19.06.2017 18:51 schrieb Harald Dunkel:
> > some reliable response time
> 
> I've to decide between popcorn and other stuff with flames.

Or just point out the support list? http://www.openbsd.org/support.html

I guess most people and companies on that list wouldn't mind fielding
bugs with reliable response time, for a price :-)

Usage of global tables and anchors in PF

[Alen Mistric]

Howdy!

I have a global table defined in pf.conf that I would like to use in both the 
main rule set and inside an anchor. However, I keep getting a namespace 
collision when I reload the configuration file. I can't quite figure out from 
reading the man pages if you're not supposed to use a global table inside an 
anchor or if I'm just doing it the wrong way. Any ideas?

table  persist
block quick from 

pass in proto tcp to port ssh modulate state \
  (max-src-conn-rate 5/3, overload  flush global)

anchor "ftp" {
  pass in proto tcp to port ftp modulate state \
(max-src-conn 2, overload  flush global )
  pass in proto tcp to port { 4:5 }
  pass out proto tcp to port ftp
}

Re: bug tracking system for OpenBSD

[Ingo Schwarze]

Hi,

Carlin Bingham wrote on Tue, Jun 20, 2017 at 11:20:10PM +1200:
> On Mon, Jun 19, 2017 at 06:51:24PM +0200, Harald Dunkel wrote:

>> would it be possible to establish a real bug tracking system for
>> OpenBSD? Something with bug owner, severity, attachments, assignee,
>> and (very important) some reliable response time and a databse
>> to search for known problems?

> There was a GSOC project proposed for this in 2014 but it apparently
> didn't get any takers. It had fairly clear requirements:
> 
> "A bug tracking system that integrates with sendbug(1) and doesn't suck
> dead bunnies through bent straws."
> 
> https://web.archive.org/web/20140303013316/http://www.openbsdfoundation.org/gsoc2014.html#bug-tracking

When i read those sentences back then, i instantly wondered how a
GSOC project might help with the maintenance task.


While a few GSOC projects do produce useful code (my subjective
impression being that far more fail completely), even those few
that succeed are notorious for causing substantial workload for
developers - both for the paperworks with Google and to get the
code into the tree.  The most common reason for failure is that
even though some interesting code does get written, it never gets
hammered into shape sufficiently for commit.  The GSOC student often
cannot do it due to lack of skill and experience, and also due to
lack of time after the end of the summer; the mentoring developers
are often overwhelmed with the amount of work required:  getting
good and "almost ready" code *really* ready for commit is often
much more work than people unfamiliar with OpenBSD development would
believe.  Getting from "almost ready" to "ready" can be more work
than getting from "nothing" to "almost ready".  As a drastic example,
converting apropos(1) from dbopen(3) to SQLite3 took Kristaps a few
weeks to get it almost ready, and after that it took me a year to
get it ready and committed.

The most successful OpenBSD GSOC project ever, mandoc -Tps, reduced
the workload by having the paperwork done by NetBSD, and i only had
to do seven commits in the time from June 10 to July 31, 2010,
without having to tweak the code because it was so good, and which
i didn't even need OKs for, so it barely caused any work at all.
That was not at all typical to a very unusual degree.  But yet,
long-term maintenance of the -Tps and -Tpdf code was both seriously
neglected (not a huge problem because it is not exactly business-
critical functionality) and it did cause some maintenance work for
me now and then (not so much that it even became a problem, but it
was noticeable at some points).


So, while GSOC might have occasional benefits,

 - it definitely never reduces the workload for existing developers,
   quite to the contrary

 - it has an extremely low efficiency in bringing in new developers
   (even though that does happen in rare, exceptional cases)

 - it rarely results in code that matures enough to get used in
   practice (even though that does happen in a few cases)

 - i'm not aware of a single example where it resulted in viable
   long-term project infrastructure

Yours,
  Ingo

Re: bug tracking system for OpenBSD

[Kai Wetlesen]

Good morning,

In regards to this:

>> would it be possible to establish a real bug tracking system
>> for OpenBSD?
> 
> There is exactly one reason it hasn't happened yet:
> 
> No developer has been able and willing to invest the additional
> time required to set it up and to commit to maintaining it.

What would a potential curator of a bug tracker need
to do besides spin up a server, install, and maintain
the chosen (or written) software?

Cheers,
Kai 

Re: bug tracking system for OpenBSD

[Edgar Pettijohn]

Thanks for the link. That was a fun read. Another reason I love OBSD. Take 
things seriously but have fun doing it.

⁣Sent from BlueMail ​

On Jun 20, 2017, 6:21 AM, at 6:21 AM, Carlin Bingham  wrote:
>On Mon, Jun 19, 2017 at 06:51:24PM +0200, Harald Dunkel wrote:
>> Hi folks,
>>
>> would it be possible to establish a real bug tracking system for
>> OpenBSD? Something with bug owner, severity, attachments, assignee,
>> and (very important) some reliable response time and a databse
>> to search for known problems?
>>
>
>There was a GSOC project proposed for this in 2014 but it apparently
>didn't get any takers. It had fairly clear requirements:
>
>"A bug tracking system that integrates with sendbug(1) and doesn't suck
>dead bunnies through bent straws."
>
>https://web.archive.org/web/20140303013316/http://www.openbsdfoundation.org/gsoc2014.html#bug-tracking
>
>--
>Carlin

Re: bug tracking system for OpenBSD

[Carlin Bingham]

On Mon, Jun 19, 2017 at 06:51:24PM +0200, Harald Dunkel wrote:
> Hi folks,
> 
> would it be possible to establish a real bug tracking system for
> OpenBSD? Something with bug owner, severity, attachments, assignee,
> and (very important) some reliable response time and a databse
> to search for known problems?
> 

There was a GSOC project proposed for this in 2014 but it apparently
didn't get any takers. It had fairly clear requirements:

"A bug tracking system that integrates with sendbug(1) and doesn't suck
dead bunnies through bent straws."

https://web.archive.org/web/20140303013316/http://www.openbsdfoundation.org/gsoc2014.html#bug-tracking

--
Carlin

Re: inet6 packet filter question: link local address vs antispoof

[Martin Pieuchot]

On 11/06/17(Sun) 16:23, Harald Dunkel wrote:
> PS #1: Outgoing traffic to a link-local address initiated by the
> gateway is not corrupted.
> 
> PS #2: It seems that OpenBSD 6.0 doesn't show this problem.

Could you use tcpdump on 6.0, do you spot any difference?

Re: inet6 packet filter question: link local address vs antispoof

[Martin Pieuchot]

On 11/06/17(Sun) 15:51, Harald Dunkel wrote:
> Hi folks,
> 
> pf.conf on my gateway (6.1) says
> 
> bash-4.4# pfctl -sr | egrep -i icmp\|block
> block return log all
> :
> :
> pass quick inet proto icmp all keep state (if-bound)
> pass quick inet6 proto ipv6-icmp all keep state (if-bound)
> 
> Problem is, a ping6 to the gateway's link local address is not
> answered. The pflog file reveals
> 
> 15:11:35.491878 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
> 4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
> (id:7445 seq:1) (len 64, hlim 64)
> 15:11:36.520792 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
> 4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
> (id:7445 seq:2) (len 64, hlim 64)
> 15:11:37.544670 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
> 4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
> (id:7445 seq:3) (len 64, hlim 64)
> 
> Please note the "::1". This address is not bound to re1. If I
> disable the firewall(!), or if I use
> 
>   pass quick inet6 proto ipv6-icmp all no state
> 
> then the icmp6 echo reply can pass:
> 
> bash-4.4# tcpdump -i re1 -env icmp6
> tcpdump: listening on re1, link-type EN10MB
> 15:13:36.328563 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:30) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:36.328689 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:30) (len 64, hlim 64)
> 15:13:37.352729 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:31) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:37.352845 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:31) (len 64, hlim 64)
> 15:13:38.376557 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:32) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:38.376672 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:32) (len 64, hlim 64)
> 15:13:39.400577 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:33) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:39.400693 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:33) (len 64, hlim 64)
> 
> But this doesn't help. The sender address of the echo reply is still
> bad. It is blocked by some antispoof rule on the receiver, afaict.

Looks like the source address selection for the reply is wrong.  Could
you please show me the routing table of this machine?

$ route -n show -inet6

Re: splassert: pool_put: want 0 have 4

[Martin Pieuchot]

On 14/06/17(Wed) 16:56, Marko Cupać wrote:
> On Tue, 13 Jun 2017 11:38:46 + (UTC)
> Stuart Henderson  wrote:
> 
> > Can you try "sysctl kern.splassert=2" to obtain a backtrace?
> > 
> > (This isn't on by default as there's a small risk of problems,
> > though I run this on almost all my routers/firewalls and never
> > had trouble from it).
> 
> Here's the backtrace:
> 
> Jun 14 16:52:05 nat2 /bsd: splassert: pool_put: want 0 have 4
> Jun 14 16:52:05 nat2 /bsd: Starting stack trace...
> Jun 14 16:52:05 nat2 /bsd: pool_put() at pool_put+0x6b
> Jun 14 16:52:05 nat2 /bsd: pipex_destroy_session() at 
> pipex_destroy_session+0xe4
> Jun 14 16:52:05 nat2 /bsd: pipex_timer() at pipex_timer+0x85
> Jun 14 16:52:05 nat2 /bsd: timeout_run() at timeout_run+0x48
> Jun 14 16:52:05 nat2 /bsd: softclock() at softclock+0x147
> Jun 14 16:52:05 nat2 /bsd: softintr_dispatch() at softintr_dispatch+0x8b
> Jun 14 16:52:05 nat2 /bsd: Xsoftclock() at Xsoftclock+0x1f

This has been fixed by yasuoka@ on Mai 28th.  Please try a new snapshot
and report back if you still encounter similar problems.

Cheers,
Martin

Re: IPSEC,CARP,sasyncd -- IPSEC failover not working

[Philipp Buehler]

Am 20.06.2017 11:13 schrieb claudiu vasadi:

Now some question:
1) On fw2, I omit the ipsecctl command and start only isakmpd and 
sasyncd.
If I check the SA's and flows, they will be synced from fw1 but is this 
how
it should be or do I need to have ipsec.conf on fw2 as well and issue 
the

"ipsecctl -f /etc/ipsec.conf" cmd when starting the IPSEC VPN?


You need to use ipsecctl on fw2, too. The -S will prevent active 
negotiating

until CARP flips over.

2) Once the SA's and flows are in sync and I carpdemote fw1, I loose 
the

IPSEC connection. When running isakmpd in debug mode, it looks like it
doesn't adhere to the SA's and flows "ipsecctl -sa" shows (a.k.a I need 
to

copy the ipsec.conf to fw2 and ipsecctl -f ipsec.conf).


Without the use of ipsecctl, you've SA data, as you've seen, but no 
routing
information (I think). Thus no more traffic passes (thinking: no route 
with SA

 -> packet dropped).

HTH,
--
pb

Re: Correct tftpproxy in faq/pf/ftp.html

[Theo Buehler]

On Tue, Jun 20, 2017 at 10:35:14AM +0200, Martin Ziemer wrote:
> Since OpenBSD 5.3 the tftpproxy is no longer startet via inetd, but as
> a daemon. The faq section in ftp.html still instructs you to use
> inetd.
> 
> Below is a diff which instructs the reader to use the service instead
> of inetd.

Committed, thanks!

sthen pointed out that the pf rules were in need of some fixing as
well, so I did that in addition to your diff.

Re: bug tracking system for OpenBSD

[Stuart Henderson]

On 2017-06-19, Ingo Schwarze  wrote:
> Hi,
>
> Harald Dunkel wrote on Mon, Jun 19, 2017 at 06:51:24PM +0200:
>
>> would it be possible to establish a real bug tracking system
>> for OpenBSD?
>
> There is exactly one reason it hasn't happened yet:
>
> No developer has been able and willing to invest the additional
> time required to set it up and to commit to maintaining it.

It is the second part, "commit to maintaining it", which is the real
problem.

This isn't just about sysadmin and software updates, but about triage,
removing dead/bogus reports etc.

When GNATS was removed, there were a huge number of open tickets.
Some valid, but many many were invalid.

IPSEC,CARP,sasyncd -- IPSEC failover not working

[claudiu vasadi]

Hello everyone,

I'm in dire need of sasyncd help

Here's the current setup I have:
- 2x OpenBSD 6.1 amd64 redundant firewalls (em0 (ext_if), em1 (int_if),
carp0 (carp_if over em0), carp1 (carp_if over em1))
- carp0 has 16 public IP's (ex: 1.1.1.1->1.1.1.16)
- carp1 has 1x internal IP (ex: 10.10.10.1, a /16 subnet)
- the 2x fw's are connected back-to-back (pfsync)
- sysctl.conf (both fw's): net.inet.carp.preempt=1,
net.inet.ip.forwarding=1, net.inet.ipcomp.enable=1
- pf.conf (both fw's): block all in, allow all out, allow pfsync and carp,
antispoof, allow proto esp and udp port 4500 and 500; (the rules are fine)

IPSEC setup (google cloud on the other side with ikev1):
- ipsec.conf (identical on both fw's):

my_gw="1.1.1.16"
my_net="10.10.0.0/16"
gcp_gw="x.x.x.x"
gcp_net="10.x.x.x/20"

# me->gcp
ike esp from $my_gw to $gcp_gw local $my_gw peer $gcp_gw main enc aes group
modp1024 psk 
ike esp from $my_gw to $gcp_net local $my_gw peer $gcp_gw main enc aes
group modp1024 psk ike esp from $my_net to $gcp_net local
$my_gw peer $gcp_gw main enc aes group modp1024 psk 

- isakmpd has the "-S -K" flag
- sasyncd.conf (fw2 has "peer "):

# carp(4) interface to track state changes on
interface carp0
# Interface group to use to suppress carp(4) preemption during boot
group carp
# sasyncd(8) peer IP address or hostname. Multiple 'peer' statements are
allowed
peer 
# Shared AES key used to encrypt messages between sasyncd(8) hosts. It can
be
# generated with the openssl(1) command 'openssl rand -hex 16'
sharedkey 

On fw1, I start the VPN in this order:
- rcctl start isakmpd
- ipsecctl -f /etc/ipsec.conf
- rcctl start sasyncd
- all good, the IPSEC VPN works

Now some question:
1) On fw2, I omit the ipsecctl command and start only isakmpd and sasyncd.
If I check the SA's and flows, they will be synced from fw1 but is this how
it should be or do I need to have ipsec.conf on fw2 as well and issue the
"ipsecctl -f /etc/ipsec.conf" cmd when starting the IPSEC VPN?

2) Once the SA's and flows are in sync and I carpdemote fw1, I loose the
IPSEC connection. When running isakmpd in debug mode, it looks like it
doesn't adhere to the SA's and flows "ipsecctl -sa" shows (a.k.a I need to
copy the ipsec.conf to fw2 and ipsecctl -f ipsec.conf).


What am I doing wrong?

-- 
Best regards,
Claudiu Vasadi

Re: Correct tftpproxy in faq/pf/ftp.html

[Theo Buehler]

On Tue, Jun 20, 2017 at 10:35:14AM +0200, Martin Ziemer wrote:
> Since OpenBSD 5.3 the tftpproxy is no longer startet via inetd, but as
> a daemon. The faq section in ftp.html still instructs you to use
> inetd.
> 
> Below is a diff which instructs the reader to use the service instead
> of inetd.

Could someone familiar with the matter please confirm this?

Thanks

> 
> Index: ftp.html
> ===
> RCS file: /cvs/www/faq/pf/ftp.html,v
> retrieving revision 1.60
> diff -u -p -r1.60 ftp.html
> --- ftp.html15 Jan 2017 11:33:04 -  1.60
> +++ ftp.html20 Jun 2017 08:29:20 -
> @@ -243,16 +243,12 @@ The rules above allow TFTP outbound from
>  servers on the external network.
>  
>  
> -The last step is to enable tftp-proxy in
> -http://man.openbsd.org/inetd.conf;>inetd.conf(5) so that it
> -listens on the same port that the divert-to rule specified above,
> -in this case 6969.
> +The last step is to enable and start tftp-proxy(8).
>  
>  
> -127.0.0.1:6969  dgram   udp   wait  root  /usr/libexec/tftp-proxy tftp-proxy
> +# rcctl enable tftpproxy
> +# rcctl start  tftpproxy
>  
> -
> -Unlike ftp-proxy(8), tftp-proxy(8) is spawned from inetd.
>  
>  
>  
> 

synproxy state with multipath routing

[Indunil Jayasooriya]

Hi Misc,

Can We have synproxy state in pf.conf, when net.inet.ip.multipath=1 is set
in /etc/sysctl.conf


here is my config

in /etc/sysctl.conf

net.inet.ip.forwarding=1# 1=Permit forwarding (routing) of IPv4
packets
#net.inet.ip.mforwarding=1  # 1=Permit forwarding (routing) of IPv4
multicast packets
net.inet.ip.multipath=1 # 1=Enable IP multipath routing

No /etc/mygate file. I have moved it

mv /etc/mygate /etc/mygate.orig


in /etc/hostname.bge0

!route add -mpath default 1.2.3.4

and

in /etc/hostname.bge1

!route add -mpath default 3.4.5.6


rebooted the OpenBSD box.


I have below 2 lines in pf.conf file. first rule works. but 2 nd rule with
synproxy state does NOT?


pass in quick log on $wan_if inet proto tcp from any to $wan_if \
port 22 reply-to ($wan_if $wan_gw)


pass in quick log on $wan_if inet proto tcp from any to $wan_if \
port 22 synproxy state (max-src-conn-rate 1/120) reply-to ($wan_if
$wan_gw)


Why?  seeking answers...




-- 
cat /etc/motd

Thank you
Indunil Jayasooriya
http://www.theravadanet.net/

Correct tftpproxy in faq/pf/ftp.html

[Martin Ziemer]

Since OpenBSD 5.3 the tftpproxy is no longer startet via inetd, but as
a daemon. The faq section in ftp.html still instructs you to use
inetd.

Below is a diff which instructs the reader to use the service instead
of inetd.

Index: ftp.html
===
RCS file: /cvs/www/faq/pf/ftp.html,v
retrieving revision 1.60
diff -u -p -r1.60 ftp.html
--- ftp.html15 Jan 2017 11:33:04 -  1.60
+++ ftp.html20 Jun 2017 08:29:20 -
@@ -243,16 +243,12 @@ The rules above allow TFTP outbound from
 servers on the external network.
 
 
-The last step is to enable tftp-proxy in
-http://man.openbsd.org/inetd.conf;>inetd.conf(5) so that it
-listens on the same port that the divert-to rule specified above,
-in this case 6969.
+The last step is to enable and start tftp-proxy(8).
 
 
-127.0.0.1:6969  dgram   udp   wait  root  /usr/libexec/tftp-proxy tftp-proxy
+# rcctl enable tftpproxy
+# rcctl start  tftpproxy
 
-
-Unlike ftp-proxy(8), tftp-proxy(8) is spawned from inetd.
 
 
 

Re: Rebuilding a degraded RAID5 softraid array

[LÉVAI Dániel]

LÉVAI Dániel @ 2017-06-20T10:22:27 +0200:
> Joel Sing @ 2017-06-19T18:14:30 +0200:
[...]

Hit reply too fast.

> > > You in fact gave the advice at a so lucky time, that I was about to
> > > return the disk for a warranty replacement -- had I done that, I could
> > > not have been able to repair the array. So thanks again, and I guess
> > > you'll have a beer on me when you're around Budapest ;)
> > 
> > Just to clarify, you're saying that when you plugged all of the original 
> > disks 
> > back in the array came up again correctly? And if this is correct, was this 
> > at 
> > boot time?
> 
> Yes, when I plugged back the 'broken' disk, the array came up in
> degraded state during boot.
> 
> The order of events were the following:
> First, one of the disks went offline, then the array became degraded.
> Then after numerous reboots it always came back degraded with the
> failing disk being Offline, but after the very first reboot (after the
> fail) softraid couldn't read eg. the size of the failed disk anymore,
> when I ran `bioctl softraid0` it showed something like this:
> (sorry, this is not the actual output, I'm just trying to remember this)
> 
> softraid0 1 Degraded9001777889280 sd8 RAID5
>   0 Online  3000592678912 1:0.0   noencl 
>   1 Online  3000592678912 1:1.0   noencl 
>   2 Online  3000592678912 1:2.0   noencl 
>   3 Offline 0 1:3.0   noencl 
> 
> Softraid could however still read eg. the serial number of the failed
> disk.

And then what I did actually was booting into bsd.rd from a USB drive, 5
3TB disks connected (the three original ones, the failing one, and the
new/clean disk), kicked off the failed drive with the rebuild (bioctl
-R ...), then shutdown the machine (mid-rebuild), removed the failed
drive (so the three original and the new one remained), then booted into
the system from the system disk(s).
Then rebuild resumed and continued at boot time.


Daniel

-- 
LÉVAI Dániel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D  650C C69B BE4C 83B6 3A8F

Re: Rebuilding a degraded RAID5 softraid array

[LÉVAI Dániel]

Joel Sing @ 2017-06-19T18:14:30 +0200:
> On Friday 16 June 2017 10:11:20 LÉVAI Dániel wrote:
> > Karel Gardas @ 2017-06-15T09:07:39 +0200:
> > > On Thu, Jun 15, 2017 at 7:04 AM, LEVAI Daniel  wrote:
> > [...]
> > 
> > > > Strangest thing is, if I boot with the 'bad' (=failing) drive as
> > > > part of the array, softraid brings the volume online (albeit
> > > > degraded) and I can even decrypt/mount the volume and use it (only
> > > > one drive being bad in the array of RAID5).  If I remove/replace
> > > > said failing drive, I'm not getting a degraded volume, just the
> > > > error about the missing chunk and that it refuses to bring it
> > > > online.
> > 
> > [...]
> > [...]
> > 
> > > So I see you do have two possibilities probably:
> > > 
> > > 1) IMHO more safe. If you do have enough SATA ports, then attach both
> > > your failing drive and your new drive to the system. Boot. OpenBSD
> > > should detect and attach RAID5 in degraded state and then you will be
> > > able to perform your rebuild (if your failing drive is not offline,
> > > you can use bioctl to offline it)
> > > or
> > 
> > Thanks Karel, this indeed did the trick. I'm still baffled however, that
> > the whole purpose of the RAID setup was diminished by a missing disk 8-\
> 
> This is certainly not expected behaviour - I've only skimmed/picked over 
> parts 
> of this thread, however softraid will attempt to bring a degraded array 
> online 
> (which it seemed to be doing):
> 
> softraid0: not all chunks were provided; attempting to bring volume 1 online
> softraid0: trying to bring up sd7 degraded
> softraid0: sd7 is offline, will not be brought online
> 
> For some reason it was unable to bring it up in a degraded state (for 
> example, 
> multiple missing disks in a RAID 5 array, different metadata versions, etc) - 
> obviously the logging does not explain why this is the case and we may not be 
> able to reproduce the situation now.
> For future travellers, using dd to capture the start of each partition (which 
> contains the softraid metadata), would allow this to be analysed further.

Hm, would it help to extract the info now from the three old and the new
disk -- just to see if there's any anomaly? How many bytes should one
extract in this case?

Wouldn't differing metadata also hinder the assembly of the array
with four disks in this case (the fourth being the failed one; but also
see my answer below for your question about this)?

> > You in fact gave the advice at a so lucky time, that I was about to
> > return the disk for a warranty replacement -- had I done that, I could
> > not have been able to repair the array. So thanks again, and I guess
> > you'll have a beer on me when you're around Budapest ;)
> 
> Just to clarify, you're saying that when you plugged all of the original 
> disks 
> back in the array came up again correctly? And if this is correct, was this 
> at 
> boot time?

Yes, when I plugged back the 'broken' disk, the array came up in
degraded state during boot.

The order of events were the following:
First, one of the disks went offline, then the array became degraded.
Then after numerous reboots it always came back degraded with the
failing disk being Offline, but after the very first reboot (after the
fail) softraid couldn't read eg. the size of the failed disk anymore,
when I ran `bioctl softraid0` it showed something like this:
(sorry, this is not the actual output, I'm just trying to remember this)

softraid0 1 Degraded9001777889280 sd8 RAID5
  0 Online  3000592678912 1:0.0   noencl 
  1 Online  3000592678912 1:1.0   noencl 
  2 Online  3000592678912 1:2.0   noencl 
  3 Offline 0 1:3.0   noencl 

Softraid could however still read eg. the serial number of the failed
disk.

> > (Just a side note: to attach the new disk, I had to remove one of the
> > system disks that are in a RAID1 setup, also with softraid. Softraid
> > however had no problem bringing up *that* RAID1 volume in a degraded
> > state with the missing disk...)
> 
> Right - that is how it should behave.

This happened to me once before with that same RAID1, and the
replacement and the rebuilding was error free -- just like now, only
this time it was an 'artificial' failure.

> > > 2) less safe (read completely untested and unverified by reading the
> > > code on my side). Use bioctl -c 5 -l 
> > >  to attach the RAID5 array including the new drive. Please do
> > > *NOT* force this. See if bioctl complains for example about missing
> > > metadata or if it automatically detects new drive and start rebuild.
> > > 
> > > Generally speaking I'd use (1) since I used this in the past and had
> > > no issue with it.
> > 
> > Now this was more interesting. I tried eg. (re)creating the RAID5 array
> > with only the remaining three (out of four) disks, with:
> > # bioctl -c 5 -l /dev/sd2a,/dev/sd3a,/dev/sd4a softraid0
> > 
> > Now the result was a firmly reproducable 

Re: isakmpd memory usage

[Nicolas]

Hi

Here is my ipsec.conf :

ike esp from /24 to /24 
 peer  
 main auth hmac-sha1 enc aes-256 group modp1024 lifetime 28800 
 quick auth hmac-sha1 enc aes-256 group modp1024 lifetime 3600 
 srcid  
 psk '' 
 tag vpn

ike passive esp transport proto udp from  to any port 1701 
 main auth hmac-sha1 enc aes group modp2048 
 quick auth hmac-sha1 enc aes 
 srcid  
 psk "" 
 tag vpnrw

ike esp from /32 to /24 
 peer  
 main auth hmac-sha2-256 enc aes-256 group modp1024 lifetime 3600 
 quick auth hmac-sha2-256 enc aes-256 group modp2048 lifetime 1200 
 srcid  
 psk ''

ike esp from /32 to /24 
 peer  
 main auth hmac-sha2-256 enc aes-256 group modp1024 lifetime 3600 
 quick auth hmac-sha2-256 enc aes-256 group modp1024 lifetime 1200 
 srcid  
 psk ''

ike esp from  to /24 
 peer  
 main auth hmac-sha1 enc aes-256 group modp1024 lifetime 28800 
 quick auth hmac-sha1 enc aes-256 group modp1024 lifetime 3600 
 srcid  
 psk '' 
 tag vpn

Actually the isakmpd process is eating more than 100MB of memory per day. 
Nicolas
17 juin 2017 11:13 "Michał Koc"  a écrit:
Hi Nicolas, 

We are currently investigating some isakmpd memory problem with the 
devs. 

We have isakmpd running more than 100 tunnels. 

Please post Your ipsec.conf with auth data and addresses anonimised to 
investigate. 

best regards
Michał Koc 
-- Wiadomość oryginalna --
Temat: Re: isakmpd memory usage
Nadawca: Nicolas Repentin  (mailto:nico...@shivaserv.fr)
Adresat: misc@openbsd.org (mailto:misc@openbsd.org)
Data: 17.06.2017 09:49  

No one ? Le 13 juin 2017 09:11:02 GMT+02:00, Nicolas  
(mailto:nico...@shivaserv.fr) a écrit : 

Hi everyone I'm searching some help about isakmpd, which is eating a 
lot of memory, until the machine crash. It's an OpenBSD 6.1 on Qemu KVM 
(ganeti). After 3 days, the process is using 650MB of memory. When she's 
"freezed", she's unreachable on network, and on console she's blinking on tty, 
like normal, but we can't write anything on it. No .core are generated. I got a 
lot of errors like "INVALID_ID_INFORMATION" on "NO_PROPOSAL_CHOSEN" on ipsec 
logs, but ipsec connections are working. Any idea how I can debug it? Thanks, 
Nicolas