Re: PC Engines APU alternative for OpenBSD - 2022h2

[Erik van Westen]

On 28-09-2022 16:27, Mikolaj Kucharski wrote:

Hi,

I'm using PC Engines for years. I have many of them. I want to buy more,
but they are not available on their main web site. I'm still planning to
buy them the moment they will show up on https://www.pcengines.ch/order.htm

However, after many weeks of waiting, I finally reached a point, when I
need to look for alternatives, as few of my hobbyist projects and plans
are on-hold for too long.

I'm looking for something similar like PC Engines APU board. Preferably
4 network cards, 4GB of RAM, low power consumption, no graphic card,
serial console access, suitable for wired and Wi-Fi and/or LTE router,
based on OpenBSD.

To give you an example, I have or had in the past, PC Engines with
OpenBSD as:

- plain simple Ethernet router
- fiber + Ethernet router
- Wi-Fi access point via Ethernet uplink
- Wi-Fi access point via LTE modem uplink
- WireGuard, OpenVPN endpoint
- DNS, DHCP, TFTP and PXE server
- print server and scanner via CUPS and SANE
- HTTP server, plus some automation daemons

Very typical stuff, nothing unusual I would say. I usually duplicate
above setups in various locations, like family house, relatives, and my
own place, but.. I run out of simple and reliable hardware to run it on,
hence this post. I don't want to run full blown PC, because of
electricity consumption and graphic card. In case of kernel panic() I
want to have a system with serial console, by design on motherboard,
not something additional.

 From architecture perspective I think most practical is amd64, but maybe
well supported arm64 would do. If you want to put RPi in the picture, I
don't think about it, as it has only one Ethernet interface.

PS: Please CC me in any replies.


Have a look at shop.opnsense.com, they might have something.

Erik

Re: [Ver3.6/3.9] Old version need help

[Erik van Westen]

Try ftp.nluug.nl, they seem to have everything starting with 2.0.

Regards,
Erik

On 30-03-2021 08:28, cclai wrote:

Hello,

I'm Hachi,
Our company’s server uses the 3.6 and 3.9 version of the system,
Used for more than ten years,
and there is a need to reinstall at present.

I have tried the file installation on FTP and failed.

Russia (Moscow) ftp://mirror.yandex.ru/pub/OpenBSD/
cd39.iso

So I hope that your organization can provide
an installation package "3.6 and 3.9 version" to solve the problem.

It would be of great help to us.
Thank you very much.

Hachi

Re: VLAN configuration problem on 6.1 ("no route to host" on other than own IP)

[Erik van Westen]

Aren't you missing the vlan definition in hostname.vlan211 like:

# cat /etc/hostname.vlan211
inet 172.16.211.3 255.255.255.0 172.16.211.255*vlan 211* vlandev em0

or, like in 6.2:

inet 172.16.211.3 255.255.255.0 172.16.211.255 vnetid 211 parent em0

?

Erik


