Re: Low throughput with 1 GigE interface
Thank you @Noth. You are right. The OpenBSD PF FAQ also says: > PF will only use one processor, so multiple processors (or multiple cores) WILL NOT improve PF performance. For PC Engines APU users, I can highly recommend to update the BIOS. It improved my networking performance quite a bit: https://pcengines.github.io/ When testing with iperf3 I now get 450Mbit/s instead of 200Mbit/s (with pf enabled). With pf disabled, I get ~750Mbit/s. Copying files from one to another machine (same physical NIC on APU, with VLANs and PF enabled) gave me around 930Mbit/s. Again, many thanks for all your help and inputs! On 2/5/2020 12:56 AM, Noth wrote: > According to the manufacturer of the APU2, the problem is with OpenBSD not > using all cores for network traffic management: > https://teklager.se/en/knowledge-base/apu2c0-ipfire-throughput-test-much-faster-pfsense/
Kibana/Elasticsearch fail
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? Thanks, EZ
Re: Process Isolation
Sent via BlackBerry® from Telstra -Original Message- From: "Johnathan M." Sender: owner-m...@openbsd.org Date: Thu, 6 Feb 2020 08:26:05 To: Charlie Burnett Cc: Subject: Re: Process Isolation On Thu, Feb 6, 2020, 4:22 AM Charlie Burnett wrote: > Hey y'all, > > Sorry if this has been answered before but I couldn't find a satisfactory > answer searching for it, and this is more of an academic question. So > security focused Linux distros like Qubes go to extremes to > compartmentalize/isolate any and all programs it can. > Qubes uses a hypervisor like kvm/qemu iirc, and the equivalent for OpenBSD would be vmm/vmd. >
Re: no pcap file from isakmpd in OBSD6.6
Christoph Leser wrote:
Hi,
after upgrading openbsd6.5 to oopenbsd6.6 using sysupgrade isakmpd
does no longer write pcap files in /var/run.
In /var/log/messages we see the following message:
isakmpd[7385]: log_packet_init: fopen ("/var/run/isakmpd.pcap", "w")
failed: Permission denied
On 2019-12-03 19:30, Theo de Raadt wrote:
m_priv_local_sanitize_path() contains some realpath() checks.
I think this is either exposing realpath() abuse( as a result of the
new in-kernel realpath to support unveil better), or it is hitting the
realpath() bug which was fixed post-release?
I get similar message when trying to report information about SAs to
isakmpd.results through isakmpd.fifo on 6.6.
echo "S" > /var/run/isakmpd.fifo
...(as root) doesn't return anything, doesn't create results file, and
gives error message in log:
Feb 6 21:20:16 kerber isakmpd[36105]: ui_open_result: fopen() failed:
Permission denied
If someone knows about some workaround for obtaining isakmpd.results
on 6.6 I'd be very grateful (or at least binary patch :D )
--
Before enlightenment - chop wood, draw water.
After enlightenment - chop wood, draw water.
Marko Cupać
https://www.mimar.rs/
Re: permissiomns of /dev/fd* and others
Cannot reproduce this issue, and the MAKEDEV script in question has had only minor unrelated changes. Something is messed up on your system, and you can diagnose this better yourself. Jan Stary wrote: > With the latest two upgrades (this week and the last), > the daily security complains about the permissions under /dev (below). > On other machines, these belong to root:operator - is it intended > that the snapshot changed them to root:wheel? > > dmesg at bottom > > Jan > > > On Feb 06 01:44:10, r...@stare.cz wrote: > > > > Running security(8): > > > > Checking disk ownership and permissions. > > Disk /dev/fd0Ba is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Bb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Bc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Bi is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Ca is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Cb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Cc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Ci is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Da is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Db is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Dc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Di is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Ea is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Eb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Ec is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Ei is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Fa is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Fb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Fc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Fi is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Ga is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Gb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Gc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Gi is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Ha is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Hb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Hc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0Hi is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0a is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0b is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0c is user root, group wheel, permissions brw-r-. > > Disk /dev/fd0i is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Ba is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Bb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Bc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Bi is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Ca is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Cb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Cc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Ci is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Da is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Db is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Dc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Di is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Ea is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Eb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Ec is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Ei is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Fa is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Fb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Fc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Fi is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Ga is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Gb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Gc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Gi is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Ha is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Hb is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Hc is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1Hi is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1a is user root, group wheel, permissions brw-r-. > > Disk /dev/fd1b is user root, group wheel,
Re: [drm] *ERROR* [CRTC:41:pipe ] flip_done timed out
Hi again, Disabling inteldrm has stopped the ERROR messages to show up but of course OpenBSD will not switch into higher resolution since then. Regards Kris -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: chroot vs unveil
Kevin Chadwick wrote: > I am considering replacing all chroot use with unveil in my processes even > where > no filesystem access is required. I am discouraging this. unveil is a complicated mechanism, and we may still discover a bug in it. Almost all the chroot in the tree are to empty unwriteable directories, in which case chroot is very secure and a very simple mechanism.
Re: is there a 2GB limit on amd64 link?
Yes, that (-mcmodel=medium) is the solution. Thanks! John On 2020-02-05 22:03, Philip Guenther wrote: On Wed, Feb 5, 2020 at 7:38 PM wrote: I am encountering a linker error when compiling with ports-gcc Fortran: ld: error: lbug2.f90:(function MAIN__: .text+0x80): relocation R_X86_64_PC32 out o f range: 2456507324 is not in [-2147483648, 2147483647] The code has several large arrays, the total size of which exceeds 2GB. Is this a linker issue, a gcc fortran issue, or a pebkac? It's at least a gnu fortran issue: it needs to generate object code in a larger "model" than it currently is. I've never used gnu fortran, but it might accept the -mcmodel=medium option like gcc and generate code sequences for data symbols that don't limit them to the bottom 2GB (or to within 2GB of the involved code, depending on gcc's choices in implementing the model). If it doesn't accept that option, then you'll need to work with the the docs, mailling lists, etc of the upstream gnu fortran project about how to have it generate code for the medium or large data models per the amd64 ABI. Philip Guenther
Re: [drm] *ERROR* [CRTC:41:pipe ] flip_done timed out
OK, will give it a go. I have already tried to disable drm* and drm0 and that just caused the laptop to hang during boot. Will give you a shout what happened when I disable inteldrm. Cheers -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Can't install OpenBSD 6.6 on apu4d4
On 2020-02-06 07:56, mabi wrote: > Thanks Mischa! I should have thought about that but I couldn't remember > having done this with previous APU models and OpenBSD versions. I expect you known but you can add this into /etc/boot.conf I also recently forgot or found I had to edit /etc/ttys too to get a getty login.
chroot vs unveil
I am considering replacing all chroot use with unveil in my processes even where no filesystem access is required. Is there any guidance on whether that is the best practice, where you only intend to run on OpenBSD?
Re: Process Isolation
On Thu, Feb 6, 2020, 4:22 AM Charlie Burnett wrote: > Hey y'all, > > Sorry if this has been answered before but I couldn't find a satisfactory > answer searching for it, and this is more of an academic question. So > security focused Linux distros like Qubes go to extremes to > compartmentalize/isolate any and all programs it can. > Qubes uses a hypervisor like kvm/qemu iirc, and the equivalent for OpenBSD would be vmm/vmd. >
Re: Process Isolation
On 2020-02-06 07:59, Charlie Burnett wrote: > I apologize if this was a question I've somehow missed the answer to! OpenBSD takes a more fine grained approach in isolating functions rather than whole programs ideally by the person best suited to do the job (the program developer). Isolating whole programs has proven not to work very well, especially on Intel ;) https://www.openbsd.org/papers/bsdcan2019-unveil/index.html
Re: Process Isolation
Den tors 6 feb. 2020 kl 10:22 skrev Charlie Burnett : > Sorry if this has been answered before but I couldn't find a satisfactory > answer searching for it, and this is more of an academic question. So > security focused Linux distros like Qubes go to extremes to > compartmentalize/isolate any and all programs it can. FreeBSD has it's jail > program which is seemingly the gold standard for process isolation when you > can't be bothered to go to the extent Qubes does. I've been trying to read > as much OpenBSD source as I can as I find some of the security tricks > y'all've come up with damn interesting. I know that once upon a time we had > sysjail, but nowadays we have just have chroot which most systems do. What > is OpenBSD's solution to this? I'm sure I've read through it I just didn't > realize the purpose. > > I apologize if this was a question I've somehow missed the answer to! > Almost looks like you missed the question while posting the answer. You list some-linux does X, fbsd does Y, obsd does Z (which you find damn interesting!) and then ask "what is openbsds solution to this?". As of now, Z is the list of mitigations openbsd does, and that is.. the solution to "this". -- May the most significant bit of your life be positive.
Re: permissiomns of /dev/fd* and others
With the latest two upgrades (this week and the last), the daily security complains about the permissions under /dev (below). On other machines, these belong to root:operator - is it intended that the snapshot changed them to root:wheel? dmesg at bottom Jan On Feb 06 01:44:10, r...@stare.cz wrote: > > Running security(8): > > Checking disk ownership and permissions. > Disk /dev/fd0Ba is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Bb is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Bc is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Bi is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Ca is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Cb is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Cc is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Ci is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Da is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Db is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Dc is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Di is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Ea is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Eb is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Ec is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Ei is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Fa is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Fb is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Fc is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Fi is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Ga is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Gb is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Gc is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Gi is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Ha is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Hb is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Hc is user root, group wheel, permissions brw-r-. > Disk /dev/fd0Hi is user root, group wheel, permissions brw-r-. > Disk /dev/fd0a is user root, group wheel, permissions brw-r-. > Disk /dev/fd0b is user root, group wheel, permissions brw-r-. > Disk /dev/fd0c is user root, group wheel, permissions brw-r-. > Disk /dev/fd0i is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Ba is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Bb is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Bc is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Bi is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Ca is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Cb is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Cc is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Ci is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Da is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Db is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Dc is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Di is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Ea is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Eb is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Ec is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Ei is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Fa is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Fb is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Fc is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Fi is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Ga is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Gb is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Gc is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Gi is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Ha is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Hb is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Hc is user root, group wheel, permissions brw-r-. > Disk /dev/fd1Hi is user root, group wheel, permissions brw-r-. > Disk /dev/fd1a is user root, group wheel, permissions brw-r-. > Disk /dev/fd1b is user root, group wheel, permissions brw-r-. > Disk /dev/fd1c is user root, group wheel, permissions brw-r-. > Disk /dev/fd1i is user root, group wheel, permissions brw-r-. > Disk /dev/rd0a is user root, group wheel, permissions brw-r-. > Disk /dev/rd0c is user root, group wheel, permissions brw-r-. > Disk /dev/sd0a is user root, group wheel, permissions brw-r-. >
Re: bad ip cksum 0! -> in enc interface
Den ons 5 feb. 2020 kl 21:01 skrev Riccardo Giuntoli : > I'm setting up a roadwarrior type ikev2 secure connection from .es to .uk. > root@ganesha:/etc# cat hostname.enc0 > > root@smigol:/etc# cat hostname.enc0 > inet 172.16.44.2/32 > up > Why are you setting up hostname.enc0? What guide is recommending you to do that? > I cannot find solution in Internet and the real think is that in many > others post people copy and paste packets and this error is visible but no > one think that is in effect an error or do not speak about. > Please set a vpn up like the openbsd faq on IPSec VPNs shows, and take it from there. It never mentions adding ip to enc0 (and that is not the purpose of enc0) so I don't see why you should. enc(4) is a debug and filtering tool not a config part of vpns. -- May the most significant bit of your life be positive.
Re: bad ip cksum 0! -> in enc interface
Hi there Janne. Result is the same in both endpoints. With or without ipcomp. Any others suggestions? Nice regards to you all misc@ On Thu, Feb 6, 2020 at 8:10 AM Janne Johansson wrote: > Den ons 5 feb. 2020 kl 21:01 skrev Riccardo Giuntoli : > >> If i sniff traffic over enc0 interface I found a strange error about ip >> chksum: >> >> (DF) (ttl 63, id 43164, len 52) (DF) (ttl 64, id 18753, len 72, bad ip >> cksum 0! -> c48a) >> This is the error as you can review. >> >> I cannot find solution in Internet and the real think is that in many >> others post people copy and paste packets and this error is visible but no >> one think that is in effect an error or do not speak about. >> > > You often see 0 in packet checksum fields if the packet is heading out on > a device > which claims to do ipv4 checksum offloading in hardware. In such cases, > the OS will > not spend time doing software checksums, but the hardware will do it just > before the > packet leaves for the network, so that is why the software sniffer will > see 0 there, but > the remote end (you do look for errors from both ends, right?) will see > something else > there. > > -- > May the most significant bit of your life be positive. > -- Name: Riccardo Giuntoli Email: tag...@gmail.com Location: Canyelles, BCN, España PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net
Process Isolation
Hey y'all, Sorry if this has been answered before but I couldn't find a satisfactory answer searching for it, and this is more of an academic question. So security focused Linux distros like Qubes go to extremes to compartmentalize/isolate any and all programs it can. FreeBSD has it's jail program which is seemingly the gold standard for process isolation when you can't be bothered to go to the extent Qubes does. I've been trying to read as much OpenBSD source as I can as I find some of the security tricks y'all've come up with damn interesting. I know that once upon a time we had sysjail, but nowadays we have just have chroot which most systems do. What is OpenBSD's solution to this? I'm sure I've read through it I just didn't realize the purpose. I apologize if this was a question I've somehow missed the answer to!
Re: VLAN or aliases or? best way to isolate untrustable hosts in a small network
Brian, I'm going to set vnetid 100 to tag VLAN and connect physical em0 to L3 switch "uplink" port (port 10 in my case) with "Tagged" mark. # /etc/hostname.vlan100 description 'Untrusted' inet 192.168.155.1 255.255.255.240 192.168.155.15 lladdr 32:f6:02:c4:1A:88 vlandev em0 vnetid 100 Ports 1-3 on L3 switch will be used for IoT connection and marked as "Untagged". Do you think will it be right? Denis On 2/5/2020 10:19 PM, Brian Brombacher wrote: > The OP’s hostname.vlan* files never specify a vnetid. I get an error trying > to configure and bring up the second vlan interface the same way without > vnetid specified. Regardless of my error, the ifconfig(8) man page says > without vnetid specified, vlan tag 0 will be used. You need to specify two > different vlan tags. > > All of that aside: VLANs don’t give you any more security. If the client > host is on the same physical network as your two VLANs, the only thing > stopping them from jumping between VLANs would be physical devices (switches, > etc.) configured to prevent that. From what I gathered, you don’t have this > level of control. Therefore, you gain nothing by segmenting the networks > with VLANs. > > -Brian > >> On Feb 5, 2020, at 11:58 AM, Christian Weisgerber wrote: >> >> On 2020-02-05, Janne Johansson wrote: >> # /etc/hostname.vlan101 description 'WLAN attached untrusted hosts' inet 192.168.156.0/24 255.255.255.0 vlandev run0 >>> VLANs and wifi sounds like a non-starter. >> >> Yep, if you're building your access point with OpenBSD. >> >> More generally, though, any AP in the business segment has support >> for multiple SSIDs that can be assigned to different VLANs on the >> Ethernet side. >> >> -- >> Christian "naddy" Weisgerber na...@mips.inka.de >
Re: VLAN or aliases or? best way to isolate untrustable hosts in a small network
Thank you for all the replies. Christian right, I didn't familiar with VLANs before my conceptual question about IoT isolation, so I have no knowledge how do VLANs work before his answer. Thanks to documentation, articles, and vlan(4), in OpenBSD for any of physical Ethernet device can be attached multiple VLANs but L3 switch with IEEE 802.1Q protocol supported must be present. Hopefully, GS110TP has L3 compatibility but requires to point "Tagged" & "Untagged" for each of VLAN port during VLANs allocation. If I understand the concepts right, I should _tag_ each /etc/hostname.vlan1xx outgoing traffic and connect physical Ethernet cable to specially allocated port on L3 switch for "Tagged" VLAN traffic. I'd like to call it as "Uplink" port on L3 switch to connect to OBSD box physical Ethernet port. Any group of ports intended for IoT connection (L3 switch ports 1-3 in my case) should be marked as "Untagged" to connect IoT devices. Please correct me if I've been mistaken. As for "access point", it works well and actively use for a long time. Second SSID is a good idea to make some isolation for untrusted and filter in PF by some indication but I don't know which indication for now. I think it will be the next step forward to wireless IoT isolation. Denis On 2/5/2020 5:53 PM, Christian Weisgerber wrote: > On 2020-02-05, Janne Johansson wrote: > >>> # /etc/hostname.vlan101 >>> description 'WLAN attached untrusted hosts' >>> inet 192.168.156.0/24 255.255.255.0 vlandev run0 >> >> VLANs and wifi sounds like a non-starter. > > Yep, if you're building your access point with OpenBSD. > > More generally, though, any AP in the business segment has support > for multiple SSIDs that can be assigned to different VLANs on the > Ethernet side. >
