Re: Bridging em and vlan
> On 6 Oct 2023, at 01:50, David Higgs wrote: > > 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? No, you were right to reach for veb in your setup.
Re: Bridging em and vlan
On Thu, Oct 5, 2023 at 9:04 AM David Gwynne wrote: > > > > On 5 Oct 2023, at 11:17, David Higgs wrote: > > > > On Tue, Oct 3, 2023 at 10:10 AM David Higgs wrote: > > > >> On Mon, Oct 2, 2023 at 9:26 AM David Higgs wrote: > >> > >>> On Sun, Oct 1, 2023 at 9:13 AM Zé Loff 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,
Re: Bridging em and vlan
> On 5 Oct 2023, at 11:17, David Higgs wrote: > > On Tue, Oct 3, 2023 at 10:10 AM David Higgs wrote: > >> On Mon, Oct 2, 2023 at 9:26 AM David Higgs wrote: >> >>> On Sun, Oct 1, 2023 at 9:13 AM Zé Loff 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.
Re: Bridging em and vlan
On Tue, Oct 3, 2023 at 10:10 AM David Higgs wrote: > On Mon, Oct 2, 2023 at 9:26 AM David Higgs wrote: > >> On Sun, Oct 1, 2023 at 9:13 AM Zé Loff 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. --david
Re: Bridging em and vlan
On Mon, Oct 2, 2023 at 9:26 AM David Higgs wrote: > On Sun, Oct 1, 2023 at 9:13 AM Zé Loff 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. Silly question, does it even make sense to add a single vlan interface to a veb? Is there maybe parent confusion between veb0 and em2 (Wifi AP iface)? Thanks. --david
Re: Bridging em and vlan
On 2023-10-02, David Higgs wrote: > Related question: It doesn't appear that veb (and bridge) are part of > either amd64 RAMDISK. Does this create any added complexity with > (sys)upgrades or does it somehow Just Work(tm)? sysupgrade downloads to disk so the bsd.rd upgrade run can work without network, so no issue there. if you were to run bsd.rd by hand and run a network-based upgrade from there you would need manual config if you need the bridge for internet access.
Re: Bridging em and vlan
couple ideas log all traffic destined to/from IOT device IP address, see if there is additional udp/tcp connections for the device during the remote control session I was also going to suggest capturing packet flow with tcpdump, but the first step is a good place to start. diana KI5PGJ On October 2, 2023 7:26:30 AM MDT, David Higgs wrote: > > >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. >
Re: Bridging em and vlan
On Sun, Oct 1, 2023 at 9:13 AM Zé Loff 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? > > Assuming your WAN connection also gets its IP address by DHCP, will your > ISP assign you multiple IP addresses, one for your uplink, one for the > IoT device? > Hopefully so, but that's orthogonal to the question I'm asking. If you absolutely need the IoT device to have unfiltered connection to > the internet, you can just create a DMZ of sorts for that VLAN, let all > traffic pass out, forward the necessary ports for incoming traffic, and, > assuming you don't trust the device at all, block all traffic from that > VLAN to the rest of the network (or be very selective about it), and > maybe also from other VLANs to that VLAN. Putting it in a different > rdomain altogether might also be a good idea. I've already tried that without success. > 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? Related question: It doesn't appear that veb (and bridge) are part of either amd64 RAMDISK. Does this create any added complexity with (sys)upgrades or does it somehow Just Work(tm)? Thanks again, --david
Re: Bridging em and vlan
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? > 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? Assuming your WAN connection also gets its IP address by DHCP, will your ISP assign you multiple IP addresses, one for your uplink, one for the IoT device? > 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? If you absolutely need the IoT device to have unfiltered connection to the internet, you can just create a DMZ of sorts for that VLAN, let all traffic pass out, forward the necessary ports for incoming traffic, and, assuming you don't trust the device at all, block all traffic from that VLAN to the rest of the network (or be very selective about it), and maybe also from other VLANs to that VLAN. Putting it in a different rdomain altogether might also be a good idea. > Thanks in advance, > > --david --
