Re: IKEv2 - Tunnel all internet traffic from gateway

[Stuart Henderson]

On 2018-01-28, Daniel Ramos  wrote:
> This is a multi-part message in MIME format.
> --20CEEB9B40C0DB09C5429C35
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Hi misc,
>
> I've been beating my head against the wall on and off for the last few 
> weeks - it's past time to ask for help.
>
> I'm trying to tunnel all internet traffic from my internal network 
> (192.168.2.0/24) through another internet-facing machine (10.1.1.0/24) 
> using IKEv2. After trying what seems to be every possibility of pf.conf 
> and iked.conf combinations, I just can't seem to get it right. My 
> closest attempt is to NAT all traffic from 192.168.2.0/24 to appear as 
> virtual IP 10.1.1.2 on the other side, which is then NAT'd out to the 
> internet as usual. The problem with this config is that ALL traffic, 
> including local traffic to 192.168.2.0/24, is tunneled. This is not 
> desired because I can no longer access my local gateway (192.168.2.1), 
> or any locally hosted services.
>
> What I think I need is to be able to specify something like "from 
> 10.1.1.2 (192.168.2.0/24) to !192.168.2.0/24" instead of "...to 
> 0.0.0.0/0" in my iked.conf, but this doesn't seem to be valid syntax. 
> Nor does limiting the tunnel to certain protos/ports, e.g. ... proto { 
> tcp udp } ... port { 53 80 443 }. It seems only one proto and port 
> combination is accepted by iked. I tried adding additional flows 
> manually - i.e. specifying only proto tcp ... port 80 in iked.conf and 
> feeding a file of additional flows via ipsecctl -F, but I receive errors 
> about bad syntax - even though I copied the lines from ipsecctl -sa. It 
> looks like only IKEv1 syntax is accepted there?

What you need is a "bypass flow", I don't think it can be done from
iked.conf but you can try this in ipsec.conf (adapt addresses as needed):

flow from 192.168.46.48/28 to 192.168.46.48/28 type bypass

ipsecctl -f /etc/ipsec.conf to load it at runtime, ipsec=YES in
rc.conf.local to load at boot.

Please follow-up to confirm whether it works for the archive, I've only
done this combined with IKEv1 but I don't see a reason why it wouldn't work.

Re: Good GPU for OpenBSD build?

[Currell Berry]

Thanks for your response and link.  Apology for my ignorance about Xorg
drivers vs kernel drivers -- You are saying that the cards listed on the
nv(4) and radeon(4) pages do not necessarily correspond to what actually
will work, but instead just correspond to code that has been written in
X.org that may or may not have the accompanying kernel support in OpenBSD
to function, correct?

For "radeon" for instance I see a bunch of files at /sys/dev/pci/drm/radeon
-- I guess these files work in conjunction with the support in
MESA/Xenocara in folders like xenocara/lib/mesa/src/gallium/drivers/radeon
?  But perhaps for the nv(4) driver for instance there may or may not be
actual kernel support in OpenBSD?  Also if I were to plug in a card not
listed on any of those lists (a late-model video card for instance), do you
think graphics and multi-monitor support would work at all in general?  My
guess is that it would fall back to software rendering, but I don't know if
there's some sort of lowest-common standard that allows the 2d graphics to
work without acceleration somehow.

Thanks for any input.

-- Currell

On Sun, Jan 28, 2018 at 6:39 PM, mazocomp  wrote:

> I believe this is easy to read: https://www.openbsd.org/amd64.html
> Kernel drivers != X.org drivers
>

Re: Good GPU for OpenBSD build?

[Currell Berry]

Ok, thanks for the info.  I may opt for the Radeon HD6xxx card as I would
like to build with an AMD processor -- and I don't really need too much in
the way of fancy graphics, just the ability to drive multiple monitors
(which it looks like for example an HD6950 has) and watch youtube videos.

-- Currell

On Sun, Jan 28, 2018 at 8:50 PM, Daniel Wilkins 
wrote:

