Re: IPsec and MTU / fragmentation

2020-02-10 Thread Janne Johansson
Den mån 10 feb. 2020 kl 20:53 skrev Simen Stavdal :

> I think the more complete solution is to run some gif/gre inside ipsec and
>> set low-enough MTU on that one, so it can correctly fragment incoming
>> packets, and optionally rebuild the packets at the remote end, while also
>> giving you an idea of "state" on the link so you optionally can run things
>> like routing daemons or something that cares about and acts on tunnel
>> state. This would cause even lower MTU, but still allow all kinds of
>> traffic and not just the "popular" one.
>>
>
> So, how will your client/server know about this lower mtu? And df bit is
> set more often than not, so fragmentation is now allowed in a lot of cases.
> This is exactly the problem that started this thread...
>
>>
>>
If the inner gif/gre tunnel has a lower mtu, then it being a layer-3 tunnel
will be able to fragment all incoming ip before sending it into the ipsec,
which will not fragment for you.
The clients will not have to change, nor any other protocol that sends ip
via the double-tunnel.

-- 
May the most significant bit of your life be positive.


Re: IPsec and MTU / fragmentation

2020-02-10 Thread Janne Johansson
Den mån 10 feb. 2020 kl 18:18 skrev Peter Müller :

> Hello Lucas,
> as far as I understood, setting MTU on encN interfaces is not supported
> since it is not mentioned by enc(4) and setting it manually fails:
>
> > machine# ifconfig enc0 mtu 1500
> > ifconfig: SIOCSIFMTU: Inappropriate ioctl for device
>

enc(4) interfaces are not to ipsec, what tun(4) is for OpenVPN.
It is not a config device per tunnel.

-- 
May the most significant bit of your life be positive.


Re: aucat - join two mono files into stereo

2020-02-10 Thread Jan Stary
On Feb 10 23:29:18, a...@caoua.org wrote:
> On Mon, Feb 10, 2020 at 10:45:02PM +0100, Jan Stary wrote:
> > I must be missing something obvious.
> > How does aucat mix two mono files into one stereo file
> > as the left and right channel, respectively?
> > 
> 
> You have to specify which file goes to which channel,
> for instance:
> 
>   aucat -n -c 0:0 -i 1.wav -c 1:1 -i 2.wav -c 0:1 -o mix.wav
> 
> 
> There is a multi-channel bus. Inputs files (-i) are written to the bus
> and output files (-o) are read from the bus. Bus channels are numbered
> from 0 to the greatest channel of all files. The per-file -c option
> specifies which channels of the bus the file will provide or consume.

Thank you. The following diff attempts to add a short explanation
along these lines to the manpage. (Is it to wordy?)

Index: aucat.1
===
RCS file: /cvs/src/usr.bin/aucat/aucat.1,v
retrieving revision 1.114
diff -u -p -r1.114 aucat.1
--- aucat.1 24 Apr 2017 06:47:41 -  1.114
+++ aucat.1 11 Feb 2020 06:45:55 -
@@ -79,10 +79,17 @@ The options are as follows:
 The buffer size of the audio device in frames.
 Default is 7680.
 .It Fl c Ar min : Ns Ar max
-The range of audio file channel numbers.
-The default is
-.Cm 0:1 ,
-i.e. stereo.
+The range of audio channels.
+For input files, these are the channels the file contributes
+to the global multi-channel bus;
+for output files, these are the channels the file consumes.
+option for details about channel routing.
+If the file header specifies a number of channels,
+.Nm
+will use that by default.
+Otherwise,
+.Cm 0:1
+is the default.
 .It Fl d
 Increase log verbosity.
 .It Fl e Ar enc

> > This mixes the two mono files into the left channel,
> > leaving the right channel empty:
> > 
> > $ aucat -n -i 1.wav -i 2.wav -o mix.wav  
> > 
> 
> Yes, by default '-c 0:0' is assumed for mono files,

For files with a header, aucat uses what the header said about channels.
That makes the above sentence seem to be in conflict with

The default is 0:1, i.e. stereo.

in the current manpage (also addressed in the above diff).

Jan




Re: aucat - join two mono files into stereo

2020-02-10 Thread Jan Stary
On Feb 10 20:31:35, dp925...@gmail.com wrote:
> On 2/10/20 18:07, Jan Stary wrote:
> > +Create a stereo file having two given mono channels:
> 
> Might be better to say:
> 
> Combine two mono files into a single stereo file, one mono file per channel:
> 
> "Create a stereo file" makes it sound like you're creating it out of thin
> air, or something. :-)

Yes, thank you. Below I tweaked the wording some more to make it
as similar to the existing text as possible ("mix" not "combine"),
while retaining the point that each of the mono files ends up
in one channel of the stereo.

Jan

Index: aucat.1
===
RCS file: /cvs/src/usr.bin/aucat/aucat.1,v
retrieving revision 1.114
diff -u -p -r1.114 aucat.1
--- aucat.1 24 Apr 2017 06:47:41 -  1.114
+++ aucat.1 11 Feb 2020 06:26:57 -
@@ -285,8 +285,14 @@ $ aucat -r 44100 -c 2:3 -o file1.wav -c 
 .Pp
 Split a stereo file into two mono files:
 .Bd -literal -offset indent
-$ aucat -n -i stereo.wav -c 0:0 -o left.wav \e
-   -c 1:1 -o right.wav
+$ aucat -n -i stereo.wav \e
+   -c 0:0 -o left.wav -c 1:1 -o right.wav
+.Ed
+.Pp
+Mix two mono files into a stereo file, one per channel:
+.Bd -literal -offset indent
+$ aucat -n -c 0:0 -i left.wav -c 1:1 -i right.wav \e
+   -c 0:1 -o stereo.wav   
 .Ed
 .Sh SEE ALSO
 .Xr audioctl 1 ,



Re: Kibana/Elasticsearch fail

2020-02-10 Thread Eric Zylstra
You rock!  I’ll let you know it works for me when I get a chance.

EZ


Sent from my iPhone

> On Feb 10, 2020, at 11:19 PM, Aaron Bieber  wrote:
> 
> On Thu, 06 Feb 2020 at 23:31:01 -0600, Eric Zylstra wrote:
>> I’ve installed the ELK packages (Elasticsearch, Logstash, Kibana) using 
>> pkg_add.  Installs went fine.  I checked out the pkg documentation 
>> (pkg_reames) and followed the steps for those that had documentation to 
>> follow.
>> 
>> When I boot, Logstash and Kibana fail.  I can use rcctl to start Logstash 
>> with no problem.  When I try to start Kibana, the following is what I see:
>> 
>> # rcctl -d start kibana
>> doing _rc_parse_conf
>> doing _rc_quirks
>> kibana_flags empty, using default ><
>> doing _rc_parse_conf /var/run/rc.d/kibana
>> doing _rc_quirks
>> doing rc_check
>> kibana
>> doing rc_start
>> doing _rc_wait start
>> doing rc_check
>> No home directory /nonexistent!
>> Logging in with home = "/".
>> Kibana does not support the current Node.js version v10.16.3. Please use 
>> Node.js v>=10.15.0 <10.16.
>> doing _rc_rm_runfile
>> (failed)
>> 
>> 
>> I’m not sure what to do with this.  Why is Logstash not starting on reboot?  
>> Why does Kibana fail?  I assume there is some config that need be done, 
>> because that Node.js error wouldn’t have made it to distribution, right?
> 
>> that Node.js error wouldn’t have made it to distribution
> 
> It did, and it's entirely my fault.
> 
> Kibana is failing because it is very strict about the version of node it wants
> to use (hence the "Kibana does not support.." message). 
> 
> Apparently the tests I had run to verify this update worked failed:
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/kibana/patches/patch-package_json?rev=1.4=text/x-cvsweb-markup
> 
> Here is a diff that fixes it for 6.6 (you will have to build it from ports
> until (if?) a proper fix is in place).
> 
> https://deftly.net/patches/kibana-6.6.1.diff
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/kibana/Makefile,v
> retrieving revision 1.32
> diff -u -p -r1.32 Makefile
> --- Makefile28 Sep 2019 09:37:54 -1.32
> +++ Makefile11 Feb 2020 04:13:52 -
> @@ -3,7 +3,7 @@
> COMMENT=browser based analytics/search interface to ElasticSearch
> 
> V =6.6.1
> -REVISION =1
> +REVISION =2
> PKGNAME =kibana-${V}
> DISTNAME =kibana-oss-${V}-darwin-x86_64
> 
> Index: patches/patch-package_json
> ===
> RCS file: /cvs/ports/www/kibana/patches/patch-package_json,v
> retrieving revision 1.4
> diff -u -p -r1.4 patch-package_json
> --- patches/patch-package_json13 May 2019 22:08:11 -1.4
> +++ patches/patch-package_json11 Feb 2020 04:13:52 -
> @@ -8,7 +8,7 @@ Index: package.json
>},
>"engines": {
> -"node": "10.15.1"
> -+"node": ">=10.15.0 <10.16"
> ++"node": "10.16.3"
>}
> -}
> \ No newline at end of file
> 
>> 
>> Thanks,
>> 
>> EZ
> 
> -- 
> PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE



