I hope it’s not too late to say thank you for your help! Setting up the bridge with tmpr(4) was surprisingly easy. I also added a third interface for management and updates. Since it is not a member of the bridge and ip forwarding is disabled, I have no worries that packets with an alien lladr might emerge to my hoster’s network. Also, the audio problems with my PBX have gone, as it is not behind NAT anymore.
-Heinrich > On 30. May 2025, at 06:56, David Gwynne <da...@gwynne.id.au> wrote: > > there's also veb(4) and tpmr(4). they're also bridges, but won't let traffic > from the network stack on the firewall onto the ports by default. tpmr(4) is > probably best for what you think you want to do here. > > On 30/05/2025 00:02, Heinrich Rebehn wrote: >> >> >>> On 28. May 2025, at 23:03, Stuart Henderson <stu.li...@spacehopper.org> >>> wrote: >>> >>> On 2025-05-27, Heinrich Rebehn <heinrich.reb...@rebehn.net> wrote: >>>> Hello all, >>>> >>>> The question may sound weird, but here is my situation: >>>> >>>> I have a (Linux) PBX (FreePBX) that I want to protect with an OpenBSD >>>> firewall since I am not familiar with Linux' builtin firewall and also I >>>> would like to separate things. >>>> >>>> I also would like to avoid routing / NAT on the firewall, which leads me >>>> to using a transparent filtering bridge. >>>> >>>> When experimenting with such a setup on my rented VMWare ESXi host, I >>>> immediately got an abuse email from my hoster, complaining the use of >>>> unauthorised MAC addresses. >>>> The reason is: >>>> When I order an additional IP address for my PBX VM, I am provided a >>>> defined MAC address which I have to configure on the VM. I am not allowed >>>> to use any other MAC. >>> >>> Surely you still need access to update/manage the firewall? >>> >>> Seems the simplest solution might be to order an additional address to >>> use on it, and configure that MAC address via 'lladdr'. (The VM host may >>> need to be configured to allow using a non-default MAC). >> >> Management could be done via the virtual console (24 lines only, no >> scrolling). My thought was to use a third interface, not bridge member, >> connected to private lan and routed to the internet for management and >> update. >> But your proposal is even better and I will spend the additional €€ on that >> :-). No worries about alien MACs. >> No need to configure MAC via ‘lladr’. The MAC will be entered on the ESXi >> management web page. >>> >>>> My setup: >>>> >>>> +--------------------------+ +--------------------------+ >>>> +----------------+ >>>> | PBX (using provided MAC) |----| OpenBSD filtering bridge |---| hoster's >>>> router| >>>> +--------------------------+ +--------------------------+ >>>> +----------------+ >>>> | | >>>> | | >>>> VMX1 VMX0 with 'alien' >>>> MAC address >>>> >>>> >>>> The challenge: How do I prevent my firewall's VMX0 interface from sending >>>> any packet using any other than the provided MAC address. >>>> >>>> Things that I already considered: >>>> - When acting as a bridge, packets from PBX should be forwarded with >>>> original MAC >>>> - IP forwarding is disabled, net.inet.ip.forwarding=0 >>>> - VMX0 and VMX1 are only configured as UP (no IP address) >>>> - The bridge is configured as: >>>> up >>>> add vmx0 >>>> add vmx1 >>>> blocknonip vmx0 >>>> blocknonip vmx1 >>>> -autoedge vmx0 >>>> -autoedge vmx1 >>>> -edge vmx0 >>>> -edge vmx1 >>>> - /etc/pf.conf: >>>> set skip on lo >>>> block drop out quick log on vmx0 from self to any >>>> block drop in quick log on vmx0 from any to self >>>> block drop log >>>> pass# No filtering done ATM >>>> >>>> >>>> Anything else that needs to be considered? >>> >>> the initial temporary PF ruleset in /etc/rc does allow some packets, >>> though you maybe ok if the interfaces have no address configured. >>> try it with a vm with a network interface plumbed through to another >>> vm where you can watch with tcpdump. >>> >>> bios/uefi may send packets in some circumstances e.g. pxe >> >> Did not think about pxe. But with your above proposal it would use a legit >> MAC! >> >> Thank you! >>> >>>> PS: If you consider this whole setup insane, I am open for better >>>> solutions :-) >>>> >>>> Thanks for any help, >>>> >>>> Heinrich >>>> >>>> >>>> >>> >>> >>> -- >>> Please keep replies on the mailing list. >> >
