Re: Bluetooth adapter that works with OpenBSD

[Aaron Mason]

On Tue, Sep 22, 2020 at 2:22 PM Tito Mari Francis Escaño
 wrote:
>
> Hi misc,
> I'm building an OpenBSD desktop PC and would like to use my Royal Kludge
> RK71 mechanical keyboard with it via USB Bluetooth dongle.
> Can somebody please point me to USB Bluetooth dongles tested working with
> OpenBSD?
> Hopefully you can guide me.
> Thanks so much.

No Bluetooth in OpenBSD, I'm afraid.

-- 
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse

Bluetooth adapter that works with OpenBSD

[Tito Mari Francis Escaño]

Hi misc,
I'm building an OpenBSD desktop PC and would like to use my Royal Kludge
RK71 mechanical keyboard with it via USB Bluetooth dongle.
Can somebody please point me to USB Bluetooth dongles tested working with
OpenBSD?
Hopefully you can guide me.
Thanks so much.

Re: dump LOB status

[Juha Erkkilä]

> On 16. Sep 2020, at 20.27, Juha Erkkilä  wrote:
> 
> 
>> On 16. Sep 2020, at 0.18, Kenneth Gober  wrote:
>> I took a very quick look at the source and it appears that 213 is shown in
>> octal.  I believe that the 200 bit indicates that a core file was produced,
>> and 13 is probably a signal number (13 octal equals 11 decimal which would
>> be SIGSEGV).  I am not sure whether the size of the file system is itself
>> the cause, I have been using dump(8) to back up a large (currently 6.7TB)
>> volume to tape for years (several tapes, actually) and it works fine,
>> although that system is still on 6.1/amd64.  I looked in CVS and didn't see
>> any obvious diffs between 6.1 and 6.6 that jumped out at me as potential
>> causes, so perhaps the issue has been latent for a long time and I haven't
>> seen it because it's triggered by the particulars of one or more files
>> rather than the overall file system size.  Maybe if an individual file gets
>> too big, or is too 'sparse' or something?
> 
> I can reproduce this on -current from Fri Sep 11 11:30:09
> with a freshly created and an empty filesystem of 2 terabytes.

It looks like the same issue has been fixed in
FreeBSD: https://svnweb.freebsd.org/base?view=revision=334979 


The diff applies cleanly to the current OpenBSD source tree.

Re: Relayd SSL Configuration with Cerbot Certs

[Graeme Neilson]

In relayd.conf you use something like this for each domain you are reverse
proxying:

# load certs
tls keypair www.example.com
tls keypair www.another_example.net
tls keypair www.third_example.com

Put your certs in
/etc/ssl/

and keys in
/etc/ssl/private/

they have to be named so they match the domains in relayd.conf so for above:
/etc/ssl/www.example.com.crt
/etc/ssl/private/www.example.com.key

and permissions on the /etc/ssl/private dir need to be restrictive.




On Sun, 20 Sep 2020 at 08:15, Benjamin Raskin 
wrote:

> Hello, Misc;
>
> I'm attempting to configure relayd to work as a reverse proxy, such that
> all
> web traffic goes through relayd prior to reaching some web server. I'm
> confused as to how I am to configure the ssl cert and key options in the
> relayd configuration. The manual configures the protocol as follows:
>
> http protocol httpfilter {
> tls ca key "/etc/ssl/private/ca.key" password "password123"
> tls ca cert "/etc/ssl/ca.crt"
> }
>
> Where do I get the password for the key? I'm using certbot to generate the
> certs, and at no time was I prompted to enter, or given a password. Am I
> missing something in terms of configuration or cert generation, or have I
> gotten everything all wrong? Thank you in advance.
>
>
> Ben Raskin
>
>

OpenDNSSEC signer engine: Bus error: How to get debug information?

[Why 42? The lists account.]

Hi All,

I am attempting to setup secure DNS on an OpenBSD 6.7 system using NSD,
Unbound and a package called Opendnssec.

I seem to have arrived at a point where one of the Opendnssec daemons,
"ods-signerd", crashes on startup i.e.
> # ods-signerd -dv
> OpenDNSSEC signer engine version 2.1.6
> Bus error in ldns_rr_clone
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Bus error

I'm not sure exactly what Threaddump means but, as far as I can tell, no
core file is dumped/written.