Re: Kibana/Elasticsearch fail

2020-02-10 Thread Aaron Bieber
On Thu, 06 Feb 2020 at 23:31:01 -0600, Eric Zylstra wrote:
> I’ve installed the ELK packages (Elasticsearch, Logstash, Kibana) using 
> pkg_add.  Installs went fine.  I checked out the pkg documentation 
> (pkg_reames) and followed the steps for those that had documentation to 
> follow.
> 
> When I boot, Logstash and Kibana fail.  I can use rcctl to start Logstash 
> with no problem.  When I try to start Kibana, the following is what I see:
> 
> # rcctl -d start kibana
> doing _rc_parse_conf
> doing _rc_quirks
> kibana_flags empty, using default ><
> doing _rc_parse_conf /var/run/rc.d/kibana
> doing _rc_quirks
> doing rc_check
> kibana
> doing rc_start
> doing _rc_wait start
> doing rc_check
> No home directory /nonexistent!
> Logging in with home = "/".
> Kibana does not support the current Node.js version v10.16.3. Please use 
> Node.js v>=10.15.0 <10.16.
> doing _rc_rm_runfile
> (failed)
> 
> 
> I’m not sure what to do with this.  Why is Logstash not starting on reboot?  
> Why does Kibana fail?  I assume there is some config that need be done, 
> because that Node.js error wouldn’t have made it to distribution, right?

> that Node.js error wouldn’t have made it to distribution

It did, and it's entirely my fault.

Kibana is failing because it is very strict about the version of node it wants
to use (hence the "Kibana does not support.." message). 

Apparently the tests I had run to verify this update worked failed:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/kibana/patches/patch-package_json?rev=1.4=text/x-cvsweb-markup

Here is a diff that fixes it for 6.6 (you will have to build it from ports
until (if?) a proper fix is in place).

https://deftly.net/patches/kibana-6.6.1.diff

Index: Makefile
===
RCS file: /cvs/ports/www/kibana/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- Makefile28 Sep 2019 09:37:54 -  1.32
+++ Makefile11 Feb 2020 04:13:52 -
@@ -3,7 +3,7 @@
 COMMENT=   browser based analytics/search interface to ElasticSearch
 
 V =6.6.1
-REVISION = 1
+REVISION = 2
 PKGNAME =  kibana-${V}
 DISTNAME = kibana-oss-${V}-darwin-x86_64
 
Index: patches/patch-package_json
===
RCS file: /cvs/ports/www/kibana/patches/patch-package_json,v
retrieving revision 1.4
diff -u -p -r1.4 patch-package_json
--- patches/patch-package_json  13 May 2019 22:08:11 -  1.4
+++ patches/patch-package_json  11 Feb 2020 04:13:52 -
@@ -8,7 +8,7 @@ Index: package.json
},
"engines": {
 -"node": "10.15.1"
-+"node": ">=10.15.0 <10.16"
++"node": "10.16.3"
}
 -}
 \ No newline at end of file

> 
> Thanks,
> 
> EZ

-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE



Re: syspatch(8) return values?

2020-02-10 Thread Antoine Jacoutot
On Mon, Feb 10, 2020 at 12:12:12PM -0500, Allan Streib wrote:
> Antoine Jacoutot  writes:
> 
> > "patches waiting, but didn't do anything" might be interesting (i.e
> > patches are available); dunno...
> 
> syspatch -c

?

-- 
Antoine



Re: inteldrm switches automatically to full brightness (100%)

2020-02-10 Thread Volker Nowarra
perfect! 
I did a reboot, and gave it at the kernel prompt a "boot -c", 
to enterinto UKC. It would allow to "find acpivideo", which 
I disabled. Booting OpenBSD66 into xenodem will go with 
full brightness, but once in a terminal window I can do:

$ doas wsconsctl display.brightness=6  
display.brightness -> 5.97%
$ doas wsconsctl display.brightness=27
display.brightness -> 26.89%
$ doas wsconsctl display.brightness=75  
display.brightness -> 74.91%

and the screen now adapts brightness as desired. 

thx so much,
Volker

On Sun, Feb 09, 2020 at 01:44:54PM +0100, Caspar Schutijser wrote:
> 
> Your email triggered me to look into this because I have a somewhat
> comparable laptop on my desk (dmesg below) and it suffers from the same
> problem. In the archives, I found a couple of things that could help:
> 
> 1. Disable acpivideo(4) and/or acpivout(4) using UKC [1] [2].
> 
> 2. Use jcs' intel_backlight_fbsd [3], see
> https://github.com/jcs/intel_backlight_fbsd
> 
> Both approaches allow me to control the brightness of the screen. FWIW,
> output of Linux running on this machine:
>   $ ls /sys/class/backlight/
>   intel_backlight
> 
> Best regards,
> Caspar Schutijser
> 
> 
> [1] https://marc.info/?l=openbsd-bugs=152699304722212=2
> [2] https://marc.info/?l=openbsd-bugs=142787936328279=2
> [3] https://marc.info/?l=openbsd-bugs=149583867702445=2
> 
> 
> 



Re: aucat - join two mono files into stereo

2020-02-10 Thread Jan Stary
On Feb 10 23:29:18, a...@caoua.org wrote:
> On Mon, Feb 10, 2020 at 10:45:02PM +0100, Jan Stary wrote:
> > I must be missing something obvious.
> > How does aucat mix two mono files into one stereo file
> > as the left and right channel, respectively?
> > 
> 
> You have to specify which file goes to which channel,
> for instance:
> 
>   aucat -n -c 0:0 -i 1.wav -c 1:1 -i 2.wav -c 0:1 -o mix.wav
> 
> 
> There is a multi-channel bus. Inputs files (-i) are written to the bus
> and output files (-o) are read from the bus. Bus channels are numbered
> from 0 to the greatest channel of all files. The per-file -c option
> specifies which channels of the bus the file will provide or consume.

Thank you, that was my confusion: the -c channel numbers are global.

Without realizing that, the -c 1:1 seems strange for a mono file.
In fact, the wording of

  -c min:max
 The range of audio file channel numbers.
 The default is 0:1, i.e. stereo.

makes it seems erroneous to specify -c 1:1 for a mono file:
being mono, it doesn't even have a '1' channel.

Could you please add something to the effect of your paragraph above?
I can't think of a wording that would be short and clear.

Would you please consider including the following EXAMPLE
to accompany the one that't there now (spliting stereo)?
(I break the cmdline between -i and -o in both cases.)

Index: aucat.1
===
RCS file: /cvs/src/usr.bin/aucat/aucat.1,v
retrieving revision 1.114
diff -u -p -r1.114 aucat.1
--- aucat.1 24 Apr 2017 06:47:41 -  1.114
+++ aucat.1 10 Feb 2020 22:44:08 -
@@ -285,8 +285,14 @@ $ aucat -r 44100 -c 2:3 -o file1.wav -c 
 .Pp
 Split a stereo file into two mono files:
 .Bd -literal -offset indent
-$ aucat -n -i stereo.wav -c 0:0 -o left.wav \e
-   -c 1:1 -o right.wav
+$ aucat -n -i stereo.wav \e
+   -c 0:0 -o left.wav -c 1:1 -o right.wav
+.Ed
+.Pp
+Create a stereo file having two given mono channels:
+.Bd -literal -offset indent
+$ aucat -n -c 0:0 -i left.wav -c 1:1 -i right.wav \e
+   -c 0:1 -o stereo.wav   
 .Ed
 .Sh SEE ALSO
 .Xr audioctl 1 ,


> > Turning -j on, this mixes each of the two mono files
> > into both the left and the right channel of the stereo output:
> > 
> > $ aucat -j on -n -i 1.wav -i 2.wav -o mix.wav  
> > 
> > Having -j on,
> > 
> > a single source may be sent to multiple destinations
> > and multiple sources may be mixed into a single destination.
> > 
> > Here, each of 1.wav and 2.wav is indeed sent to multiple destinations,
> > namely both the left and right channel of the stereo output. However,
> > "multiple sources are mixed into a single destination" even with -j off:
> > above, both 1.wav and 2.wav end up in the left channel.

This still seems a bit unclear: "multiple sources being mixed into
a single destination" is not exclusively a feature of -j on,
but the current wording makes it sound that way.