Op 6-11-2017 om 17:47 schreef Andre Ruppert:
> Hello @misc,
>
> perhaps I'm stupid, but I don't see my fault in a vlan network
> configuration:
>
> I got a OpenBSD 6.1 gateway box, connected to several switches.
>
> On em0 I habe to serve two networks:
> 172.16.210.0  (direct em0 - no vlan)
> 172.16.211.0  (VLAN 211 tagged on em0)
>
> 
>
> On of my connections (em0) has a simple configuration on standard VLAN
> 1 (untagged):
>
> # ifconfig em0
> em0:
> flags=8b43
> mtu 1500
>     lladdr a0:36:9f:36:49:e6
>     description: sbc-ect-lan-ext
>     index 1 priority 0 llprio 3
>     media: Ethernet autoselect (1000baseT full-duplex,master)
>     status: active
>     inet 172.16.210.3 netmask 0xff00 broadcast 172.16.210.255
>
> # cat /etc/hostname.em0
> inet 172.16.210.3 255.255.255.0 172.16.210.255 description
> "sbc-ect-lan-ext"
>
> --
>
> This interface also is "CARPed":
>
> # ifconfig carp0
> carp0: flags=8843 mtu 1500
>     lladdr 00:00:5e:00:01:01
>     index 8 priority 15 llprio 3
>     carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100
>     groups: carp
>     status: backup
>     inet 172.16.210.1 netmask 0xff00 broadcast 172.16.210.255
>
> # cat /etc/hostname.carp0
> inet 172.16.210.1 255.255.255.0 172.16.210.255 vhid 1 carpdev em0 pass
>  advskew 100
>
> (this gateway is the CARP slave (backup) of a pair of redundant gateways)
>
> ---
>
> Next: I want to have a VLAN on this interface em0:
> (the connected switch has a trunk configured this VLAN 210 (untagged)
> and VLAN 211 (tagged) - but I don't know if this information makes
> sense here)
>
> # ifconfig vlan211
> vlan211: flags=8843 mtu 1500
>     lladdr a0:36:9f:36:49:e6
>     index 15 priority 0 llprio 3
>     vlan: 211 parent interface: em0
>     vnetid: 211
>     parent: em0
>     groups: vlan
>     status: active
>     inet 172.16.211.3 netmask 0xff00 broadcast 172.16.211.255
>
> # cat /etc/hostname.vlan211
> inet 172.16.211.3 255.255.255.0 172.16.211.255 vlandev em0
>
> --
>
> corresponding routing table (excerpt):
>
>  # netstat -nr
> Routing tables
>
> Internet:
> Destination    Gateway    Flags   Refs  Use   Mtu 
> Prio Iface
> default    172.16.0.15    UGS    1  191 - 8
>
> ...
> ...
>
> 172.16.210/24  172.16.210.3   UCn    1 1094 -
> 4 em0
> 172.16.210/24  172.16.210.1   Cn 0    0 -   
> 19 carp0
> 172.16.210.1   00:00:5e:00:01:01  UHLl   0  153 -
> 1 carp0
> 172.16.210.3   a0:36:9f:36:49:e6  UHLl   0  275 -
> 1 em0
> 172.16.210.10  00:08:25:22:50:e0  UHLc   0  158 -
> 3 em0
> 172.16.210.255 172.16.210.3   UHPb   0    0 -
> 1 em0
> 172.16.210.255 172.16.210.1   HPb    0    0 -
> 1 carp0
> 172.16.211/24  172.16.211.3   UCn    0 1215 -
> 4 vlan211
> 172.16.211.3   a0:36:9f:36:49:e6  UHLl   0    0 -
> 1 vlan211
> 172.16.211.255 172.16.211.3   UHb    0    0 -
> 1 vlan211
>
> -
>
> My problem:
>
> I am only able to ping myself (VLAN 211)  - end I _don't_ think it's a
> switch problem - because I get an "no route to host" error
> # ping 172.16.211.3 # (my IP)
> PING 172.16.211.3 (172.16.211.3): 56 data bytes
> 64 bytes from 172.16.211.3: icmp_seq=0 ttl=255 time=0.153 ms
> 64 bytes from 172.16.211.3: icmp_seq=1 ttl=255 time=0.080 ms
> ...
> ...stupid but working as expected...
>
>
> # ping 172.16.211.2 # some other IP, same network
> PING 172.16.211.2 (172.16.211.2): 56 data bytes
> ping: sendmsg: No route to host
> ping: wrote 172.16.211.2 64 chars, ret=-1
> ping: sendmsg: No route to host
> ping: wrote 172.16.211.2 64 chars, ret=-1
> ping: sendmsg: No route to host
> ...
>
>
> The routing table then has added one new entry:
>
> 172.16.211/24  172.16.211.3   UCn    1 1743 -
> 4 vlan211
> 172.16.211.2   link#15    UHLc   0 1684 -
> 3 vlan211  !
> 172.16.211.3   a0:36:9f:36:49:e6  UHLl   0   18 -
> 1 vlan211
> 172.16.211.255 172.16.211.3   UHb    0    0 -
> 1 vlan211
>
>
> I'm clueless and don't know how to investigate further...
>
> In my pf.conf I tried to "temporarly annihilate" the rules on the em0
> interface ("set skip on em0"), 

Re: pf and max bandwidth in nested queues (bug?)

[Erik van Westen]

