vSwitch, promiscuous mode and OpenVPN

[vspherization]

Hello,

I've deployed an OpenVpn infrastructure (configured in bridging mode) within a VMmare ESX4 environment.
The scenario is this:

A remote client connects to the OpenVpn server (VM1), VM1 also owns an interface where traffic passes in tagged mode complaint to vlan 8021q, VM2 owns a interface on the vlan10. VM1 can ping VM2 without any problem (supposing vlan 10 traffic).

http://imageshack.us/photo/my-images/259/networkb.png/

VM1 has two NICs, one configured to be contacted remotely by remote openvpn clients and one configured to send frames compliant to vlan 8021q protocol (This is obtained by a software related to openVpn) to internal vlans.

VM2 has one NIC, configured to be within the vlan10.

All the ports of the VMware vSwitch (except one) are configured to multiplex and demultiplex level 2 traffic based on a VLANID (for example VLAN10). Only one port, that one related to the second NIC of the VM1 is configured in trunk mode (VLANID 4095). In this manner frames from different VLAN will be received by the vSwitch through the trunk link and will be sent out to the right vlan ports. A software on VM1 will pack frames compliant to 8021q and will send out them through the second NIC .

After an openvpn connection the remote client cannot ping VM2.
Analizing traffic with Wireshark on the VM2 I've noticed that an ARP request leaves from the remote client MAC to the destination host interface of VM2 (broadcast ARP request).
The host VM2 sends an ARP reply directly to the MAC address of the remote client.

This last packet doesn't pass the vSwitch, so it isn't received by the remote client and the ping fails.
I think this occurs because the vSwitch only knows all the MACs of virtual machines within the ESX environment, it doesn't learn MAC addresses like a physical real switch and it discards packets sent to unknown unicast MAC addresses (broadcast traffic instead is passed).Am I wrong?

If the port of the vSwitch related to the trunk mode is configured in promiscuous mode, the above ARP reply is received by the remote client and the ping succeeds. This is a workaround used by many people in my situation (see this document as example - http://www.jeremycole.com/blog/2010/03/11/openvpn-bridge-under-vmware-esxi/).

My question is, is it possible to solve this situation without configuring the port of the switch in promiscuous mode?

Is available in VMware an emulation of a real switch performing that I am trying to do? How about Cisco Nexus 1000V or Open vSwitch?

Thanks in advance.

[milton123]

Look you wrote your problem very complexly. So far what I have understand that you wanna promiscuous mode. You have configure VLAN here that means switch will initiate a ARP and delivery packet only same VLAN pool. In order to communicate with VLAN you have to configure VLAN routing to pass all traffic.

Cheers, Yours Udin

[vspherization]

Thanks for your reply Milton,

The situation I have described above works perfectly in a physical environment (without any virtual machine, so without ESX server).

OpenVpn is configured in bridging mode, there are more than one openvpn services on the server so it is configured to build more than one tunnel, one for each vlan. For example the first tunnel will put the remote client within the vlan10, the second tunnel will put other clients within the vlan20 etc.

On the second interface of VM1 frames come already tagged ,compliant 8021q, built by the openVpn server and will be received tagged (detagging will be made up by the openvpn server).

[rickardnobel]

vspherization wrote:

Analizing traffic with Wireshark on the VM2 I've noticed that an ARP request leaves from the remote client MAC to the destination host interface of VM2 (broadcast ARP request).
The host VM2 sends an ARP reply directly to the MAC address of the remote client.

This last packet doesn't pass the vSwitch, so it isn't received by the remote client and the ping fails.
I think this occurs because the vSwitch only knows all the MACs of virtual machines within the ESX environment, it doesn't learn MAC addresses like a physical real switch and it discards packets sent to unknown unicast MAC addresses (broadcast traffic instead is passed). Am I wrong?

I think you are most likely right. The vSwitch does not learn MAC address like a physical switch, and normally this is not a problem since it means that all unknown unicast MAC addresses are "outside" the vSwitch and should be delivered to the physical network.

Your ARP request (with Broadcast destination) is sent to all ports on the layer two network, but the vSwitch does not "know" that the remote MAC is reachable through VM1. If you would have layer 3 routing in VM1 then it would work, but I guess this VPN software you use does not work that way?

Another possible workaround would be if VM1 would change the SRC MAC of the ARP request when passing it through, and set the internal vNIC MAC address as source instead. That way it would look correct from the vSwitch, however it might of course not be possible.

[dgoldsmith]

Any information about enabling Promiscuous mode on a portgroup from a Nexus 1000V?

Similar situation here -- we've had a bunch of virtual labs on ESXi 3 and ESXi 4 using local vSwitches and we enabled Promiscuous mode on the portgroup to allow the OpenVPN connection to work with bridging.

Working on moving some of our labs over to ESXi5 servers that are using the Nexus 1000V and under Inventory->Networking, when I right-click on one of the portgroups, 'Edit Settings' is greyed out.  When I connect to our VSM and look at the port profile, I'm not seeing any obvious settings for promiscuous mode.  Looking through N1000V docs but it seems like most mentions of promiscuous have to do with private vlans.

Dave