Jan



Re: Dell Latitude e6400 OpenBSD Drive Issue

2020-02-10 Thread Aaron Mason
On Tue, Feb 11, 2020 at 3:04 AM Adam Thompson  wrote:
>
> [SNIP]
>
> The older the Latitude, the harder it is to open, but even an E6400 is
> pretty easy, even if you've never opened up a laptop before.

Yes.  The E6400 and E6410 were favourites of mine, with a single
spring-mounted screw and a slide clip holding the bottom in place.
The E6420 with its eleventy billion screws on the base (none held in
place with anything) was a major step backwards, but still easier than
many business-grade laptops I'd seen.

>
> Good luck,
> -Adam
>


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



Re: aucat - join two mono files into stereo

2020-02-10 Thread Alexandre Ratchov
On Mon, Feb 10, 2020 at 10:45:02PM +0100, Jan Stary wrote:
> I must be missing something obvious.
> How does aucat mix two mono files into one stereo file
> as the left and right channel, respectively?
> 

You have to specify which file goes to which channel,
for instance:

aucat -n -c 0:0 -i 1.wav -c 1:1 -i 2.wav -c 0:1 -o mix.wav


There is a multi-channel bus. Inputs files (-i) are written to the bus
and output files (-o) are read from the bus. Bus channels are numbered
from 0 to the greatest channel of all files. The per-file -c option
specifies which channels of the bus the file will provide or consume.

> This mixes the two mono files into the left channel,
> leaving the right channel empty:
> 
> $ aucat -n -i 1.wav -i 2.wav -o mix.wav  
> 

Yes, by default '-c 0:0' is assumed for mono files,
so both go to the left one.

> That surprises me; the -j option says:
>   
>   If the flag is off, then each source channel is routed
>   to a single destination channel, possibly discarding channels. 
> 
> Here the -j is off (by default), so 1.wav is routed
> into a single destination channel, namely the left;
> 2.wav is also routed into a single channel: the left.
> Is that intended?
> 

Yes. We want two files specified the same way to be routed to the same
destination (ie file position on the command line shouldn't matter).

> Turning -j on, this mixes each of the two mono files
> into both the left and the right channel of the stereo output:
> 
> $ aucat -j on -n -i 1.wav -i 2.wav -o mix.wav  
> 
> Having -j on,
> 
>   a single source may be sent to multiple destinations
>   and multiple sources may be mixed into a single destination.
> 
> Here, each of 1.wav and 2.wav is indeed sent to multiple destinations,
> namely both the left and right channel of the stereo output. However,
> "multiple sources are mixed into a single destination" even with -j off:
> above, both 1.wav and 2.wav end up in the left channel.
> 



aucat - join two mono files into stereo

2020-02-10 Thread Jan Stary
I must be missing something obvious.
How does aucat mix two mono files into one stereo file
as the left and right channel, respectively?

This mixes the two mono files into the left channel,
leaving the right channel empty:

$ aucat -n -i 1.wav -i 2.wav -o mix.wav  

That surprises me; the -j option says:

If the flag is off, then each source channel is routed
to a single destination channel, possibly discarding channels. 

Here the -j is off (by default), so 1.wav is routed
into a single destination channel, namely the left;
2.wav is also routed into a single channel: the left.
Is that intended?


Turning -j on, this mixes each of the two mono files
into both the left and the right channel of the stereo output:

$ aucat -j on -n -i 1.wav -i 2.wav -o mix.wav  

Having -j on,

a single source may be sent to multiple destinations
and multiple sources may be mixed into a single destination.

Here, each of 1.wav and 2.wav is indeed sent to multiple destinations,
namely both the left and right channel of the stereo output. However,
"multiple sources are mixed into a single destination" even with -j off:
above, both 1.wav and 2.wav end up in the left channel.

Jan



Re: IPsec and MTU / fragmentation

2020-02-10 Thread Simen Stavdal
On Mon, 10 Feb 2020 at 17:00, Janne Johansson  wrote:

> Den mån 10 feb. 2020 kl 16:27 skrev Simen Stavdal :
>
>> This is more a discussion about scalability and practical implementation.
>> We both know that PMTU will work partly at best, your entire path back
>> must support this, and also, the "offending" client must allow inbound
>> control messages on their host firewall for this to work.
>> And even if the packets are received by the client, will it support and
>> adjust MSS? I have seen a lot of clients not adhering to standards.
>>
>> Modifying thousands of clients (via dhcp options for instance) to use a
>> fixed MTU will affect other applications too (if you choose to go that
>> route), not just the ones that need to traverse a tight ipsec tunnel.
>> Would you adjust all your clients just because you had a single path
>> using SLIP in your network?
>>
>
> I would want for noone to ever have to know the complete path, slip or no
> slip.
>
>
>> Point is, there is no perfect solution to this issue, there are just
>> different ways of solving bits and bobs on the way.
>> Adjust mss will work just fine for all tcp protocols, and no, not for UDP
>> because it does not use a three way handshake (no MSS to adjust).
>> In my opinion, max-mss works very well in most cases, especially when you
>> have full control of the tunnel you are using (as is the case of Lucas'
>> original question).
>> We use it extensively in many of our applications in my workplace, and as
>> of yet has not represented any big issues, so it is a practically good way
>> to solve this issue.
>>
>
> I think the more complete solution is to run some gif/gre inside ipsec and
> set low-enough MTU on that one, so it can correctly fragment incoming
> packets, and optionally rebuild the packets at the remote end, while also
> giving you an idea of "state" on the link so you optionally can run things
> like routing daemons or something that cares about and acts on tunnel
> state. This would cause even lower MTU, but still allow all kinds of
> traffic and not just the "popular" one.
>

So, how will your client/server know about this lower mtu? And df bit is
set more often than not, so fragmentation is now allowed in a lot of cases.
This is exactly the problem that started this thread...

>
> I am somewhat trying to care for the ones that make a site-2-site ipsec
> which may work for the initial setup, and later find out that more than one
> non-tcp kind of traffic doesn't work without understanding why ssh,http
> works but not list-of-things-like
> mosh,wireguard,quic,yet-another-layer-of-ipsec,hosting-udp-game doesn't.
>
so, I agree that it would be nice that all protocols would work, but
ultimately the client/server refusing to use fragmentation is really the
problem, when MTU is too small, and clients insist on big packets.

>
> As for UDP, there are options here too in pf.conf (like no-df), but
>> personally I have not tested this, but it would be fun to try. It says it
>> supports IPv4 (which would include TCP, UDP and ICMP).
>> Would be interesting to find if UDP enforces DF in most cases.
>>
>
> no-df in PF more or less controls if it will silently drop fragments that
> arrive which has DF set. Linux used/uses to send such udp, for much
> enjoyment. "noone else should fragment, but I just did and you as the
> packet checker can't know who did"
>

> --
> May the most significant bit of your life be positive.
>


Re: syspatch(8) return values?

2020-02-10 Thread Adam Thompson

On 2020-02-08 06:03, Antoine Jacoutot wrote:

On Fri, Jan 31, 2020 at 09:03:59AM -0600, Adam Thompson wrote:

There's no mention of what syspatch(8) returns, in the manpage.

I can prove quickly enough that it exits(0) when there's nothing to 
do, but
I'm more interested in knowing (for automation purposes) what the 
return
values are in other circumstances, and all my systems are already up 
to

date.  Before standing up yet another system, I figured I'd ask here.

I can think of four scenarios syspatch(8) perhaps ought to 
distinguish, at

least I'm interested in these 4 outcomes:
  1. nothing to do
  2. patches waiting, but didn't do anthing
  3. patches applied
  4. something went wrong

Can I reliably tell based on $? or do I have to parse the output?


Most likely parse, yes.

"patches waiting, but didn't do anything" might be interesting (i.e 
patches are

available); dunno...


Equally if not more interesting would be "I tried to apply patches but 
failed somehow".  Which happened to me, and which is why I asked in the 
first place.
*sigh*  I'll try to propose some bad diffs [if I'm writing them, they'll 
be bad] someday soon.

-Adam



Re: IPsec and MTU / fragmentation

2020-02-10 Thread Peter Müller
Hello Lucas,

as far as I understood, setting MTU on encN interfaces is not supported
since it is not mentioned by enc(4) and setting it manually fails:

> machine# ifconfig enc0 mtu 1500
> ifconfig: SIOCSIFMTU: Inappropriate ioctl for device

If you do not want to use GRE tunnels or gif interfaces, I suppose truncating
MSS via pf might be an acceptable but not elegant solution:

> match on enc0 scrub (max-mss 1394)