Op 1-11-2017 om 14:22 schreef Oliver Humpage:
> Hello,
>
> I have an OpenBSD 6.2 router, set up in a test rig so there's no traffic 
> apart from my tests. It has vmx interfaces. $int_if is a vlan on one of them.
>
> I have an issue where if a child queue has a different “max” from a parent 
> queue, the bandwidth is throttled down to much less than either.
>
> I have the following simple queue tree (eventually it will be bigger, this is 
> just for testing):
>
> queue inbound on $int_if bandwidth 100M
>   queue inbound_all parent inbound bandwidth 30M max 30M
> queue inbound_std parent inbound_all bandwidth 20M max 30M default
> pass on $int_if
>
> This works, and an iperf test shunting data through the router from ext->int 
> gets around 30Mb as expected.
>
> If I change the inbound_all queue's max to a slightly higher number, this 
> shouldn’t have any effect at all - after all, the inbound_std queue is still 
> "bandwidth 20M max 30M", and neither of these numbers exceed the parent:
>
> queue inbound on $int_if bandwidth 100M
>   queue inbound_all parent inbound bandwidth 30M max 40M
>  ^^^
> queue inbound_std parent inbound_all bandwidth 20M max 30M default
> pass on $int_if
>
> However, when I do this, suddenly connections assigned to inbound_std only 
> get around 2.3Mb. 
>
> ``systat q’’ shows all packets are going into the correct queue.
>
> As an experiment, I put a “min” level on inbound_std:
>
> queue inbound_std parent inbound_all bandwidth 20M min 10M max 30M default
>
> Then connections get that minimum bandwidth (here, iperf reported around 
> 10Mb), so it shows the queue *can* use more than 2.3Mb, but it still sticks 
> to the min rather than using all available bandwidth.
>
> This seems like a bug to me, although I’m hesitant to suggest it since I have 
> a lot of respect for the OpenBSD team. Does anyone have a suggestion as to 
> what’s happening?
>
> Thanks,
>
> Oliver.
>

I might be mistaken, but doesn't queueing only work on OUTgoing traffic
since one cannot control the rate at which traffic is delivered to you,
but one can control the rate of traffic going out of an interface?

Erik

Re: Traffic filtering

[Erik van Westen]

Op 30-10-2017 om 22:37 schreef x9p:
>
>> I use the blocklists from emergingthreats.net. Is already in a format
>> that  Works wonderfully.
>>
>> http://rules.emergingthreats.net/fwrules/emerging-PF-ALL.rules
>
> Good to use HTTPS to avoid someone tampering with the list via DNS/etc..

So use https://rules.emergingthreats.net/fwrules/emerging-PF-ALL.rules
instead... I won't stop you. :) What are the chances that someone will
be able to realisticly tamper with the traffic? Very close to zero given
the setup. The chances that the other side is tampered with are much,
much higher. You might as well not rely on external sources.
Of course you are running your own DNS resolver and not relying on your
provider, are you?

>
>> Just fetch them through a cron job, include them in pf.conf and reload
>> pf.conf. And yes, you would have to trust...
>
> Is a nice idea to whitelist the IP address/range where you connect
> from, if loading external rules made by somebody else, so you do not
> get locked out of your own box (happened once on a friday, not funny).

Won't happen, thanks for the warning though. I connect from the inside
(always access) to the outside, and when connecting from the outside it
will be over IPv6. The list is IPv4.

Erik

Re: Traffic filtering

[Erik van Westen]

Op 30-10-2017 om 21:50 schreef greg...@airmail.cc:
> Hi,
> I'm new to this area, but I would like to filter some traffic.
> The goal is to keep people secure while web browsing, not to censure.
> And also enable better privacy, mainly stop "malware" and
> tracking/ads as restrictively as possible.
>
> I have 3 questions, in case someone here has the time to answer me:
>
[snip]
> 2. If the right approach is blacklisting domains, then what list
> do OpenBSD users recommend to use? People seem to be using these
> two, but I would like to know the opinion from OpenBSD users:
> http://www.malware-domains.com/files/
> https://hosts-file.net/?s=Download
> 3. There's any well designed tool that I can automatically update
> these lists (using pledge and signify, for example), or a simple shell
> script is enough?

I use the blocklists from emergingthreats.net. Is already in a format
that  Works wonderfully.

http://rules.emergingthreats.net/fwrules/emerging-PF-ALL.rules

Just fetch them through a cron job, include them in pf.conf and reload
pf.conf. And yes, you would have to trust...

Good luck.

Erik

Re: DMCA Free OpenBSD VPS Hosting, multiple payment methods

[Erik van Westen]

Op 20-10-2017 om 12:29 schreef Niels Kobschaetzki:
>
> On 17/10/20 08:09, x9p wrote:
>>> Depending on the country the ISP will see then the police coming to
>>> their
>>> datacenter and start to pull servers. And then they can close shop
>>> because
>>> a single customer was an asshole and did illegal stuff on their
>>> ip-range
>>> and hardware. That is self-protection.
>>>
>>
>> agree on that. a single customer can ruin everything. I disagree that
>> you
>> need to pull servers offline. Just give them the VPS image and put it
>> offline. Image encrypted, btw.
>
> No, **you** do not pull the servers offline. The police will do that for
> you. A lawyer might help to negotiate that it is enough to hand them the
> encrypted VPS-image, but that won't necessarily work.
>
> Niels

A lawyer only comes in after the fact. Remember the "ex parte" part?
Damage is done.

Re: DMCA Free OpenBSD VPS Hosting, multiple payment methods