Is there something I can/should do in order to enable a core dump, or to
gather some more debug info. that I can pass on to the Opendnssec
developers?

Alternatively, if anyone has any ideas about what could be causing the
problem, or how to avoid it, that would be even better :-).

The other daemon started by Opendnssec seems to be running "as expected"
e.g.
> # ps aux | grep ods
> _opendns 67028  0.0  1.1 24140 33728 ??  I7Sep209:02.01 
> /usr/local/sbin/ods-enforcerd

Thanks in advance!

Cheers,
Robb.

Re: PF Natting before filtering

[Stuart Henderson]

On 2020-09-21, open...@kene.nu  wrote:
>> > My basic ruleset snippet:
>> > pass quick on vlan100 from any to any
>> > match out on vlan200 nat-to vlan200
>> > pass out on vlan200
>> > block out quick on vlan200 from 
>>
>> If this is your actual ruleset, you are observing the intended behavior.
>> match rule actions are applied directly, so the pass rule would see the
>> already
>> NATed packets as you have specified.
>>
>
> I noticed the same from some last minute efforts, the ordering of the match
> rule matters.
>
>
>> In a simple case like this you could optionally move the nat-to action to
>> the pass rule and remove the match rule if that fits your needs better.
>>
>
> Unfortunately I have many more pass rules that would need NAT applied to it
> on a case-by-case basis which is not maintainable so I guess I have to
> abort the mission and keep what I have, which is filtering on ingress.
> me.

Try tagging the relevant addresses (match from  tag whatever)
before the nat rule, then "block out quick on vlan200 tagged whatever".
Or tag the packets you _do_ want to allow and "pass out tagged permitted".

[ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

[Demi M. Obenour]

Yesterday, I wrote an unprivileged sandboxing tool for OpenBSD, based
on pledge(2) and unveil(2).  I have included the complete C source
code below, and also attached it in case this makes it easier to use.

I called it pledge(1), but am open to suggestions for a better
name.  The tool makes essential use of the execpromises argument
to pledge(2), so that it can sandbox the program it executes.
While I understand that this argument is slated for removal,
pledge(1) would not be possible without it.

pledge(1) tries to be smart: it will always unveil the target program
for execution, and will always unveil the dynamic linker and system
library directory for reading.  This avoids confusing errors from
execve(2), as well as spurious crashes from the executed program.

pledge(1) is mainly intended for when the program being sandboxed
is either potentially malicious, or doesn’t use pledge(2) and
unveil(2) to the fullest extent possible.  For example, ftp(1)
can’t use unveil(2) without significant additional complexity,
as it doesn’t know in advance where the TLS certificates are
located.  I often know that in advance, however, so I can apply
tighter sandboxing than ftp(1) can on its own.  I can also use
pledge(1) to sandbox untrusted code, for instance in a program like
the Rust Playground (https://play.rust-lang.org) that (by design)
needs to execute arbitrary user-supplied code.  While it might
also be possible to achieve this using chroots and routing domains,
using them requires root privileges, whereas pledge(1) works as an
unprivileged user.

There are several potential improvements to be made, but I believe
that the current code is already useful.  I use it to sandbox ftp(1)
in a modified version of sysupgrade(8), for example.  Bug reports
and feature requests would be greatly appreciated, as would general
suggestions for improving the code.  If there is interest, I would
also like to turn pledge(1) into a proper OpenBSD package at some
point, so that it can be installed using pkg_add(1).

The source code is less than 50 lines, so I have included it inline
to make it easier for others to comment on it, if they wish.
---
#include 
#include 
#include 

extern char **environ;

int
main (int argc, char **argv) {
char *end_perms, *arg0 = NULL, *progpath = NULL;
int ch;

while ((ch = getopt(argc, argv, "u:0:")) != -1) {
switch (ch) {
case '0':
if (arg0 != NULL)
errx(3, "arg0 cannot be set twice");
arg0 = optarg;
break;
case 'u':
if ((end_perms = strchr(optarg, ':')) == NULL)
errx(3, "no colon after permissions");
*end_perms = '\0';
if (unveil(end_perms + 1, optarg))
err(2, "unveil");
break;
}
}

if (argc - optind < 2)
errx(3, "not enough arguments");
argc -= optind;
argv += optind;
if (optind < 2 || strcmp(argv[-1], "--") != 0)
errx(3, "no -- before pledge: optind %d", optind);
progpath = argv[1];
if (arg0 != NULL)
argv[1] = arg0;
if (unveil("/usr/libexec/ld.so", "r") ||
unveil("/usr/lib", "r") ||
unveil(argv[1], "x") ||
unveil(NULL, NULL))
err(2, "unveil");
if (pledge(NULL, *argv))
err(2, "pledge");
execve(progpath, argv + 1, environ);
err(1, "execve");
}
---

Sincerely,

Demi M. Obenour
#include 
#include 
#include 

extern char **environ;

int
main (int argc, char **argv) {
	char *end_perms, *arg0 = NULL, *progpath = NULL;
	int ch;

	while ((ch = getopt(argc, argv, "u:0:")) != -1) {
		switch (ch) {
		case '0':
			if (arg0 != NULL)
errx(3, "arg0 cannot be set twice");
			arg0 = optarg;
			break;
		case 'u':
			if ((end_perms = strchr(optarg, ':')) == NULL)
errx(3, "no colon after permissions");
			*end_perms = '\0';
			if (unveil(end_perms + 1, optarg))
err(2, "unveil");
			break;
		}
	}

	if (argc - optind < 2)
		errx(3, "not enough arguments");
	argc -= optind;
	argv += optind;
	if (optind < 2 || strcmp(argv[-1], "--") != 0)
		errx(3, "no -- before pledge: optind %d", optind);
	progpath = argv[1];
	if (arg0 != NULL)
		argv[1] = arg0;
	if (unveil("/usr/libexec/ld.so", "r") ||
	unveil("/usr/lib", "r") ||
	unveil(argv[1], "x") ||
	unveil(NULL, NULL))
		err(2, "unveil");
	if (pledge(NULL, *argv))
		err(2, "pledge");
	execve(progpath, argv + 1, environ);
	err(1, "execve");
}

Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

[Demi M. Obenour]

On 2020-09-21 12:51, Demi M. Obenour wrote:
> Yesterday, I wrote an unprivileged sandboxing tool for OpenBSD, based
> on pledge(2) and unveil(2).  I have included the complete C source
> code below, and also attached it in case this makes it easier to use.

I just realized that I forgot to include a license.  Consider this
code to be released under the same ISC-style license as used by
OpenBSD itself.

Sincerely,

Demi

Re: video(1) -s size default overrides -r rate

[Laurence Tratt]

On Mon, Sep 21, 2020 at 05:44:17PM +0200, Jan Stary wrote:

Hello Jan,

> Presumably, as the default -s size is picked, and the camera cannot do 30
> fps in that size, -r 20 is chosen instead.
>
> If that's correct, the default size in effect overrides a specified rate.
> Is that intended?
>
> It doesn't seem to be the least surprise: the command line specifies the
> rate, and doesn't care about the size.
>
> Would it be preferable if video(1) chose -s 640x360 in that case, at 30
> fps, obeying the command line option?

IMHO, there's no way to not surprise users: users (naively, if reasonably)
want both big sizes and high frame rates, but that's generally impractical
for (uncompressed) YUY2. It *might* be more reasonable to throw an error if
everything specified can't be delivered.

However, there's a probably deeper point here. IMHO, video(1) isn't really a
sensible tool for viewing or recording video as it can't access a camera's
MJPEG mode (assuming the camera has one!) without ld tricks. In general, I
suggest that people use ffplay/ffmpeg (or something similar). Stefan Hagen
has been trying to put together an FAQ entry explaining webcam use on
OpenBSD [1].


Laurie

[1] https://marc.info/?l=openbsd-tech=160053691513681=2

video(1) -s size default overrides -r rate

[Jan Stary]

This is 6.8-beta/amd64 on a Thinkpad T400 (dmesg below)
using the following cheap USB camera/mic ("SriHome"):

uvideo0 at uhub7 port 1 configuration 1 interface 0 "webcam webcam" rev 
2.00/0.10 addr 2
video0 at uvideo0

$ video -q
video device /dev/video:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
640x360: 30, 25
640x480: 20
1280x720: 10
  controls: brightness, contrast, saturation, gain, sharpness, 
white_balance_temperature

By default, video(1) chooses -s 640x480:

$ video -v -O file.raw
video device /dev/video:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
640x360: 30, 25
640x480: 20
1280x720: 10
  controls: brightness, contrast, saturation, gain, sharpness, 
white_balance_temperature
Xv adaptor 0, GLAMOR Textured Video:
  encodings: yv12
  max size: 1280x800
using yuy2 encoding
using frame size 640x480 (614400 bytes)
using default frame rate
run time: 3.249037 seconds
frames grabbed: 50
frames played: 49
played fps: 14.773606


Now, when -r 30 is specified, this happens:

$ video -v -r-30--Offile.raw
video device /dev/video:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
640x360: 30, 25
640x480: 20
1280x720: 10
  controls: brightness, contrast, saturation, gain, sharpness, 
white_balance_temperature
Xv adaptor 0, GLAMOR Textured Video:
  encodings: yv12
  max size: 1280x800
using yuy2 encoding
using frame size 640x480 (614400 bytes)
using frame rate 20 fps
run time: 4.714163 seconds
frames grabbed: 72
frames played: 71
played fps: 14.848870

Presumably, as the default -s size is picked,
and the camera cannot do 30 fps in that size,
-r 20 is chosen instead.

If that's correct, the default size
in effect overrides a specified rate.
Is that intended?

It doesn't seem to be the least surprise:
the command line specifies the rate,
and doesn't care about the size.

Would it be preferable if video(1) chose
-s 640x360 in that case, at 30 fps,
obeying the command line option?


When the smaller size is specified explicitly,
the paramaters are obeyed:

$ video -v -r 30 -s 640x360 -O file.raw
video device /dev/video:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
640x360: 30, 25
640x480: 20
1280x720: 10
  controls: brightness, contrast, saturation, gain, sharpness, 
white_balance_temperature
Xv adaptor 0, GLAMOR Textured Video:
  encodings: yv12
  max size: 1280x800
using yuy2 encoding
using frame size 640x360 (460800 bytes)
using frame rate 30 fps
run time: 6.172711 seconds
frames grabbed: 187
frames played: 172
played fps: 27.702576

(The same happens with -r 25,
also supported for 640x360, but not for 640x480.)

Jan


OpenBSD 6.8-beta (GENERIC.MP) #0: Fri Sep 18 11:00:33 CEST 2020
h...@lenovo.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8463781888 (8071MB)
avail mem = 8192229376 (7812MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries)
bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012
bios0: LENOVO 64741EG
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA SSDT 
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) 
EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 798.17 MHz, 06-17-06
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 266MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 798.01 MHz, 06-17-06
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 

Re: PF Natting before filtering

[Peter N. M. Hansteen]

On Mon, Sep 21, 2020 at 02:14:25PM +0200, open...@kene.nu wrote:
> > > can find online seems to suggest otherwise.
> >
> > It would be interesting to hear which shreds of information you found.
> >
> Mainly this which I see now contradicts itself.
> https://forums.freebsd.org/threads/nat-filtering-in-pf-what-happens-if.22783/

It's important to be aware that FreeBSD's PF is ancient, on par with roughly
what was in OpenBSD 4.5. The NAT code on the OpenBSD side of the fence was
totally rewritten for 4.7 which is also IIRC when match was introduced. You may
have noticed that FreeBSD's PF does not have match rules.

I hope you find a workable solution for what you need to do.

All the best,

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Using Acusis USB microphone-speaker from OpenBSD

[Ibsen S Ripsbusker]

To whom it may concern,

I have an Acusis, which should be a USB microphone and speaker.
https://www.crowdsupply.com/antimatter-research/acusis

I have managed to use my Acusis in Trisquel (GNU/Linux) to record and
play simultaneously. I tried this in OpenBSD, but I manage only
to record, never to play, not even at different times, even though the
operating system suggests that audio playing is occurring. Does anyone
have thoughts as to what I could do to make it work? Changing the Acusis
firmware is an option.

Please accept the assurances of my sincerest regards and respect,
Ibsen S. Ripsbusker



# mixerctl
inputs.record=255
inputs.record_mute0=off
outputs.dac=255,255
outputs.dac_mute0=off
outputs.dac_mute1=off
record.enable=sysctl
# cat /etc/sysctl.conf
net.inet.ip.forwarding=1
hw.setperf=0
kern.audio.record=1
# sndioctl  -v
input[0].level=1.000
output[0].level=1.000
output[1].level=1.000
app/aucat0.level=1.000
app/opusdec0.level=1.000
# dmesg
OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34314653696 (32725MB)
avail mem = 33262067712 (31721MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f4d8000 (53 entries)
bios0: vendor American Megatrends Inc. version "2.1" date 01/18/2018
bios0: Supermicro A1SAi
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDAT UEFI APIC BDAT HPET SSDT HEST 
BERT ERST EINJ
acpi0: wakeup devices PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) EHC1(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2400.44 MHz, 06-4d-08
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2400.01 MHz, 06-4d-08
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2400.02 MHz, 06-4d-08
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2400.02 MHz, 06-4d-08
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX1)
acpiprt2 at acpi0: bus 2 (BR04)
acpiprt3 at acpi0: bus 3 (PEX2)
acpiprt4 at acpi0: bus 4 (PEX3)
acpiprt5 at acpi0: bus -1 (PEX4)
acpicpu0 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
"PNP0003" at acpi0 not configured
acpicmos0 at acpi0
"IPI0001" at acpi0 not configured
"PNP0C33" at acpi0 not configured
ipmi at mainbus0 not configured
cpu0: using VERW MDS workaround
cpu0: Enhanced SpeedStep 2400 MHz: speeds: 2400, 2300, 2200, 2100, 2000, 1900, 
1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Atom C2000 Host" rev 

Re: PF Natting before filtering

[openbsd]

On Mon, Sep 21, 2020 at 1:39 PM Peter N. M. Hansteen 
wrote:

> On Mon, Sep 21, 2020 at 12:46:15PM +0200, open...@kene.nu wrote:
>
> > I am seeing what could be expected behaviour but the small shreds of
> info I
> > can find online seems to suggest otherwise.
>
> It would be interesting to hear which shreds of information you found.
>
>
Mainly this which I see now contradicts itself.
https://forums.freebsd.org/threads/nat-filtering-in-pf-what-happens-if.22783/

>
> > I have a box that acts as a router and firewall. It forwards packets from
> > the internal lan (call it vlan100) and sends it natted out on the
> external
> > lan (call it vlan200).
> >
> > The problem I am seeing is that I am unable to filter on vlan200 as the
> > match nat rule (match out on vlan200 nat-to vlan200) seems to rewrite the
> > source address before any filtering is taken into account.
> >
> > Is this intended? I was under the assumption that filtering is done twice
> > in my box, as it forwards, once on ingress (where I have a pass quick
> > everything rule) and one on egress (where the nat is and where I want the
> > filtering done) in a basic Routing->Access->NAT scheme? As it stands now
> I
> > have to filter on ingress.
> >
> > My basic ruleset snippet:
> > pass quick on vlan100 from any to any
> > match out on vlan200 nat-to vlan200
> > pass out on vlan200
> > block out quick on vlan200 from 
>
> If this is your actual ruleset, you are observing the intended behavior.
> match rule actions are applied directly, so the pass rule would see the
> already
> NATed packets as you have specified.
>

I noticed the same from some last minute efforts, the ordering of the match
rule matters.


> In a simple case like this you could optionally move the nat-to action to
> the pass rule and remove the match rule if that fits your needs better.
>

Unfortunately I have many more pass rules that would need NAT applied to it
on a case-by-case basis which is not maintainable so I guess I have to
abort the mission and keep what I have, which is filtering on ingress.


> All the best,
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
>
Thanks for the quick and on-point answer. Probably saved a few hours for
me.

Re: PF Natting before filtering

[Peter N. M. Hansteen]

On Mon, Sep 21, 2020 at 12:46:15PM +0200, open...@kene.nu wrote:
 
> I am seeing what could be expected behaviour but the small shreds of info I
> can find online seems to suggest otherwise.

It would be interesting to hear which shreds of information you found.

> 
> I have a box that acts as a router and firewall. It forwards packets from
> the internal lan (call it vlan100) and sends it natted out on the external
> lan (call it vlan200).
> 
> The problem I am seeing is that I am unable to filter on vlan200 as the
> match nat rule (match out on vlan200 nat-to vlan200) seems to rewrite the
> source address before any filtering is taken into account.
> 
> Is this intended? I was under the assumption that filtering is done twice
> in my box, as it forwards, once on ingress (where I have a pass quick
> everything rule) and one on egress (where the nat is and where I want the
> filtering done) in a basic Routing->Access->NAT scheme? As it stands now I
> have to filter on ingress.
> 
> My basic ruleset snippet:
> pass quick on vlan100 from any to any
> match out on vlan200 nat-to vlan200
> pass out on vlan200
> block out quick on vlan200 from 

If this is your actual ruleset, you are observing the intended behavior. 
match rule actions are applied directly, so the pass rule would see the already
NATed packets as you have specified.

In a simple case like this you could optionally move the nat-to action to
the pass rule and remove the match rule if that fits your needs better.

All the best,

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

PF Natting before filtering

[openbsd]

Hello,

I am seeing what could be expected behaviour but the small shreds of info I
can find online seems to suggest otherwise.

I have a box that acts as a router and firewall. It forwards packets from
the internal lan (call it vlan100) and sends it natted out on the external
lan (call it vlan200).

The problem I am seeing is that I am unable to filter on vlan200 as the
match nat rule (match out on vlan200 nat-to vlan200) seems to rewrite the
source address before any filtering is taken into account.

Is this intended? I was under the assumption that filtering is done twice
in my box, as it forwards, once on ingress (where I have a pass quick
everything rule) and one on egress (where the nat is and where I want the
filtering done) in a basic Routing->Access->NAT scheme? As it stands now I
have to filter on ingress.

My basic ruleset snippet:
pass quick on vlan100 from any to any
match out on vlan200 nat-to vlan200
pass out on vlan200
block out quick on vlan200 from 

Re: Does DNS need TCP?

[Stuart Henderson]

On 2020-09-21, Predrag Punosevac  wrote:
> As of the port blocking unfortunately I am old enough to remember this
> post 
>
> http://cr.yp.to/djbdns/tcp.html#why
>
> and the remark that TCP is only needed for records larger than 512
> bytes. 
>
> "You want to publish record sets larger than 512 bytes. (This is almost
> always a mistake.)"
>
> I had no need for TCP port 53 to be open. Until month and a half ago
> things worked as expected and I have more important things to do than to
> fix things which don't appear to be broken.

