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.