> To save you the search for what the hell northern islands is:
> the best graphics support you'll have is a Kaby Lake processor
> without a graphics card. Failing that you want a high end
> Radeon HD6xxx card (Northern Islands.) Skylake processors may
> be the better option than those, thinking about it: the 6xxx
> cards are pushing 10 years old now.
>

Re: Good GPU for OpenBSD build?

[Daniel Wilkins]

To save you the search for what the hell northern islands is:
the best graphics support you'll have is a Kaby Lake processor
without a graphics card. Failing that you want a high end
Radeon HD6xxx card (Northern Islands.) Skylake processors may
be the better option than those, thinking about it: the 6xxx
cards are pushing 10 years old now.

Re: pcengines apu boards

[Paul B. Henson]

On Wed, Jan 17, 2018 at 12:56:04PM +0100, Christopher Zimmermann wrote:

> I have the same problem and have tried to hunt the bug, but failed so
> far. Have you already identified the quirks linux and freebsd use to
> fix this problem?

No :(, I worked on it for a while but kernel hacking isn't my
speciality. I don't think the specific quirks I was initially trying to
port would have fixed it anyway, as they seemed mainly aimed at data
transfers and I couldn't even get the miniPCI card to get hot plugged
and detected while testing with an external miniPCI to USB adapter
plugged into the internal EHCI header.

I ended up just using the external adapter plugged into the xHCI ports
exposed outside the case. Annoying not to be able to just have it inside
the case, but it works like a champ in this configuration.

Re: vmm networking with ubuntu guest [SOLVED-ish]

[Mike Larkin]

On Tue, Jan 23, 2018 at 06:44:06AM -0800, Carlos Cardenas wrote:
> On Tue, Jan 23, 2018 at 06:38:41PM +1100, tomr wrote:
> > 
> > So. This email was written before I had tried an earlier LTS version of
> > ubuntu as the VMM guest. May the details below help someone else in future! 
> > 
> > Whatever the problem was, my workaround was to use 16.04-LTS instead 17.10
> > 
> > t
> > 
> > --
> > 
> > I'm trying to get an ubuntu guest running, but something is going wrong
> > with its networking. Using the exact same vmd config (apart from disk
> > images and lladdr), I can get both OpenBSD and alpine linux guests
> > running just fine.
> 
> Howdy.
> 
> Thanks for reporting this.
> 
> The issue at hand is that newer versions of ubuntu have an "updated" vionet
> guest driver which is causing issues to the vionet driver in vmd.
> 
> 
> +--+
> Carlos
> 

Yes, I debugged this a few weeks back. It seems that the guest driver in
17.10 is not happy with being told it only has 1 entry in its ring. I got
sidetracked with other things, but should be a simple fix if I get some time.

-ml

Re: Good GPU for OpenBSD build?

[mazocomp]

I believe this is easy to read: https://www.openbsd.org/amd64.html
Kernel drivers != X.org drivers

Re: "uhub1: device problem, disabling port 1" on Zenbook

[Maximilian Pichler]

On Sun, Jan 28, 2018 at 8:12 PM, Kenneth Gober  wrote:
> When you reach the "(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?"
> prompt, enter S then type the following commands to create the sd1
> device entries:
>
> # cd /etc
> # ./MAKEDEV sd1

Thanks! I had confused the absence of the node with the absence of the drive.

I'm assuming you meant:
# cd /dev
# sh ./MAKEDEV sd1

After more testing, it looks like there is non-deterministic
behaviour: at each reboot either the thumb drive is recognized (i.e.
sd1 appears in dmesg) or it isn't (no sd1 in dmesg, but "uhub1: device
problem, disabling port 1"). Sometimes unplugging and replugging the
hub or drive gets it recognized, but not always.

At least this allowed me to install the system, after a lucky reboot...

Re: van Sprundel

[lists]

Sun, 28 Jan 2018 15:11:41 +0100 Hiltjo Posthuma 
> On Sun, Jan 28, 2018 at 12:56:26PM +, Andy Lemin wrote:
> > Really, did he actually post any real vulnerabilities to OpenBSD!
> > 
> > This article has to be govt propaganda..
> > 
> > https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html
> > 
> > I was laughing with tears when I read this..
> > 
> 
> Hey,
> 
> Maybe I shouldn't reply, but I feel this is insulting to the amazing work of
> Van Sprundel. I've also seen better nuanced articles about the same
> presentation talk.
> 
> Sources:
> - https://www.openbsd.org/errata60.html (the batch of patches on August 3 
> 2017).
> - http://undeadly.org/cgi?action=article=20170804053102
> - Slides: 
> https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf
> - https://www.openbsd.org/errata56.html (earlier work).
> 
> Please do more research before you post.
> 