DNS is fairly resilient so it can often "work" in a degraded fashion
with the only noticeable problem being some slowness, but relying on
this means that when things are a bit more broken or the situation
changes it will be unusable.

Even in cases where there are no large record sets, it is common for
modern authoritative servers to employ RRL (response rate limiting)
for UDP queries. One common method involves replying with a short
response with the TC flag set (truncated, querier should retry
over TCP) when they receive high request volumes from a particular
source network (often spoofed, using the authoritative server as a
"packet amplifier" - small queries generate a larger response
directed at the spoofed address). The handshake needed for establishing
a TCP connection makes it hard to spoof the source address of a query
(trivial for UDP) allowing legitimate connections to make it through
while not acting as a reliable packet amplifier.

> The following 
>
> https://www.openbsd.org/faq/pf/
>
> is also evolving.

Honestly it hasn't had a thorough refresh/review since before PF syntax
changed to nat-to over 10 years ago, it's only had iterative changes
since then - it will get you up and running but imho it's not a great
basis for writing a maintainable and well-performing ruleset using
current features.

Tagging is only mentioned in "advanced configuration", received-on isn't
shown at all, no use of interface groups (those three I'd consider
pretty basic use), nothing about priority or queues or flow queues (I
guess these are a bit more advanced but I'd consider essential for both
setups with low line capacity, and larger scale setups where you have
high speed ports feeding lower speed lines - either NNIs with leased
line carriers or where you're controlling flows into radio links of say
a hundred Mb from a gigabit port etc).