1394 bytes is intentional as the remote end has an interface MTU of 1488 bytes
configured (behind a DSL connection using VLANs).

That being said, I bumped into some reproducible but not deterministic crashes
which are most likely related to IPsec connections as the same system runs
stable using OpenVPN. Please refer to 
https://marc.info/?l=openbsd-bugs=158048415032524=2
for further information - unfortunately, there is no solution for this yet.

Thanks, and best regards,
Peter Müller

> Hi misc@,
> 
> I've set up an IPsec tunnel to for serving my website from my home. The
> tunnel works quite well most of the time, but if I try to deliver big
> files over it, the HTTP client never gets a response. After some
> testing, if I ran in the HTTP server end
> 
>   perl -e 'print "a" x 1386;' | doas nc -l 10.200.0.80 80
> 
> client receives 1386 "a"s, but with any bigger size the client sees no
> response at all.
> 
> This smells of MTU / fragmentation issues, but I don't know enough about
> networks to configure it properly. Is this the case? Any recommendations
> on how to configure a sensible value? Any clue sticks? I can bang
> different MTUs until it works, but that solution doesn't seem to scale.
> You can find my iked and pf configs below.
> 
> Also would like to understand why it happens, so pointers to docs are
> more than welcome.
> 
> Thanks in advance,
> -Lucas
> 
> Initiator /etc/iked.conf:
> 
>   initiator_www = 10.200.0.80
>   initiator_peer =192.0.2.1
>   responder = 198.51.100.1
> 
>   ikev2 "www" active proto tcp \
>   from $initiator_www port 80 to $responder \
>   peer $responder \
>   srcid initiator dstid responder \
>   tag IPSECWWW
> 
> Initiator /etc/pf.conf:
> 
>   set block-policy drop
>   set loginterface egress
>   set skip on lo0
> 
>   block all
> 
>   pass out quick on { egress enc0 }
> 
>   pass in quick on enc0 tagged IPSECWWW
>   pass in on egress proto tcp to port ssh
>   pass in on egress inet proto icmp all
>   pass in on egress inet6 proto ipv6-icmp all
> 
> Responder /etc/iked.conf:
> 
>   initiator_www = 10.200.0.80
>   initiator_peer =192.0.2.1
>   responder = 198.51.100.1
> 
>   ikev2 "www" passive proto tcp \
>   from $responder to $initiator_www port 80 \
>   peer $initiator_peer \
>   srcid responder dstid initiator \
>   tag IPSECWWW
> 
> Responder /etc/pf.conf:
> 
>   set block-policy drop
>   set loginterface egress
>   set skip on lo0
> 
>   block log all
> 
>   pass out quick on egress
> 
>   pass in log on egress proto udp from any to (egress) \
>   port { isakmp ipsec-nat-t }
>   pass in log on egress proto esp from any to (egress)
>   pass in log on enc0 tagged IPSECWWW
>   pass out log on enc0
> 
>   pass in on egress proto tcp to port { ssh http https }
>   pass in on egress inet proto icmp all
>   pass in on egress inet6 proto icmp6 all
> 



Re: syspatch(8) return values?

2020-02-10 Thread Allan Streib
Antoine Jacoutot  writes:

> "patches waiting, but didn't do anything" might be interesting (i.e
> patches are available); dunno...

syspatch -c

Allan



Re: No traffic from/to road warrior's LAN hosts when IKEv2 VPN is connected

2020-02-10 Thread Martin
I can even ping any internet host from road warrior's LAN interface when iked 
is connected:

$ ping -I 192.168.0.1 remote_host.com -> works as should be

But no any traffic from 192.168.0.10 host except successful DNS 
queries/responses from/to Road Warrior's local DNS resolver.

$ telnet remote_host.com 80 -> from 192.168.0.10 LAN host is always fail. I can 
see ACKs from remote_host.com 80 from IPsec virtual 10.0.1.2 to 
192.168.0.10:80, but no connection.

All traffic goes trough Road Warrior's global VPN NAT rule when VPN is 
connected:

match out log on enc0 inet all nat-to 10.0.1.2

OR trough egress when VPN is disconnected:

match out log on egress from {lo0, 192.168.0.0/24} to any nat-to (egress:0)

# Outgoing www, https traffic
pass in on 192.168.0.1 inet proto tcp from 192.168.0.0/24 to any \
port {www, https} modulate state
pass out on enc0 inet proto tcp from 10.0.1.2 to any \
port {www, https} flags S/SA modulate state
pass out on (egress) inet proto tcp from (egress) to any \
port {www, https} flags S/SA modulate state

When Road Warrior's VPN is disconnected, any LAN client can connect any 
internet host as usual.

Please advice.

Martin

‐‐‐ Original Message ‐‐‐
On Monday, February 3, 2020 9:03 PM, Martin Got  
wrote:

> OpenIKED IKEv2 VPN setup consists of OpenBSD-6.6 based remote server and 6.6 
> based road warrior -
> client with dynamic IP. VPN works stable even using a link behind ISP NAT 
> with ping latency from
> ~750ms to ~1100ms. Hope latency about 1000ms can't be related to the issue 
> because all the tests
> with disconnected/connected VPN have been made on the same ISP channel.
>
> Any of the hosts from LAN (192.168.0.0/24) connected to the road warrior can 
> reach external Internet
> hosts with disconnected VPN only.
>
> If VPN is connected, no one host from road warrior's LAN can reach any 
> internet host.
> But any of LAN host can connect to road warrior's local services listening on 
> lo0 even with VPN is
> connected or not.
>
> So I can't ping any Internet host from road warrior's LAN host if VPN is 
> connected, but I can ping
> outside Internet hosts from road warriors' localhost itself. In PF ICMP set 
> from any to any and ping
> works to any Internet host if VPN is disabled. I think it can't be bound to 
> firewall rules, maybe
> timeouts of PF connection states. I'm completely not sure about it.
>
> When VPN is connected, all roadwarrior's LAN traffic is disabled for some 
> reason, tcpdump shows
> requests and replies to LAN's host on enc0 but initiator (192.168.0.5) don't 
> receive any replies. I
> don't know why?
>
> $ tcpdump -en -i pflog0
> 10:12:43.598785 rule 4/(match) match out on enc0: 10.0.1.2 > 8.8.8.8: icmp: 
> echo request
> 10:12.43.598814 rule 563/(match) pass out on enc0: 10.0.1.2 > 8.8.8.8: icmp: 
> echo request
> 10.12.44.277267 rule 4/(match) match out on enc0: 10.0.1.2 > 192.168.0.5: 
> icmp: echo reply
> 10.12.47.277848 rule 4/(match) match out on enc0: 10.0.1.2 > 192.168.0.5: 
> icmp: echo reply
>
> LAN clients' can reach road warrior's localhost bound services like DNS, 
> proxy and it doesn't matter
> if VPN enabled or not, but no any outbound traffic with enabled VPN.
>
> Road warrior client has one NAT in PF to transmit packets from it's local IP 
> address when VPN is
> disabled, and second NAT rule to transmit packets when IKEv2 VPN is connected 
> like:
>
> $ pf.conf (client)
>
> ---NAT
>
> ===
>
> match out log on enc0 inet all nat-to 10.0.1.2
> match out log on rdomain 0 from {lo0, 192.168.0.0/24} to any nat-to (egress:0)
>
> ---ICMP
>
> 
>
> pass in log quick on 192.168.0.1 inet proto icmp all icmp-type \
> echoreq, timex, paramprob, unreach code needfrag keep state
> pass out log inet proto icmp all
>
> ---Web
>
> ===
>
> pass in on 192.168.0.1 inet proto tcp from 192.168.0.0/24 to any \
> port {www, https} modulate state
> pass out on enc0 inet proto tcp from 10.0.1.2 to any \
> port {www, https} flags S/SA modulate state
> pass out on (egress) inet proto tcp from (egress) to any \
> port {www, https} flags S/SA modulate state
>
> ---IPsec
>
> =
>
> pass in log on (egress) inet proto esp from any to (egress) port {isakmp, 
> ipsec-nat-t}
> pass out log on (egress) inet proto udp from (egress) to any port {isakmp, 
> ipsec-nat-t} keep state
>
> pass in log on enc0 inet proto ipencap from any to (egress) keep state 
> (if-bound)
> pass out log on enc0 inet proto ipencap from (egress) to any keep state 
> (if-bound)
>
> pass in log on enc0 inet from 0.0.0.0/0 to 0.0.0.0/0 keep state (if-bound)
> pass out log on enc0 inet from 0.0.0.0/0 to 0.0.0.0/0 keep state (if-bound)
>
> ---
>
> 
>
> /etc/sysctl.conf has
>
> =
>
> net.inet.ip.forwarding=1
>
> I bypass all the possible SA flows from/to road warrior's LAN in 
> /etc/ipsec.conf, and all traffic
> from/to road warrior's localhost services so DNS works as expected (DNS 
> listens on road warrior's
> localhost and all queries 