Hi Hiltjo,

His 2017-12-29 talk was obviously an old presentation, help him fix it.

https://media.ccc.de/search/?q=sprundel
https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equally
https://fahrplan.events.ccc.de/congress/2017/Fahrplan/events/8968.html

We all know the BSDs are not sitting on bugs, stale data is misleading.

Kind regards,
Anton Lazarov

Good GPU for OpenBSD build?

[Currell Berry]

Hello,

I am considering building myself a new computer, and I would like to drive
as many as four monitors with it.  3D performance doesn't matter much, I
just would like to have a bunch of functioning screen real-estate.

Do any of you all have any recommendations for video hardware that works
well with OpenBSD and that supports up to four monitors (in my case)?  From
the lists of supported hardware on the radeon(4) and nv(4) manpages, it
seems to me that the Radeon Hawaii R9 (290 & 390 I guess?) series is the
newest/best hardware supported.  Anyone have experience running that?

Thanks,
Currell

Re: gzip compression and httpd/relayd

[Michael Hekeler]

Am Sun, 28 Jan 2018 10:18:30 +0100
schrieb Thuban :

>  
> > Yes it's possible. Make sure to set the appriopriate HTTP headers
> > aswell with relayd: read "Accept-Encoding" and if it's acceptable
> > set "Content-Encoding".
> 
> Indeed, it works.
> 
> relayd.conf : 
> 
>   match response header "Accept-Encoding" value "gzip"
> match response header set "Content-Encoding" value "gzip"
> 
> Then : 
> 
>   cd /var/www/htdocs/site
>   gzip style.css && mv style.css.gz style.css
> 
> Now, open URL pointing to style.css, and here you go.
> 
> However, all your files must be gzipped, or the browser is unhappy.
> 
> Thanks a lot.
> 

Interesting...
Thank you

Re: "uhub1: device problem, disabling port 1" on Zenbook

[Kenneth Gober]

On Sun, Jan 28, 2018 at 4:23 AM, Maximilian Pichler
 wrote:
> I'm trying to install OpenBSD 6.2 on a Zenbook (UX390UA) but it is
> unable to find the installer USB key (after booting from it). The key
> is connected via the USB-A/C adapter/hub that comes with the laptop.
> The same hardware works fine under Linux.

