On Thu, Oct 5, 2023 at 9:04 AM David Gwynne <da...@gwynne.id.au> wrote:
> > > > On 5 Oct 2023, at 11:17, David Higgs <hig...@gmail.com> wrote: > > > > On Tue, Oct 3, 2023 at 10:10 AM David Higgs <hig...@gmail.com> wrote: > > > >> On Mon, Oct 2, 2023 at 9:26 AM David Higgs <hig...@gmail.com> wrote: > >> > >>> On Sun, Oct 1, 2023 at 9:13 AM Zé Loff <zel...@zeloff.org> wrote: > >>> > >>>> On Sat, Sep 30, 2023 at 11:39:36AM -0400, David Higgs wrote: > >>>>> All of my devices until now have been behind my OpenBSD NAT router, > >>>> but I > >>>>> recently acquired a Internet of Trash device that I would like to be > >>>>> accessible to the internet (yes, I know). > >>>>> > >>>>> My home configuration uses a Unifi AP to translate my various SSIDs > >>>> into > >>>>> VLANs which plug into one of my APU em(4) ports. The IoT thing > >>>> already has > >>>>> its own dedicated SSID/VLAN, but doesn't enjoy living behind my NAT. > >>>> > >>>> Define "doesn't enjoy". It absolutely requires a public IP? It needs > >>>> some ports to be forwarded? Has some sort of network connection > >>>> detection that fails because some ports are blocked for outgoing > >>>> traffic? > >>>> > >>> > >>> I'm still trying to determine ground truth with manufacturer support. > >>> Port forwarding doesn't seem sufficient. The device can reach out just > >>> fine but is not remotely controllable as advertised. > >>> > >>>> Is there a way for me to bridge just one of the vlan(4) logical > >>>> interfaces > >>>>> with my other em(4) uplink, so that my IoT item can speak DHCP > directly > >>>>> with my internet provider? > >>>> > >>> > >>>> Can this be done with veb/vport or bridge, or will I need to use > >>>> something > >>>>> more exotic to strip the 802.1q tags before they are sent to my ISP? > >>>> > >>> > >>> Self-replying here: I don't see many examples of veb(4) use online, but > >>> it seems as if I can add my physical uplink and the IoT VLAN both to a > >>> veb and attach a vport to become my new uplink. That should be > logically > >>> equivalent to putting a three-port switch between my router and my ISP > CPE, > >>> with the third port for the IoT device. Is anyone able to shoot holes > in > >>> this or suggest a superior alternative, before I attempt the > configuration > >>> later this week? > >>> > >> > >> I appreciate the previous replies/cluebats, but my initial attempt was > >> rushed and unsuccessful. > >> > >> In broad strokes, I created veb0 and added em0, vlan222, and vport0 to > >> it. Then I tried getting vport0 to speak DHCP with my upstream, but > >> nothing seemed to happen or appear in logs. > >> > >> I will have to spend more time on this to eliminate the possibility of > >> fat-fingering, remove various confounding variables, and produce a > better > >> result/report. > >> > > > > For the archives, this worked swimmingly once I paid closer attention to > > what I was doing. Based on my second attempt, I hadn't put my vport0 > > interface up. > > > > Of course, my ISP isn't handing out more than a single IPv4 address by > > default, so all this has been simply a good learning experience. > > For future reference, if you just want to join two ethernet interfaces on > an openbsd box together you can use tpmr(4). It was almost called xcon(4), > short for cross-connect. > > It's also worth noting the steps taken by the Ethernet stack when it > processes packets and which drivers can take packets at which point. Let's > assume an ethernet packet is coming in on a physical interface, em0 in this > case. > > 1: trunk/aggr processing > > If em0 is part of trunk/aggr, then those drivers will steal the packet and > start processing it again as if it was received on the relevant trunk/aggr > interface. > > 2. service delimited packet filtering, ie, vlan/svlan handling > > If em0 is a parent interface to vlan or svlan interfaces, this is when > they get taken and processing starts again as if they were received on the > virtual interfaces. > > If no vlan/svlan interface is configured, the packets are marked as now > marked as "service delimited". > > 3. bridge processing > > This is where bridge/veb/tpmr can take a packet. > > 4. dropping service delimited packets > > This is where vlan/svlan tagged packets are dropped that all the preceding > aggr/trunk/vlan/svlan/bridge/veb/tpmr drivers declined. The exception is > packets send to vlan 0, because vlan 0 isn't real and is only used to carry > priority information on the wire for the native vlan. > > This means that you can set up a bridge/veb/tpmr that forwards vlan tagged > packets, but optionally slice specific vlans off for other processing by > configuring a vlan interface with em0 as a parent to take those packets > away first. > > 5. carp > > If the destination address is for a carp interface on em0, it's at this > point it's taken away. > > 6. Ethernet procotol handling > > This is when the arp/ipv4/ipv6 protocols are checked and the packets are > fed into the layer 3 stacks. > Logically, I wanted three hosts in the same broadcast domain (ISP CPE, IoT device, OpenBSD router), so tpmr(4) didn't seem appropriate - was I missing something? --david
