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.smyth@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.Rebehn@rebehn.net <mailto:Heinrich.Rebehn@rebehn.net>> wrote:
> Unfortunately, switching to vmx(4) did *not* do the trick
>
> -Heinrich
>
>
> > On 29. Nov 2020, at 22:38, Heinrich Rebehn <Heinrich.Rebehn@rebehn.net <mailto:Heinrich.Rebehn@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.Rebehn@rebehn.net <mailto:Heinrich.Rebehn@rebehn.net> <mailto:Heinrich.Rebehn@rebehn.net <mailto:Heinrich.Rebehn@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.
No comments:
Post a Comment