> $ ls /dev/*sd1*
> ls: /dev/*sd1*: No such file or directory

the RAMDISK kernel is extremely space-constrained, so its /dev
directory is not fully populated.

When you reach the "(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?"
prompt, enter S then type the following commands to create the sd1
device entries:

# cd /etc
# ./MAKEDEV sd1
# exit

You will then be returned to the installer and you should be able to
proceed normally.

-ken

Re: Removing FUSE would theoretically make a system more secure?

[Gregor Best]

On Sun, Jan 28, 2018 at 06:11:51PM +0100, who one wrote:
> Hello, 
> 
> "> And what are you defending against?"
> 
> there was/is a great guy that investigated the security of the BSDs, reported 
> a few bugs too: 
> 
> https://www.youtube.com/watch?v=rRg2vuwF1hY=youtu.be=1522
> 
> that lead to ex.: 
> 
> https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/017_fuse.patch.sig
> [...]

By that logic, you've just disabled a piece of code that someone (Helg)
is actively working on and that has security issues fixed. What makes
you so sure there are no deadly bugs in, say, the FAT code? Or drivers
for rare-ish network cards? Or the ~120k lines of code that make up the
driver for Intel graphics cards?

Of course running less code means less of an attack surface. Just make
sure you're actually improving security if that's your goal, not just
diddling around on the fringes of your system and feeling secure because
Fuse is disabled while you're running Chrome which has access to your
~/.ssh/id_ed25519 or ~/.bitcoin/wallet.dat.

> [...]
> So would the mentioned method, by removing the "grep -i fuse
> /sys/conf/GENERIC" and doing re-compile would "disable FUSE"? 
> [...]

If would. But as already mentioned by other people, the barriers to Fuse
are relatively high (You need code exec as root to fiddle with
/dev/fuse0), while code you're actually running may have more of an
impact on your security situation.

-- 
Gregor

Re: Segmentation fault / firefox (core dumped)

[Mihai Popescu]

Just a hint:

http://www.youtube.com/watch?v=FzJJbNRErVQ=30m38s

Re: Removing FUSE would theoretically make a system more secure?

[who one]

Hello, 

"> And what are you defending against?"

there was/is a great guy that investigated the security of the BSDs, reported a 
few bugs too: 

https://www.youtube.com/watch?v=rRg2vuwF1hY=youtu.be=1522

that lead to ex.: 

https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/017_fuse.patch.sig

So would the mentioned method, by removing the "grep -i fuse /sys/conf/GENERIC" 
and doing re-compile would "disable FUSE"? 

Thanks for the syspatch/relinking hint, I forgot about them if I touch the 
kernel!

Thanks!


> Sent: Sunday, January 28, 2018 at 5:15 AM
> From: mar...@martinbrandenburg.com
> To: misc@openbsd.org, whoonet...@mail.com
> Subject: Re: Removing FUSE would theoretically make a system more secure?
>
> > afaik if I would remove the lines that contains "FUSE" and "fuse" from 
> > /sys/conf/GENERIC and re-compile the kernel, that would mean, there will be 
> > no more FUSE support in my kernel after reboot.
> >
> > If so, would this step help to make my system more secure? Ex.: from a 
> > future FUSE related security issue? 
> >
> > just asking theoretically, since I don't use FUSE related stuff, so 
> > thinking of that is unneeded. 
> >
> > or it would just create an unsupported kernel which didn't had any tests 
> > regarding the missing fuse and maybe cause bigger issues and security 
> > issues vs. if I wouldn't touched it? 
> 
> I daresay that removing FUSE support will make you invulnerable to any
> kind of bug in FUSE.  jca has already given you an outline of the
> reasons to believe such a bug, if it exists, is rather unlikely to be
> exploitable.
> 
> You had better consider what you're giving up when you make this change.
> You won't be able to use FUSE.  You won't be able to use syspatch.  I'm
> not sure how it affects kernel relinking.  You'll have to build your
> kernels yourself on all architectures you run for each release and every
> kernel-related erratum.  You'll have to maintain your changes.  You
> can't just say "I'm not sure" as I just did.  You'll have to take
> responsibility for the possibility that running a non-standard
> configuration may introduce bugs.
> 
> And what are you defending against?  Somebody has to get root or a way
> to mount filesystems without root.  We'll assume he's got a way to mount
> filesystems without root, because if he had a way to get root, he
> wouldn't need bother with anything else.  Then he's got to have his FUSE
> exploit which gives him root.  Since he probably doesn't have an account
> on your system, he's got to have a third exploit to start running code
> to begin with.
> 
> Defense in depth is good, but this isn't worth the effort on your part.
> 
> Your security need only be good enough to require an attacker spend more
> than he's willing to spend.
> 
> Martin
> 
> 

Re: Segmentation fault / firefox (core dumped)

[Dumitru Mișu Moldovan]

La 27.01.2018 14:59, Roderick a scris:
> 
> 
> # iridium&
> [2] 14714
> # *** autoupdate was enabled, overriding with false
> iridium(14714) in free(): use after free 0x7e51b6a0
> 
> [2]Abort iridium (core dumped)
> 
> 

Known issue.  You'll need to try launching Iridium several times to
eventually get it to start (sometimes 5 times in a row for me on i386).
This issue was solved for the Chromium port shortly after the last
release, so I'll guess the fix will trickle down to the Iridium port
before the next release. (Someone running Iridium on -current to
confirm/infirm?)  After launching, the browser itself is quite solid,
but tabs will crash from time on time, possibly because of memory
constraints, as I've seen signs of major leaking (eg. with video
streaming running for hours).



One note on SeaMonkey, as it was mentioned in this thread…  While the
interface may seem bloated, the browser is currently the leanest
full-featured one, in my experience.  First of all the Mozilla-based
rendering engine is not that bad to start with.  Also SeaMonkey still
uses only one process for everything, so it's not that memory-intensive.
 Being based on GTK+ 2.x also helps in this regard when compared to its
GTK+ 3.x siblings.

If you also need a full-featured mail client (as in capable of correctly
rendering HTML junk, checking SMIME/PGP signatures etc.) and an IRC
client, you'll get to take even more advantage of its monolithic design.
 I have used it successfully for years on old hardware.  The OpenBSD
port is very solid, thanks to the excellent work of Landry Breuil.

To get the latest version, you'll need to run -current though, and even
then, not all the latest Firefox security fixes will be included, as
Seamonkey's development is slower.  So beware of all the security
implications of this, maybe compensate with NoScript and other tricks.

As a side note, have noticed Firefox Quantum made strides in reducing
memory consumption and has also become much snappier on OpenBSD for me.
I'm typing this on a 9-year old desktop which struggled with latest ESR.
 To the point that sound in other apps (think light media players such
as Deadbeef or ffplay) was sometimes chopped when closing heavy tabs in
Firefox (confused as to why, this old workhorse has 8GB of RAM and a,
premium at the time, Intel SSD).  If you are interested in trying
Firefox Quantum on 6.2, you should follow the instructions at
https://undeadly.org/cgi?action=article=20170425173917.





signature.asc
Description: OpenPGP digital signature

Re: van Sprundel

[Edgar Pettijohn]

On 01/28/18 08:29, Andy Lemin wrote:

Hi.

That’s ok. This list is a place for open and honest conversation :)

My reaction was towards the article trying to say that BSD’s are dying, rather 
than against Van Sprundle or his research.

I’ve read through his slides before and I skim through the erratas each 
upgrade, but this article tries to bloat the truth in my eyes.

So I’m asking the question as to where the reality lies as it stands today?

Linux is such a moving target with so much unnecessary complexity with SystemD, 
that in the bigger picture we can place far more more trust in the BSD’s.

It’s also a pretty serious allegation to cite so many vulnerabilities as still 
being unfixed today? Is this true?

Thanks for your reply :)

A



Sent from a teeny tiny keyboard, so please excuse typos


On 28 Jan 2018, at 14:11, Hiltjo Posthuma  wrote:


On Sun, Jan 28, 2018 at 12:56:26PM +, Andy Lemin wrote:
Really, did he actually post any real vulnerabilities to OpenBSD!

This article has to be govt propaganda..

https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html

I was laughing with tears when I read this..

OpenBSD is the only OS I place any real trust in <3

Is probably the only OS they can’t hack.

And SystemD makes me want to both cry and scream at the same time.

A


Sent from a teeny tiny keyboard, so please excuse typos

Hey,

Maybe I shouldn't reply, but I feel this is insulting to the amazing work of
Van Sprundel. I've also seen better nuanced articles about the same
presentation talk.

Sources:
- https://www.openbsd.org/errata60.html (the batch of patches on August 3 2017).
- http://undeadly.org/cgi?action=article=20170804053102
- Slides: 
https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf
- https://www.openbsd.org/errata56.html (earlier work).

Please do more research before you post.

--
Kind regards,
Hiltjo

Interesting read.  Thanks for sharing.

Re: van Sprundel

[Andy Lemin]

Hi.

That’s ok. This list is a place for open and honest conversation :)

My reaction was towards the article trying to say that BSD’s are dying, rather 
than against Van Sprundle or his research.

I’ve read through his slides before and I skim through the erratas each 
upgrade, but this article tries to bloat the truth in my eyes. 

So I’m asking the question as to where the reality lies as it stands today?

Linux is such a moving target with so much unnecessary complexity with SystemD, 
that in the bigger picture we can place far more more trust in the BSD’s.

It’s also a pretty serious allegation to cite so many vulnerabilities as still 
being unfixed today? Is this true?

Thanks for your reply :)

A



Sent from a teeny tiny keyboard, so please excuse typos

> On 28 Jan 2018, at 14:11, Hiltjo Posthuma  wrote:
> 
>> On Sun, Jan 28, 2018 at 12:56:26PM +, Andy Lemin wrote:
>> Really, did he actually post any real vulnerabilities to OpenBSD!
>> 
>> This article has to be govt propaganda..
>> 
>> https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html
>> 
>> I was laughing with tears when I read this..
>> 
>> OpenBSD is the only OS I place any real trust in <3
>> 
>> Is probably the only OS they can’t hack.
>> 
>> And SystemD makes me want to both cry and scream at the same time.
>> 
>> A
>> 
>> 
>> Sent from a teeny tiny keyboard, so please excuse typos
> 
> Hey,
> 
> Maybe I shouldn't reply, but I feel this is insulting to the amazing work of
> Van Sprundel. I've also seen better nuanced articles about the same
> presentation talk.
> 
> Sources:
> - https://www.openbsd.org/errata60.html (the batch of patches on August 3 
> 2017).
> - http://undeadly.org/cgi?action=article=20170804053102
> - Slides: 
> https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf
> - https://www.openbsd.org/errata56.html (earlier work).
> 
> Please do more research before you post.
> 
> -- 
> Kind regards,
> Hiltjo

Re: van Sprundel

[Hiltjo Posthuma]

On Sun, Jan 28, 2018 at 12:56:26PM +, Andy Lemin wrote:
> Really, did he actually post any real vulnerabilities to OpenBSD!
> 
> This article has to be govt propaganda..
> 
> https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html
> 
> I was laughing with tears when I read this..
> 
> OpenBSD is the only OS I place any real trust in <3
> 
> Is probably the only OS they can’t hack.
> 
> And SystemD makes me want to both cry and scream at the same time.
> 
> A
> 
> 
> Sent from a teeny tiny keyboard, so please excuse typos

Hey,

Maybe I shouldn't reply, but I feel this is insulting to the amazing work of
Van Sprundel. I've also seen better nuanced articles about the same
presentation talk.

Sources:
- https://www.openbsd.org/errata60.html (the batch of patches on August 3 2017).
- http://undeadly.org/cgi?action=article=20170804053102
- Slides: 
https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf
- https://www.openbsd.org/errata56.html (earlier work).

Please do more research before you post.

-- 
Kind regards,
Hiltjo

IKEv2 - Tunnel all internet traffic from gateway

[Daniel Ramos]

Hi misc,

I've been beating my head against the wall on and off for the last few 
weeks - it's past time to ask for help.


I'm trying to tunnel all internet traffic from my internal network 
(192.168.2.0/24) through another internet-facing machine (10.1.1.0/24) 
using IKEv2. After trying what seems to be every possibility of pf.conf 
and iked.conf combinations, I just can't seem to get it right. My 
closest attempt is to NAT all traffic from 192.168.2.0/24 to appear as 
virtual IP 10.1.1.2 on the other side, which is then NAT'd out to the 
internet as usual. The problem with this config is that ALL traffic, 
including local traffic to 192.168.2.0/24, is tunneled. This is not 
desired because I can no longer access my local gateway (192.168.2.1), 
or any locally hosted services.


What I think I need is to be able to specify something like "from 
10.1.1.2 (192.168.2.0/24) to !192.168.2.0/24" instead of "...to 
0.0.0.0/0" in my iked.conf, but this doesn't seem to be valid syntax. 
Nor does limiting the tunnel to certain protos/ports, e.g. ... proto { 
tcp udp } ... port { 53 80 443 }. It seems only one proto and port 
combination is accepted by iked. I tried adding additional flows 
manually - i.e. specifying only proto tcp ... port 80 in iked.conf and 
feeding a file of additional flows via ipsecctl -F, but I receive errors 
about bad syntax - even though I copied the lines from ipsecctl -sa. It 
looks like only IKEv1 syntax is accepted there?


I appreciate any thoughts and assistance.

Regards,

Daniel
OpenBSD 6.2 (GENERIC.MP) #2: Sun Dec 10 21:14:42 CET 2017

r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17033199616 (16244MB)
avail mem = 16509960192 (15745MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xecff0 (90 entries)
bios0: vendor American Megatrends Inc. version "2901" date 10/25/2015
bios0: ASUS All Series
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SSDT SSDT SSDT MCFG HPET SSDT SSDT BGRT UEFI
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
UAR1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) 
RP05(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz, 2498.89 MHz
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2498887240 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz, 2498.56 MHz
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz, 2498.56 MHz
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz, 2498.56 MHz
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz, 2498.56 MHz
cpu4: 

van Sprundel

[Andy Lemin]

Really, did he actually post any real vulnerabilities to OpenBSD!

This article has to be govt propaganda..

https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html

I was laughing with tears when I read this..

OpenBSD is the only OS I place any real trust in <3

Is probably the only OS they can’t hack.

And SystemD makes me want to both cry and scream at the same time.

A


Sent from a teeny tiny keyboard, so please excuse typos

Re: gzip compression and httpd/relayd

[Hiltjo Posthuma]

On Sun, Jan 28, 2018 at 10:18:30AM +0100, Thuban wrote:
>  
> > Yes it's possible. Make sure to set the appriopriate HTTP headers aswell
> > with relayd: read "Accept-Encoding" and if it's acceptable set
> > "Content-Encoding".
> 
> Indeed, it works.
> 
> relayd.conf : 
> 
>   match response header "Accept-Encoding" value "gzip"

This should be: match request header "Accept-Encoding" value "*gzip*" I think.
It should only output gzip if it's an accepted encoding, else some clients
break.

> match response header set "Content-Encoding" value "gzip"
> 
> Then : 
> 
>   cd /var/www/htdocs/site
>   gzip style.css && mv style.css.gz style.css
> 
> Now, open URL pointing to style.css, and here you go.
> 
> However, all your files must be gzipped, or the browser is unhappy.
> 
> Thanks a lot.
> 

You're welcome :)

-- 
Kind regards,
Hiltjo

"uhub1: device problem, disabling port 1" on Zenbook

[Maximilian Pichler]

Hi,

I'm trying to install OpenBSD 6.2 on a Zenbook (UX390UA) but it is
unable to find the installer USB key (after booting from it). The key
is connected via the USB-A/C adapter/hub that comes with the laptop.
The same hardware works fine under Linux.

The initial dmesg (full output below) has:

sd1 at scsibus1 targ 1 lun 0:  SCSI2
0/direct removable
sd1: 3728MB, 512 bytes/sector, 7634944 sectors

...but:

$ ls /dev/*sd1*
ls: /dev/*sd1*: No such file or directory

When un- and replugging the key, the following additional lines appear:

sd1 detached
scsibus1 detached
umass0 detached
uhub1: port 1, set config 0 at addr 3 failed
uhub1: device problem, disabling port 1

When un- and replugging the adapter (with the key in it), the
following additional lines appear:

uhub1 detached
uhub2 detached
uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs, Inc.
USB2.0 Hub" rev 2.10/6.80 addr 2
uhub1: port 1, set config 0 at addr 3 failed
uhub1: device problem, disabling port 1
"VIA Technologies Inc. USB 2.0 BILLBOARD" rev 2.01/3.04 addr 3 at
uhub1 port 2 not configured
uhub2 at uhub0 port 13 configuration 1 interface 0 "VIA Labs, Inc.
USB3.0 Hub" rev 3.00/6.85 addr 4

Using another type of USB hub and an external HDD gives similar results:

uhub1 at uhub0 port 1 configuration 1 interface 0 "Apple Inc. USB2.0
Hub" rev 2.10/45.28 addr 2
"Apple Inc. USB-C Digital AV Multiport Adapter" rev 2.10/2.35 addr 3
at uhub1 port 2 not configured
uhub2 at uhub0 port 13 configuration 1 interface 0 "Apple Inc. USB3.0
Hub" rev 3.00/45.28 addr 4
umass0 at uhub2 port 1 configuration 1 interface 0 "Seagate Expansion"
rev 3.00/0.00 addr 8
mass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0:  SCSI4 0/direct fixed
sd1: 3815447MB, 512 bytes/sector, 7814037167 sectors
uhub1 detached
uhub1 at uhub0 port 1 configuration 1 interface 0 "Apple Inc. USB2.0
Hub" rev 2.10/45.28 addr 2
"Apple Inc. USB-C Digital AV Multiport Adapter" rev 2.10/2.35 addr 3
at uhub1 port 2 not configured

Any help with this would be much appreciated!

Thanks

Max


Initial dmesg:

OpenBSD 6.2 (RAMDISK_CD) #132: Tue Oct  3 21:26:51 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 17037766656 (16248MB)
avail mem = 16517648384 (15752MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xeb350 (31 entries)
bios0: vendor American Megatrends Inc. version "UX390UAK.312" date 04/25/2017
bios0: ASUSTeK COMPUTER INC. UX390UAK
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT ECDT MCFG FIDT SSDT MSDM SSDT HPET
UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 DMAR TPM2
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 2904.00 MHz
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 290400 Hz
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 3 (RP09)
acpiprt5 at acpi0: bus -1 (RP10)
acpiprt6 at acpi0: bus -1 (RP11)
acpiprt7 at acpi0: bus -1 (RP12)
acpiprt8 at acpi0: bus -1 (RP13)
acpiprt9 at acpi0: bus 1 (RP01)
acpiprt10 at acpi0: bus -1 (RP02)
acpiprt11 at acpi0: bus -1 (RP03)
acpiprt12 at acpi0: bus -1 (RP04)
acpiprt13 at acpi0: bus -1 (RP05)
acpiprt14 at acpi0: bus 2 (RP06)
acpiprt15 at acpi0: bus -1 (RP07)
acpiprt16 at acpi0: bus -1 (RP08)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP14)
acpiprt22 at acpi0: bus -1 (RP15)
acpiprt23 at acpi0: bus -1 (RP16)
acpiec at acpi0 not configured
acpicpu at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured

Re: gzip compression and httpd/relayd

[Thuban]

 
> Yes it's possible. Make sure to set the appriopriate HTTP headers aswell
> with relayd: read "Accept-Encoding" and if it's acceptable set
> "Content-Encoding".

Indeed, it works.

relayd.conf : 

match response header "Accept-Encoding" value "gzip"
match response header set "Content-Encoding" value "gzip"

Then : 

cd /var/www/htdocs/site
gzip style.css && mv style.css.gz style.css

Now, open URL pointing to style.css, and here you go.

However, all your files must be gzipped, or the browser is unhappy.

Thanks a lot.