[Erik van Westen]

Op 19-10-2017 om 20:27 schreef x9p:
>> But they WILL terminate your contract. Do not host in The Netherlands,
>> but in Switzerland or Iceland. Illegal torrents are forbidden in The
>> Netherlands, and actively chased nowadays.
>>
>>
> This is the tricky part for Netherlands. They will only terminate your
> contract upon receiving a WRITTEN court order to do so. 
You underestimate 'Stichting Brein'. They WILL get an ex parte (no
less!) court order. So you will not know you are being investigated
until a court order is served and you server is shut off. Only then you
will be told.


> Lawyers are not
> cheap.

Yes they are for 'Stichting Brein'. Their only purpose is to uphold the
rights of the copyright holders,
and they have lawyers are working for them. The copyright holders pay
and pay well for it.

>  A lawsuit will not be brought against each and everyone using Pop
> Corn Time to watch Hitman's Bodyguard, but it is really easy and cheap to
> write an script, collect IPs via torrent, and send DMCA takedown notices.
> DMCA free ignores this automatic scripts, but of course need to act upon
> receiving a court order.
'Stichting Brein' does have similar scripts. No worries.

>
> If you are Pirate Bay, ok, you should worry. If you are a John Nobody like
> me, that will not happen anytime soon.
>
> cheers.
>
> x9p

Try it and you will see. They will take action based on DMCA requests by
the way, they already do,
on behalf of the US copyright holders.
Not to frighten you, but that is how it works. Been there, seen that.
And yes, it has been announced they will start crackown on the smaller
targets (already started).

Follow the current standard operating procedures. It has been judged
that Stichting Brein WILL get
names based on ip addresses by court order, no further actions needed,
no further courts involved.

You seem to be blissfully unaware of the 'progress' in the Dutch legal
system thus far. Full blocking (ip-, name
and DNS based) for ISPs for TPB. If 'Stichting Brein' determines a new
ip address or name, they
demand a blockade, no court order needed.

I would not take the chance, and I live in The Netherlands. I don't need
to. But if I would build a setup,
it would be with a VPS in Switzerland. Never, ever in The Netherlands.

But back on topic. This has nothing to do with OpenBSD.

Re: DMCA Free OpenBSD VPS Hosting, multiple payment methods

[Erik van Westen]

Op 19-10-2017 om 17:28 schreef Michael Hekeler:
>> Not at all. Some hosting companies specific mention it.
> Interesting.
> I didn´t knew..
>
>
>> The company I mention above is also part of EU, I believe.
> Germany (Hetzner) is
> Iceland (1984) is not 
>
>  
>> quoting myself, the answer is in the beginning of this email:
>> " >> expect the worst in torrent-related matters."
> Ah, okay - I have not seen this.
>
> Torrents are not basically illegal. So no problem with the hosters.
>
> But of course you should not host something like pirate bay in EU. And
> also better to stay away from the non-EU-members in europe (like swiss,
> monaco, moldova...) 

Given the mention of DMCA, chances are very high that illegal torrents
are being referred to. That means that one is only really safe in
Switzerland (where privacy laws really protects the (torrent) users) or
Iceland. The EU countries, and more specifically Germany, The
Netherlands and France follow a strict policy. I have no reason to
assume that matters are different in the other EU countries, although
there are a lot of bullet proof hosters in Romania and Bulgaria, but one
really does not want to be associated with that. Bullet proof hosting is
associated with criminal activities.

Especially Switzerland is probably the best choice (good
interconnections, low latency). Prices for VPS's are high though, and I
do not know the situation with OpenBSD hosting.

Re: DMCA Free OpenBSD VPS Hosting, multiple payment methods

[Erik van Westen]

Op 19-10-2017 om 14:51 schreef x9p:
> I believe it already got a bit off-topic, sorry if its the case, but will
> try to answer.
>
>>> Could not find DMCA-related info on the pages of company. Being Germany,
>>> I
>>> expect the worst in torrent-related matters.
>> Wouldn´t it be strange to find information related to a United States
>> Law on a german company´s homepage ;-)
>>
>>
> Not at all. Some hosting companies specific mention it. In this case a
> Dutch company, which do not act(terminate) your hosting upon receiving
> automatic email threats from DMCA lawyers, but require a written subpoena
> to do so.
>
[snip]

> quoting myself, the answer is in the beginning of this email:
>
> " >> expect the worst in torrent-related matters."
>
> cheers.
>
> x9p
>
>

But they WILL terminate your contract. Do not host in The Netherlands,
but in Switzerland or Iceland. Illegal torrents are forbidden in The
Netherlands, and actively chased nowadays.