Re: Relayd SSL Configuration with Cerbot Certs

[Stuart Henderson]

On 2020-09-19, Benjamin Raskin  wrote:
> Hello, Misc;
>
> I'm attempting to configure relayd to work as a reverse proxy, such that all
> web traffic goes through relayd prior to reaching some web server. I'm
> confused as to how I am to configure the ssl cert and key options in the
> relayd configuration. The manual configures the protocol as follows:
>
> http protocol httpfilter {
> tls ca key "/etc/ssl/private/ca.key" password "password123"
> tls ca cert "/etc/ssl/ca.crt"
> }
>
> Where do I get the password for the key? I'm using certbot to generate the
> certs, and at no time was I prompted to enter, or given a password. Am I
> missing something in terms of configuration or cert generation, or have I
> gotten everything all wrong? Thank you in advance.
>
>
> Ben Raskin
>
>

"tls ca key/cert" are for TLS inspection, aka MITM. In that case
you provide a key for a private CA not a regular CA-signed server
certificate, and relayd generates certificates on-the-fly matching the
requested hostname, the password is the password used when encrypting
the key for that CA.

This is not what you want for a regular reverse proxy. For that case
there are predefined filenames, see the FILES section of relayd.conf(5).
(It's not very obvious - last time I tried to do this with relayd
I ended up using ktrace before I remembered how to do it. I normally
go straight to nginx for reverse proxying as it's so much easier to
configure and more flexible...).

