Hello Tom, Thank you very much for your in-depth explanations.
Actually enabling mac changes and forged transmits did the trick. A HUGE trick: While A was pinging R, I tried to look at the icmp requests and replies on B’s vmx1 interface. But they did not show. Neither bridge0 or vmx0 showed anything from or to A. I then blocked all traffic in B’s pf. A still kept on pinging successfully. I then shut down B. A was still happily pinging R. This is really scary! I intended to protect a Linux host whose firewall I don’t trust, but now it seems that I can trust VMware’s vmswitch even less. I also love VMware, it is fine for playing with networks, subnetting, IPSec etc.. but I never used virtual switches before. If there isn’t any way to firewall another host without doing NAT (both in the same subnet’s IP range), then I am afraid the Linux firewall will have to do. With kind greetings, Heinrich > On 29. Nov 2020, at 23:26, Tom Smyth <tom.sm...@wirelessconnect.eu> wrote: > > Hello Heinrich, > it is not OpenBSD it is a Vmware issue ... > > virtualnets / vswitches in ESXI are not proper switches... they forward > packets based on static mac- virtual port entries. (they do not do proper > mac learning) > > you can set the vwswitch in the networking configuration section ... there > are 2 places you can set it ... in the vmnet and the vswitch setup in the > vmnet setup config in vsphere > > there are 3 workarounds > > 1) use promiscuous mode (you can set the promiscuous setting on the vswitch) > you will also need to allow mac changes and forged transmits (from memory) > Upside (it works) and is Free > > downside each vm on that vswitch receives a copy of the frames sent and > received ... promiscuous makes a vhub rather than a vswitch > so it is slower than one would like > > 2) there is a lab test switch (it was in vmware labs I think) that does mac > learning however it does not do mac aging > upside it works and is faster than promiscuous > downside not againg out macs is just f**king dumb ... > > 3) get the enterprise enterprise enterprise + licence and they will give you > proper mac learning on the virtual switches > > and that is the reason I migrated to a different Virtual machine solution ... > > I love Vmware but they are optimistic when they call their vswitches > switches ... they are efficeint for non forwarding workloads and I can > understand why they do the static map by default > but for networking (they dont even give you LACP on their enterprise licence > you have to go for their top line license enterprise Plus (last time i > checked) > > it is a pitty because I do like Vmware and moving off it was tough as > breaking an addiction... > > Hope this helps > > Tom Smyth > > > > On Sun, 29 Nov 2020 at 22:10, Heinrich Rebehn <heinrich.reb...@rebehn.net > <mailto:heinrich.reb...@rebehn.net>> wrote: > Unfortunately, switching to vmx(4) did *not* do the trick > > -Heinrich > > > > On 29. Nov 2020, at 22:38, Heinrich Rebehn <heinrich.reb...@rebehn.net > > <mailto:heinrich.reb...@rebehn.net>> wrote: > > > > Some things I forgot: > > > > All interfaces are UP > > pf(4) ist disabled > > bridge0 sees a bunch of lladdrs on em0 and one on em1, which is that of “A” > > > > -Heinrich > > > > > >> On 29. Nov 2020, at 22:29, Heinrich Rebehn <heinrich.reb...@rebehn.net > >> <mailto:heinrich.reb...@rebehn.net> <mailto:heinrich.reb...@rebehn.net > >> <mailto:heinrich.reb...@rebehn.net>>> wrote: > >> > >> Hi all, > >> > >> I am trying to setup an OpenBSD 6.7 virtual machine under VMware ESXi 6.7 > >> to use as a filtering bridge between two virtual networks. I enabled > >> promiscuous mode for both virtual switches. > >> One network is the VMnet network, which is connected to the “outside > >> world”. > >> > >> “A” ——> “B” ——> “R” > >> > >> “A” is a test machine 192.168.1.152 > >> “B” is the bridge No IP. em0 connects to R, em1 connects to A > >> “R” is the router provided by the hoster 192.168.1.1 > >> > >> The addresses are only examples, the actual addresses a public IPs. > >> > >> When A tries to ping R, ist sends an arp request for R’s lladdr. R > >> responds with its lladdr. Tcpdump on R’s em1 suggests that it is sent out > >> on the virtual network. However, A does not see the arp reply, hence > >> ping(8) fails. > >> > >> What am I missing? While browsing the mailing list archive, I just saw > >> that vmx(4) might be a better choice, but I had not yet time to try it out. > >> > >> > >> Any other known issues around bridge(4) or promiscuous mode under ESXi ? > >> > >> Thanks for any insights, > >> > >> Heinrich > > > > -- > Kindest regards, > Tom Smyth.