Re: Dell Latitude e6400 OpenBSD Drive Issue

2020-02-10 Thread Adam Thompson

On 2020-02-10 09:36, Michael G Workman wrote:

Ok, thanks for the info.


For your E6400, see this guide: 
https://www.parts-people.com/blog/2012/10/16/dell-latitude-e6420-cmos-battery-removal-and-installation/


I found E6400 CMOS batteries from multiple vendors on the first page of 
Google results, most around US$10.  The only recommendation I can give 
is that I've used Parts-People.com in the past, no complaints with them.


Make sure you get the right replacement - check if your battery is 
2-wire or 3-wire *before* ordering a replacement - many of the listings 
don't worry about such minor details, g.


The older the Latitude, the harder it is to open, but even an E6400 is 
pretty easy, even if you've never opened up a laptop before.


Good luck,
-Adam



Re: IPsec and MTU / fragmentation

2020-02-10 Thread Janne Johansson
Den mån 10 feb. 2020 kl 16:27 skrev Simen Stavdal :

> This is more a discussion about scalability and practical implementation.
> We both know that PMTU will work partly at best, your entire path back
> must support this, and also, the "offending" client must allow inbound
> control messages on their host firewall for this to work.
> And even if the packets are received by the client, will it support and
> adjust MSS? I have seen a lot of clients not adhering to standards.
>
> Modifying thousands of clients (via dhcp options for instance) to use a
> fixed MTU will affect other applications too (if you choose to go that
> route), not just the ones that need to traverse a tight ipsec tunnel.
> Would you adjust all your clients just because you had a single path using
> SLIP in your network?
>

I would want for noone to ever have to know the complete path, slip or no
slip.


> Point is, there is no perfect solution to this issue, there are just
> different ways of solving bits and bobs on the way.
> Adjust mss will work just fine for all tcp protocols, and no, not for UDP
> because it does not use a three way handshake (no MSS to adjust).
> In my opinion, max-mss works very well in most cases, especially when you
> have full control of the tunnel you are using (as is the case of Lucas'
> original question).
> We use it extensively in many of our applications in my workplace, and as
> of yet has not represented any big issues, so it is a practically good way
> to solve this issue.
>

I think the more complete solution is to run some gif/gre inside ipsec and
set low-enough MTU on that one, so it can correctly fragment incoming
packets, and optionally rebuild the packets at the remote end, while also
giving you an idea of "state" on the link so you optionally can run things
like routing daemons or something that cares about and acts on tunnel
state. This would cause even lower MTU, but still allow all kinds of
traffic and not just the "popular" one.

I am somewhat trying to care for the ones that make a site-2-site ipsec
which may work for the initial setup, and later find out that more than one
non-tcp kind of traffic doesn't work without understanding why ssh,http
works but not list-of-things-like
mosh,wireguard,quic,yet-another-layer-of-ipsec,hosting-udp-game doesn't.

As for UDP, there are options here too in pf.conf (like no-df), but
> personally I have not tested this, but it would be fun to try. It says it
> supports IPv4 (which would include TCP, UDP and ICMP).
> Would be interesting to find if UDP enforces DF in most cases.
>

no-df in PF more or less controls if it will silently drop fragments that
arrive which has DF set. Linux used/uses to send such udp, for much
enjoyment. "noone else should fragment, but I just did and you as the
packet checker can't know who did"

-- 
May the most significant bit of your life be positive.


Re: Dell Latitude e6400 OpenBSD Drive Issue

2020-02-10 Thread Michael G Workman
Ok, thanks for the info.

*Michael G. Workman*
(321) 432-9295
michael.g.work...@gmail.com



On Sun, Feb 9, 2020 at 4:47 PM Adam Thompson  wrote:

> On 2020-02-09 06:58, Michael G Workman wrote:
> > Hello,
> >
> > Shout out to the OpenBSD developers for making a great OS!
> >
> > I was able to install OpenBSD 6.6 on a Dell Latitude e6400 laptop, with
> > a
> > USB Install. Sent the dmesg in already.
> >
> > The installer would not recognize the hard drive, a brand new SSD
> > drive.
> > The solution to that, from stack exchange, was to change the SATA
> > settings
> > in BIOS from IRRTL to AHCI, that fixed the problem.
> >
> > However if my laptop is powered off for a while, the SATA setting
> > changes
> > back to IRRTL instead of AHCI, very annoying, not sure why the BIOS
> > would
> > not make my changes persistent. I think it may be a hardware issue, but
> > just wanted to know if anyone else has encountered this before?
> >
> > Thanks.
> >
> > *Michael G. Workman*
> > (321) 432-9295
> > michael.g.work...@gmail.com
>
> I have run several laptops from that series with OpenBSD.  The other
> replies are correct, your BIOS battery is dead.  Unfortunately, on many
> of the Latitudes, the BIOS battery is of the variety that's embedded in
> the RTC chip, and is not separately replaceable.
> Some, however, including - the 6430 for example - have a regular coin
> cell, albeit wrapped in a proprietary cover with a non-standard
> connector, but at least is *is* replaceable without insane amounts of
> work.
> I have the owner's manuals for many of the 6400 series, email me
> directly if you can't find the guide to replacing parts for your
> particular model.
> -Adam
>


Re: IPsec and MTU / fragmentation

2020-02-10 Thread Simen Stavdal
This is more a discussion about scalability and practical implementation.
We both know that PMTU will work partly at best, your entire path back must
support this, and also, the "offending" client must allow inbound control
messages on their host firewall for this to work.
And even if the packets are received by the client, will it support and
adjust MSS? I have seen a lot of clients not adhering to standards.

Modifying thousands of clients (via dhcp options for instance) to use a
fixed MTU will affect other applications too (if you choose to go that
route), not just the ones that need to traverse a tight ipsec tunnel.
Would you adjust all your clients just because you had a single path using
SLIP in your network?

Point is, there is no perfect solution to this issue, there are just
different ways of solving bits and bobs on the way.
Adjust mss will work just fine for all tcp protocols, and no, not for UDP
because it does not use a three way handshake (no MSS to adjust).

In my opinion, max-mss works very well in most cases, especially when you
have full control of the tunnel you are using (as is the case of Lucas'
original question).
We use it extensively in many of our applications in my workplace, and as
of yet has not represented any big issues, so it is a practically good way
to solve this issue.

As for UDP, there are options here too in pf.conf (like no-df), but
personally I have not tested this, but it would be fun to try. It says it
supports IPv4 (which would include TCP, UDP and ICMP).
Would be interesting to find if UDP enforces DF in most cases.

Cheers,
Simon.

On Mon, 10 Feb 2020 at 13:50, Janne Johansson  wrote:

> Den mån 10 feb. 2020 kl 12:15 skrev Simen Stavdal :
>
>> True, but issue was related to downloading over http, which is over tcp.
>> So, if http is your only concern I would go for this option.
>>
>
> To me, it sounds just a bit like "let this person notice the other errors
> later".
>
>
>> Most clients are configured with an MTU of their physical NIC
>> capabilities, and sometimes even with jumbo support.
>> MTU is a property of the OS in both ends, while MSS is a property of the
>> packets that can be adjusted in-flight.
>>
>>
> MTU is strictly a property of each and every interface in all the hops
> between you and your endpoint and equally strictly is mss a property of
> _tcp_ packets that can be adjusted. If you run another ipsec inside this
> first ipsec tunnel-with-mss-fixed that second one would break, since ESP/AH
> is not tcp and will not do the 3way handshake where PF can fix mss for it.
> Or mosh, wireguard, or http/3 since they run over UDP.
>
> Not trying to nitpick everything, but internet wasn't built on 1500 MTU
> ethernet everywhere, in the old bad days you might go over PPP (576) or
> SLIP (296) links at times and it still worked, so if your setups today
> break if someone in your path limits you to 1476 or so, then we have
> regressed quite a bit since the crap internet days.
>
>
>> So, if you want to fix the MTU, you will have to configure that on the
>> conversation parters and not in pf.
>> So, while we agree on the principals, how do you suggest MTU is changed?
>>
>
> PMTU discovery would be one method, yes. Middle boxes that will not drop
> icmp is part if this of course.
>
>
>> Statically configured on each host? DHCP option?
>>
>
> This depends a bit on where you place your ipsec gw of course, but if you
> can't set it on the tunnel (since ipsec on obsd isn't like openvpn or
> gif/gre) you might need to set it on the interface where you take in the
> traffic, if you can't set it on all clients going via the gw, which is a
> believable scenario.
>
>
>> This might fix the http/ssh issues one might see, because both of those
>>> run over TCP, but MSS fixups will not correct large UDP or icmp packets, or
>>> any other non-TCP protocol one might run over that ipsec, so making sure
>>> the traffic is below the MTU should be the end goal, not fixing 90% with
>>> pf.
>>>
>>
>
> --
> May the most significant bit of your life be positive.
>