Re: Does DNS need TCP?

[Otto Moerbeek]

On Sun, Sep 20, 2020 at 10:17:47PM -0400, Predrag Punosevac wrote:

> Nicolai  wrote :
> 
> > On Sun, Sep 20, 2020 at 12:43:41AM -0400, Predrag Punosevac wrote:
> > 
> > > For number of years I had in my /var/unbound/etc/unbound.conf line
> > > 
> > > do-tcp: no
> > 
> > > To make things worse I was blocking port TCP port 53. 
> > 
> > Just curious, why did you do that?
> 
> When I start using Unbound on OpenBSD it was not the part of the base.
> There was not such a thing as the default unbound.conf file. I vividly
> remember reading NLnet Labs Documentation three full days before
> deciding on my defaults. Even once Unbound became the part of the base,
> (IIRC 5.7) the defaults were not carved in stone. They changed quite a
> bit over the time.

unbound itslef has tcp switched on by default.

> 
> As of the port blocking unfortunately I am old enough to remember this
> post 
> 
> http://cr.yp.to/djbdns/tcp.html#why
> 
> and the remark that TCP is only needed for records larger than 512
> bytes. 
> 
> "You want to publish record sets larger than 512 bytes. (This is almost
> always a mistake.)"
> 
> I had no need for TCP port 53 to be open. Until month and a half ago
> things worked as expected and I have more important things to do than to
> fix things which don't appear to be broken.

