> 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.