Re: rspamd stop rc script doesn't work in OpenBSD 6.6

2020-02-10 Thread Diana Eichert
SIGKILL seems pretty harsh, have you tried SIGTERM instead?

On Sun, Feb 9, 2020 at 12:48 PM aisha  wrote:
>
> You need to use pkill -9 to kill rspamd, which i think should be added
> to the stop part of the rspamd daemon.
>
> At least this is what I have been using, any other methods would be nice
> to know.
>
> ---
> Aisha
> blog.aisha.cc



Re: No traffic from/to road warrior's LAN hosts when IKEv2 VPN is connected

2020-02-10 Thread Martin Got
Hello @misc,

I'm still can't resolve the issue with outgoing connections from OpenBSD 
RoadWarrior's LAN clients, but connections from Road Warrior's localhost go tru 
VPN as it should be.

Any Ideas what can be wrong in my setup would be highly appreciated.

Martin

‐‐‐ Original Message ‐‐‐
On Monday, February 3, 2020 9:03 PM, Martin Got  
wrote:

> OpenIKED IKEv2 VPN setup consists of OpenBSD-6.6 based remote server and 6.6 
> based road warrior -
> client with dynamic IP. VPN works stable even using a link behind ISP NAT 
> with ping latency from
> ~750ms to ~1100ms. Hope latency about 1000ms can't be related to the issue 
> because all the tests
> with disconnected/connected VPN have been made on the same ISP channel.
>
> Any of the hosts from LAN (192.168.0.0/24) connected to the road warrior can 
> reach external Internet
> hosts with disconnected VPN only.
>
> If VPN is connected, no one host from road warrior's LAN can reach any 
> internet host.
> But any of LAN host can connect to road warrior's local services listening on 
> lo0 even with VPN is
> connected or not.
>
> So I can't ping any Internet host from road warrior's LAN host if VPN is 
> connected, but I can ping
> outside Internet hosts from road warriors' localhost itself. In PF ICMP set 
> from any to any and ping
> works to any Internet host if VPN is disabled. I think it can't be bound to 
> firewall rules, maybe
> timeouts of PF connection states. I'm completely not sure about it.
>
> When VPN is connected, all roadwarrior's LAN traffic is disabled for some 
> reason, tcpdump shows
> requests and replies to LAN's host on enc0 but initiator (192.168.0.5) don't 
> receive any replies. I
> don't know why?
>
> $ tcpdump -en -i pflog0
> 10:12:43.598785 rule 4/(match) match out on enc0: 10.0.1.2 > 8.8.8.8: icmp: 
> echo request
> 10:12.43.598814 rule 563/(match) pass out on enc0: 10.0.1.2 > 8.8.8.8: icmp: 
> echo request
> 10.12.44.277267 rule 4/(match) match out on enc0: 10.0.1.2 > 192.168.0.5: 
> icmp: echo reply
> 10.12.47.277848 rule 4/(match) match out on enc0: 10.0.1.2 > 192.168.0.5: 
> icmp: echo reply
>
> LAN clients' can reach road warrior's localhost bound services like DNS, 
> proxy and it doesn't matter
> if VPN enabled or not, but no any outbound traffic with enabled VPN.
>
> Road warrior client has one NAT in PF to transmit packets from it's local IP 
> address when VPN is
> disabled, and second NAT rule to transmit packets when IKEv2 VPN is connected 
> like:
>
> $ pf.conf (client)
>
> ---NAT
>
> ===
>
> match out log on enc0 inet all nat-to 10.0.1.2
> match out log on rdomain 0 from {lo0, 192.168.0.0/24} to any nat-to (egress:0)
>
> ---ICMP
>
> 
>
> pass in log quick on 192.168.0.1 inet proto icmp all icmp-type \
> echoreq, timex, paramprob, unreach code needfrag keep state
> pass out log inet proto icmp all
>
> ---Web
>
> ===
>
> pass in on 192.168.0.1 inet proto tcp from 192.168.0.0/24 to any \
> port {www, https} modulate state
> pass out on enc0 inet proto tcp from 10.0.1.2 to any \
> port {www, https} flags S/SA modulate state
> pass out on (egress) inet proto tcp from (egress) to any \
> port {www, https} flags S/SA modulate state
>
> ---IPsec
>
> =
>
> pass in log on (egress) inet proto esp from any to (egress) port {isakmp, 
> ipsec-nat-t}
> pass out log on (egress) inet proto udp from (egress) to any port {isakmp, 
> ipsec-nat-t} keep state
>
> pass in log on enc0 inet proto ipencap from any to (egress) keep state 
> (if-bound)
> pass out log on enc0 inet proto ipencap from (egress) to any keep state 
> (if-bound)
>
> pass in log on enc0 inet from 0.0.0.0/0 to 0.0.0.0/0 keep state (if-bound)
> pass out log on enc0 inet from 0.0.0.0/0 to 0.0.0.0/0 keep state (if-bound)
>
> ---
>
> 
>
> /etc/sysctl.conf has
>
> =
>
> net.inet.ip.forwarding=1
>
> I bypass all the possible SA flows from/to road warrior's LAN in 
> /etc/ipsec.conf, and all traffic
> from/to road warrior's localhost services so DNS works as expected (DNS 
> listens on road warrior's
> localhost and all queries were redirected by rdr-to rule in PF).
>
> $ /etc/ipsec.conf (client)
> flow from 127.0.0.1/32 to 127.0.0.1/32 type bypass
>
> flow from 127.0.0.1/32 to 192.168.0.0/24 type bypass
> flow from 192.168.0.0/24 to 127.0.0.1/32 type bypass
> flow from 192.168.0.0/24 to 192.168.0.0/24 type bypass
>
> $ /etc/iked.conf (client)
> ikev2 "road-warrior" active esp \
> from 0.0.0.0/0 to 0.0.0.0/0 \
> local 1.2.3.4 peer 4.3.2.1 \
> srcid roadw.vpn dstid srv.vpn \
> ikelifetime 80m lifetime 100m bytes 256m \
> tag "IKED" \
> tap "enc0"
>
> rcctl -f start iked (client)
>
> =
>
> iked(OK)
>
> ipsecctl -f /etc/ipsec.conf (client)
>
> =
>
> ipsecctl -sa (client)
>
> ==
>
> FLOWS:
> flow esp in from 0.0.0.0/0 to 0.0.0.0/0 peer 4.3.2.1 srcid FQDN/roadw.vpn 
> dstid FQDN/srv.vpn type
>
> use
> flow esp in from 192.168.0.0/24 to 

Re: IPsec and MTU / fragmentation

2020-02-10 Thread Stuart Henderson
On 2020-02-10, Paul de Weerd  wrote:
>and I've told
> them to either stop filering ICMPv6 Packet Too Large errors or
> restrict the MSS to a lower value on their end (as they said they were
> doing) to fix this for all their users.