He's talking about publishing here. You are talking abbout resolving.
You do not have control about what sizes of record sets other are publishing.

djb is both respected and an outlier. Never take his opinion for
granted without consulting other sources.

Just one example: dig +dnssec akamai.com txt

> 
> The following 
> 
> https://www.openbsd.org/faq/pf/
> 
> is also evolving. It has been almost 15 years since the OpenBSD became
> my daily driver and I would swear (but I am not going to look through
> Internet archive) that there was a time when UDP port 53 was the only
> open domain service in the minimal working example.

I think if you look at the CVS history of the default pf.conf you'll
see that outgoing traffic was never blocked by default.

-Otto

> 
> 
> > 
> > On my authoritative servers roughly 1 in 1000 queries are over TCP, even
> > though no answers are over 512 bytes.  Like most people, I don't use
> > DNSSEC, and unlike most people, I do use DNSCurve.
> > 
> 
> I try to stay away from a universal quantification (a professional
> deformation).  I do use DNSSEC more or less since it became available. I
> used it before the time it became default in unbound.conf file of
> OpenBSD. That is an example of the OpenBSD unbound.conf default which
> actually changed not so long time ago.
> 
> 
> 
> > I've seen "in the wild" authoritative servers that always set TC=1 but
> > that's exceedingly rare and a bad idea for general use.
> > 
> > If you block 53/udp then your life will change for the worse a LOT
> > faster than if you merely block 53/tcp, but both are used, and both
> > should be allowed.  Blocking either will lead to downtime.
> > 
> > If you don't understand the defaults then leave them be.  Put your
> > energy into fixing things that are visibly broken.
> >
> 
> That is exactly the reason that I kept 53/tcp closed past it useful
> shelf life. I actually have more interesting things to do than fixing
> the stuff which are only marginally important for my life. 
> 
> 
> > 
> > Just a related PSA: please don't block ICMP either.  It's important,
> > necessary, and good.
> 
> I am not blocking and I have never blocked it although I do have some
> restrictions in place since I read the first edition of the book of PF. 
> As you know the book is overdue for 4th edition. As you see the only
> constant in life is change. 
> 
> 
> Cheers,
> Predrag
> 
> > 
> > Nicolai
>