Re: About WPA2 compromised protocol

[Erik van Westen]

Op 16-10-2017 om 12:43 schreef Stefan Sperling:
> On Mon, Oct 16, 2017 at 10:22:26AM +, C. L. Martinez wrote:
>> HI all,
>>
>>  Regarding WPA2 alert published today: https://www.krackattacks.com/,
>> if I use an IPSec tunnel with shared-key or certifcate or an OpenVPN
>> connection to authenticate and protect clients and hostAP comms, is
>> this vulnerability mitigated?
>>
>>  Thanks.
>>
> Also this was *NOT* a protocol bug.
> arstechnica claimed such nonesense without any basis in fact and
> now everybody keeps repeating it :(
>
> It was an implementation bug.
>
Ah, good to know. But did every manufacturer make the same mistake then?

Erik

Re: About WPA2 compromised protocol

[Erik van Westen]

Op 16-10-2017 om 12:22 schreef C. L. Martinez:
> HI all,
>
>  Regarding WPA2 alert published today: https://www.krackattacks.com/,
> if I use an IPSec tunnel with shared-key or certifcate or an OpenVPN
> connection to authenticate and protect clients and hostAP comms, is
> this vulnerability mitigated?
>
>  Thanks.
>
Sure. A tunnel over WIFI is the preferred option anyway. WIFI cannot be
assumed to be safe.

Erik

Re: routing problem with wordpress and external and internal traffic

[Erik van Westen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Op 27-9-2017 om 11:20 schreef Markus Rosjat:
> Hi there, > > I have a small problem getting a wordpress instance, that works
with ips in the url, to work from the internal net. > > So here ist the
setup > > a webserver for some application behind a Openbsd Firewall
(webbserver is openBSD 6.0) I have a static ip for my external nic and
the wordpress instance uses the external ip in the site url.
Additionally I have to use a diffrent port then https because there is a
proxy server listining for some other application. > > While reaching
the site from the outsite world is no problem because its simple
redirect to the webserver and the wordpress instance has the url saved
it becomes kinda tricky to reach the wordpress instance from the inside.
in the internal net the webserver is listens on port 80 and 443 so I can
reach it from the inside but then the wordpress instance is rewiriting
the url to a port that isnt 443 becuase from the outsideworld it expects
a diffrent port. > > So question now is, is it possible to route the way
from inside to the outside and back without inventing the wheel new or
is it simpler just to let the webserver listen to the diffrent port too?
> > I hope it makes sense to someone to give me a push in the right
direction > > regards > Hi,


I think you are looking for something along the lines like:

match in on $vlan1 proto tcp from any to $realoutside port 443 rdr-to
$misp port 443

vlan1 is an inside network, and misp is an internal machine (was
reachable from the outside and needed to be reachable on the inside as
well).

Am I correct?

Regards,

Erik

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQIcBAEBCAAGBQJZy814AAoJEAeixT/cUIgnicQP/0+bYFH04K3ZagwfTi22NjMN
0txdUlLJCIJtRVaeLFJ4u7MDCKC9CzJO6s7NIwBmwKmaE40fL+itWAJH/qQ1DRQ3
uyG8AlccGLS+KnjNze7zR3rDPMsJFrgtOKVAU0YRNYEFxS0ShYBzme8ZydAwxq7M
Br/RxTHEA1kV0kfYk7z1JffdjYkGPpZG9/ocwdVKiwKBOf0LAz8OrlAwEhDcjd/B
jWs/T6GkFNDUo1qS1kmRpwXGIHCGjNdz9k1y3kaZ0lz2htt5ITfya1+d09kFNtaB
N/OIOwj2mLF6WnJrQ/RDmqEDzIX74XUROH7a1hKJpIhDU8yVRgva/czR5CCkOz+m
xwEKESeXhhccOF1aCmY/K3btK0LuBxQqxg48T0XiWeSFyK0V4+nMy4Ddohfuvoll
xyYt225XIWB+9hgNOTuChtuy7hKltj8Lv3dyTrNxkRRd/VFF2d0hm/e4FB3NLdFJ
9SwfeOp/NJ33vc3Z0ohx8589sWfL47IleEQWxEBebVE8uQQI/d+bygDa/HhUaB+W
P1jzETwHeis/SrIp7wShWC600lCsoNLWvcMHrR0Yu2oCNJsUsbwYvs7SmBIvYBty
F6GVpP4Y62hwbHWIL/nALdJSUF6r0GDsn+Gd1DLxQ6ZzP++bBScq93zdW0VXsIxo
3/vQdsjNd6uhh7JwhiXW
=XXdi
-END PGP SIGNATURE-