AFAIK some security assessors (who don't understand TCP/IP) whine
about this..




Re: strange dmesg

2020-02-10 Thread Kevin Chadwick
On 2020-02-08 16:40, Otto Moerbeek wrote:
> When booting, the contents of the existing dmesg buffer are examined.
> If the current contents are deemed to be a dmesg, it is not cleared.
> It's possible the (random) contents of the buffer are seen as valid by
> chance and are thus regarded as dmesg content.

When I have seen it, it has been dmesg intermingled with other bytes. It is a
little worrying to see but I assume this is by design (no crc/checksum) in case
something useful is retrievable?

I guess Stus reference to UEFI doesn't suggest it can expose anything sensitive?



Re: strange dmesg

2020-02-10 Thread Stuart Henderson
On 2020/02/10 13:11, whistlez...@riseup.net wrote:
> On Mon, Feb 10, 2020 at 09:45:06AM -, Stuart Henderson wrote:
> > On 2020-02-10, Janne Johansson  wrote:
> > > Den lör 8 feb. 2020 kl 11:31 skrev :
> > >
> > >> Hi,
> > >> I have some strange output from dmesg, what could be ?
> > >> At the follwoing link I've posted some screenshots:
> > >> https://postimg.cc/gallery/1o4wsaw74/
> > >>
> > >
> > > dmesg is contained in a memory buffer with (hopefully) room for more than
> > > one dmesg, so you can get
> > > previous versions listed when you run it. If the memory gets slightly
> > > corrupted during reboots,
> > > I guess the "other" dmesgs can come out as garbage, based on how memory
> > > gets reused or
> > > reallocated in the time between reboot and next boot when the OS isn't in
> > > control of the
> > > RAM.
> > 
> > From the contents, this one looks like it was probably overwritten with
> > some UEFI code during boot.
> > 
> 
> Could be a UEFI rootkit ? Or something that from UEFI try to inject code
> in the kernel ?
> 
> 

I think it is probably normal operation of your machine. It just happened
to pick an area of memory where the old dmesg is located to use during
boot.

If bytes 0x063061 (MSG_MAGIC defined in sys/msgbuf.h) are present at the
right location then it is treated as a message buffer from a previous
boot. If the UEFI firmware (or BIOS or device boot code or whatever)
as part of its normal operations writes to memory somewhere after that
marker, but leaves the marker itself alone, it will still be treated as
valid.



Re: IPsec and MTU / fragmentation

2020-02-10 Thread Janne Johansson
Den mån 10 feb. 2020 kl 12:15 skrev Simen Stavdal :

> True, but issue was related to downloading over http, which is over tcp.
> So, if http is your only concern I would go for this option.
>

To me, it sounds just a bit like "let this person notice the other errors
later".


> Most clients are configured with an MTU of their physical NIC
> capabilities, and sometimes even with jumbo support.
> MTU is a property of the OS in both ends, while MSS is a property of the
> packets that can be adjusted in-flight.
>
>
MTU is strictly a property of each and every interface in all the hops
between you and your endpoint and equally strictly is mss a property of
_tcp_ packets that can be adjusted. If you run another ipsec inside this
first ipsec tunnel-with-mss-fixed that second one would break, since ESP/AH
is not tcp and will not do the 3way handshake where PF can fix mss for it.
Or mosh, wireguard, or http/3 since they run over UDP.

Not trying to nitpick everything, but internet wasn't built on 1500 MTU
ethernet everywhere, in the old bad days you might go over PPP (576) or
SLIP (296) links at times and it still worked, so if your setups today
break if someone in your path limits you to 1476 or so, then we have
regressed quite a bit since the crap internet days.


> So, if you want to fix the MTU, you will have to configure that on the
> conversation parters and not in pf.
> So, while we agree on the principals, how do you suggest MTU is changed?
>

PMTU discovery would be one method, yes. Middle boxes that will not drop
icmp is part if this of course.


> Statically configured on each host? DHCP option?
>

This depends a bit on where you place your ipsec gw of course, but if you
can't set it on the tunnel (since ipsec on obsd isn't like openvpn or
gif/gre) you might need to set it on the interface where you take in the
traffic, if you can't set it on all clients going via the gw, which is a
believable scenario.


> This might fix the http/ssh issues one might see, because both of those
>> run over TCP, but MSS fixups will not correct large UDP or icmp packets, or
>> any other non-TCP protocol one might run over that ipsec, so making sure
>> the traffic is below the MTU should be the end goal, not fixing 90% with
>> pf.
>>
>

-- 
May the most significant bit of your life be positive.


Re: strange dmesg

2020-02-10 Thread whistlez-ml
On Mon, Feb 10, 2020 at 09:45:06AM -, Stuart Henderson wrote:
> On 2020-02-10, Janne Johansson  wrote:
> > Den lör 8 feb. 2020 kl 11:31 skrev :
> >
> >> Hi,
> >> I have some strange output from dmesg, what could be ?
> >> At the follwoing link I've posted some screenshots:
> >> https://postimg.cc/gallery/1o4wsaw74/
> >>
> >
> > dmesg is contained in a memory buffer with (hopefully) room for more than
> > one dmesg, so you can get
> > previous versions listed when you run it. If the memory gets slightly
> > corrupted during reboots,
> > I guess the "other" dmesgs can come out as garbage, based on how memory
> > gets reused or
> > reallocated in the time between reboot and next boot when the OS isn't in
> > control of the
> > RAM.
> 
> From the contents, this one looks like it was probably overwritten with
> some UEFI code during boot.
> 

Could be a UEFI rootkit ? Or something that from UEFI try to inject code
in the kernel ?




Re: IPsec and MTU / fragmentation

2020-02-10 Thread Paul de Weerd
On Mon, Feb 10, 2020 at 12:15:37PM +0100, Simen Stavdal wrote:
| True, but issue was related to downloading over http, which is over tcp.
| So, if http is your only concern I would go for this option.
| 
| Most clients are configured with an MTU of their physical NIC capabilities,
| and sometimes even with jumbo support.
| MTU is a property of the OS in both ends, while MSS is a property of the
| packets that can be adjusted in-flight.
| 
| So, if you want to fix the MTU, you will have to configure that on the
| conversation parters and not in pf.
| So, while we agree on the principals, how do you suggest MTU is changed?

One interesting option that I recently discovered thanks to florian@
is the 'mtu'[1] setting in /etc/rad.conf on your IPv6 router.  By
lowering the MTU, packets had a smaller MSS, which aligned with the
MTU of the IPv6 tunnel I was using in that situation.  This, in turn,
allowed me to use software my bank has provided for my mobile device
over IPv6 without a problem.

Admittedly, after learning that this worked, I switched back to
scrubbing the MSS in pf.conf for this particular bank, and I've told
them to either stop filering ICMPv6 Packet Too Large errors or
restrict the MSS to a lower value on their end (as they said they were
doing) to fix this for all their users.  The effect of using 'mtu' in
rad(8) is a lower configured MTU on your SLAAC enabled clients,
affecting also IPv4 (and local IPv6) traffic.

Cheers,

Paul 'WEiRD' de Weerd

[1]: http://man.openbsd.org/rad.conf#mtu

| Statically configured on each host? DHCP option?
| 
| Cheers,
| Simon.
| 
| On Mon, 10 Feb 2020 at 12:06, Janne Johansson  wrote:
| 
| > Den mån 10 feb. 2020 kl 11:58 skrev Simen Stavdal :
| >
| >> Hi Lucas,
| >> Have you tried to manipulate the mss during conversation setup?
| >> This is done with the max-mss directive in pf.conf.
| >> Basically, it takes the three way handshake, and overrides the MSS value
| >> in
| >> the handshake to something lower than the default.
| >>
| >
| > This might fix the http/ssh issues one might see, because both of those
| > run over TCP, but MSS fixups will not correct large UDP or icmp packets, or
| > any other non-TCP protocol one might run over that ipsec, so making sure
| > the traffic is below the MTU should be the end goal, not fixing 90% with
| > pf.
| >
| > --
| > May the most significant bit of your life be positive.
| >

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 



Re: IPsec and MTU / fragmentation

2020-02-10 Thread Simen Stavdal
True, but issue was related to downloading over http, which is over tcp.
So, if http is your only concern I would go for this option.

Most clients are configured with an MTU of their physical NIC capabilities,
and sometimes even with jumbo support.
MTU is a property of the OS in both ends, while MSS is a property of the
packets that can be adjusted in-flight.

So, if you want to fix the MTU, you will have to configure that on the
conversation parters and not in pf.
So, while we agree on the principals, how do you suggest MTU is changed?

Statically configured on each host? DHCP option?

Cheers,
Simon.

On Mon, 10 Feb 2020 at 12:06, Janne Johansson  wrote:

> Den mån 10 feb. 2020 kl 11:58 skrev Simen Stavdal :
>
>> Hi Lucas,
>> Have you tried to manipulate the mss during conversation setup?
>> This is done with the max-mss directive in pf.conf.
>> Basically, it takes the three way handshake, and overrides the MSS value
>> in
>> the handshake to something lower than the default.
>>
>
> This might fix the http/ssh issues one might see, because both of those
> run over TCP, but MSS fixups will not correct large UDP or icmp packets, or
> any other non-TCP protocol one might run over that ipsec, so making sure
> the traffic is below the MTU should be the end goal, not fixing 90% with
> pf.
>
> --
> May the most significant bit of your life be positive.
>


Re: IPsec and MTU / fragmentation

2020-02-10 Thread Janne Johansson
Den mån 10 feb. 2020 kl 11:58 skrev Simen Stavdal :

> Hi Lucas,
> Have you tried to manipulate the mss during conversation setup?
> This is done with the max-mss directive in pf.conf.
> Basically, it takes the three way handshake, and overrides the MSS value in
> the handshake to something lower than the default.
>

This might fix the http/ssh issues one might see, because both of those run
over TCP, but MSS fixups will not correct large UDP or icmp packets, or any
other non-TCP protocol one might run over that ipsec, so making sure the
traffic is below the MTU should be the end goal, not fixing 90% with pf.

-- 
May the most significant bit of your life be positive.


Re: IPsec and MTU / fragmentation

2020-02-10 Thread Simen Stavdal
Hi Lucas,

Have you tried to manipulate the mss during conversation setup?
This is done with the max-mss directive in pf.conf.

Basically, it takes the three way handshake, and overrides the MSS value in
the handshake to something lower than the default.

Client (1500 bytes) -> pf (change to 1300 bytes) -> Server
Server (1500 bytes) -> pf (change to 1300 bytes) -> Client

Now, both the server and the client thinks that the remote conversation
partner is only able to receive 1300 bytes, and will package the data
accordingly.

When a normal conversation is set up, it is becoming more and more common
to set DF=1 (don't fragment = true).
When the router/firewall receives packets that are too big, they become
discarded, but the max-mss should take care of this. I.e, while not
allowing fragmentation, but force smaller packets in the first place.

The three way handshake will usually always come true, because the packets
are very small.

Cheers,
Simon.

On Sun, 9 Feb 2020 at 21:35, Lucas  wrote:

> Hi misc@,
>
> I've set up an IPsec tunnel to for serving my website from my home. The
> tunnel works quite well most of the time, but if I try to deliver big
> files over it, the HTTP client never gets a response. After some
> testing, if I ran in the HTTP server end
>
> perl -e 'print "a" x 1386;' | doas nc -l 10.200.0.80 80
>
> client receives 1386 "a"s, but with any bigger size the client sees no
> response at all.
>
> This smells of MTU / fragmentation issues, but I don't know enough about
> networks to configure it properly. Is this the case? Any recommendations
> on how to configure a sensible value? Any clue sticks? I can bang
> different MTUs until it works, but that solution doesn't seem to scale.
> You can find my iked and pf configs below.
>
> Also would like to understand why it happens, so pointers to docs are
> more than welcome.
>
> Thanks in advance,
> -Lucas
>
> Initiator /etc/iked.conf:
>
> initiator_www = 10.200.0.80
> initiator_peer =192.0.2.1
> responder = 198.51.100.1
>
> ikev2 "www" active proto tcp \
> from $initiator_www port 80 to $responder \
> peer $responder \
> srcid initiator dstid responder \
> tag IPSECWWW
>
> Initiator /etc/pf.conf:
>
> set block-policy drop
> set loginterface egress
> set skip on lo0
>
> block all
>
> pass out quick on { egress enc0 }
>
> pass in quick on enc0 tagged IPSECWWW
> pass in on egress proto tcp to port ssh
> pass in on egress inet proto icmp all
> pass in on egress inet6 proto ipv6-icmp all
>
> Responder /etc/iked.conf:
>
> initiator_www = 10.200.0.80
> initiator_peer =192.0.2.1
> responder = 198.51.100.1
>
> ikev2 "www" passive proto tcp \
> from $responder to $initiator_www port 80 \
> peer $initiator_peer \
> srcid responder dstid initiator \
> tag IPSECWWW
>
> Responder /etc/pf.conf:
>
> set block-policy drop
> set loginterface egress
> set skip on lo0
>
> block log all
>
> pass out quick on egress
>
> pass in log on egress proto udp from any to (egress) \
> port { isakmp ipsec-nat-t }
> pass in log on egress proto esp from any to (egress)
> pass in log on enc0 tagged IPSECWWW
> pass out log on enc0
>
> pass in on egress proto tcp to port { ssh http https }
> pass in on egress inet proto icmp all
> pass in on egress inet6 proto icmp6 all
>
>


Re: IPsec and MTU / fragmentation

2020-02-10 Thread Lucas
Hi Denis,

Denis  wrote:
> It can be re-keying issue. You can check this out by adding to iked.conf
> on both ends:

I took this line off from the mail while cleaning up the config. I have

ikelifetime 3h lifetime 1h

in both ends.

> By the way, can your let us know "big files" exact size?

> > perl -e 'print "a" x 1386;' | doas nc -l 10.200.0.80 80
> > 
> > client receives 1386 "a"s, but with any bigger size the client sees no
> > response at all.

Anything bigger than 1386 bytes.

-Lucas



Re: strange dmesg

2020-02-10 Thread Stuart Henderson
On 2020-02-10, Janne Johansson  wrote:
> Den lör 8 feb. 2020 kl 11:31 skrev :
>
>> Hi,
>> I have some strange output from dmesg, what could be ?
>> At the follwoing link I've posted some screenshots:
>> https://postimg.cc/gallery/1o4wsaw74/
>>
>
> dmesg is contained in a memory buffer with (hopefully) room for more than
> one dmesg, so you can get
> previous versions listed when you run it. If the memory gets slightly
> corrupted during reboots,
> I guess the "other" dmesgs can come out as garbage, based on how memory
> gets reused or
> reallocated in the time between reboot and next boot when the OS isn't in
> control of the
> RAM.

>From the contents, this one looks like it was probably overwritten with
some UEFI code during boot.



Re: strange dmesg

2020-02-10 Thread Janne Johansson
Den lör 8 feb. 2020 kl 11:31 skrev :

> Hi,
> I have some strange output from dmesg, what could be ?
> At the follwoing link I've posted some screenshots:
> https://postimg.cc/gallery/1o4wsaw74/
>

dmesg is contained in a memory buffer with (hopefully) room for more than
one dmesg, so you can get
previous versions listed when you run it. If the memory gets slightly
corrupted during reboots,
I guess the "other" dmesgs can come out as garbage, based on how memory
gets reused or
reallocated in the time between reboot and next boot when the OS isn't in
control of the
RAM.

-- 
May the most significant bit of your life be positive.


Re: IPsec and MTU / fragmentation

2020-02-10 Thread Denis
It can be re-keying issue. You can check this out by adding to iked.conf
on both ends:

Intitiator:
...
ikelifetime 120m lifetime 180m bytes 200m \
tag IPSECWWW

Receiver:
...
ikelifetime 100m lifetime 160m bytes 250m \
tag IPSECWWW

The test result can be used for further investigations.

By the way, can your let us know "big files" exact size?

Denis

On 2/9/2020 9:33 PM, Lucas wrote:
> Hi misc@,
> 
> I've set up an IPsec tunnel to for serving my website from my home. The
> tunnel works quite well most of the time, but if I try to deliver big
> files over it, the HTTP client never gets a response. After some
> testing, if I ran in the HTTP server end
> 
>   perl -e 'print "a" x 1386;' | doas nc -l 10.200.0.80 80
> 
> client receives 1386 "a"s, but with any bigger size the client sees no
> response at all.
> 
> This smells of MTU / fragmentation issues, but I don't know enough about
> networks to configure it properly. Is this the case? Any recommendations
> on how to configure a sensible value? Any clue sticks? I can bang
> different MTUs until it works, but that solution doesn't seem to scale.
> You can find my iked and pf configs below.
> 
> Also would like to understand why it happens, so pointers to docs are
> more than welcome.
> 
> Thanks in advance,
> -Lucas
> 
> Initiator /etc/iked.conf:
> 
>   initiator_www = 10.200.0.80
>   initiator_peer =192.0.2.1
>   responder = 198.51.100.1
> 
>   ikev2 "www" active proto tcp \
>   from $initiator_www port 80 to $responder \
>   peer $responder \
>   srcid initiator dstid responder \
>   tag IPSECWWW
> 
> Initiator /etc/pf.conf:
> 
>   set block-policy drop
>   set loginterface egress
>   set skip on lo0
> 
>   block all
> 
>   pass out quick on { egress enc0 }
> 
>   pass in quick on enc0 tagged IPSECWWW
>   pass in on egress proto tcp to port ssh
>   pass in on egress inet proto icmp all
>   pass in on egress inet6 proto ipv6-icmp all
> 
> Responder /etc/iked.conf:
> 
>   initiator_www = 10.200.0.80
>   initiator_peer =192.0.2.1
>   responder = 198.51.100.1
> 
>   ikev2 "www" passive proto tcp \
>   from $responder to $initiator_www port 80 \
>   peer $initiator_peer \
>   srcid responder dstid initiator \
>   tag IPSECWWW
> 
> Responder /etc/pf.conf:
> 
>   set block-policy drop
>   set loginterface egress
>   set skip on lo0
> 
>   block log all
> 
>   pass out quick on egress
> 
>   pass in log on egress proto udp from any to (egress) \
>   port { isakmp ipsec-nat-t }
>   pass in log on egress proto esp from any to (egress)
>   pass in log on enc0 tagged IPSECWWW
>   pass out log on enc0
> 
>   pass in on egress proto tcp to port { ssh http https }
>   pass in on egress inet proto icmp all
>   pass in on egress inet6 proto icmp6 all
>