Changes between Initial Version and Version 3 of Ticket #10811
- Timestamp:
- Sep 12, 2019 12:44:02 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #10811
- Property Status new → closed
- Property Resolution → obsolete
-
Ticket #10811 – Description
initial v3 3 3 When run from within the VM, I can connect clients to this server and ping/log into the server's IP, (guest machine) but I cannot access the Host's IP or anything else on the LAN from the client. If I set up the OpenVPN server identically on the host, (Which is the same OS and otherwise identical setup) it works fine. OpenVPN requires setting up a bridge internally on the server for this kind of layer 2 tap VPN, and putting the ethernet interface into promiscuous mode. I've tried attaching the VM bridged adapter to the physical eth0 interface of the host and also to a bridged adapter on the host that was then bridged to the eth0 interface while eth0 was in promiscuous mode (similar to the setup on the guest) 4 4 5 I have found two other references to this problem, one with a Linux host, the other with Windows. The Windows one was ticket 8965. Both references indicate that this bug was a regression between versions 4.0.4 and 4.0.6. Since I'm using Ubuntu 12.04 and VBox 4.1.18, downgrading to VBox 4.0.4 to confirm this would be painful.5 I have found two other references to this problem, one with a Linux host, the other with Windows. The Windows one was ticket #8965. Both references indicate that this bug was a regression between versions 4.0.4 and 4.0.6. Since I'm using Ubuntu 12.04 and VBox 4.1.18, downgrading to VBox 4.0.4 to confirm this would be painful. 6 6 7 7 Looking at the changelog of 4.0.6, I suspect that I've found the culprit: … … 10 10 Not sure what is meant by "switch behavior" but a switch is nothing more than a many-port bridge, which will broadcast frames to all ports but the one it came in on if the MAC is not in the MAC table, will learn the source MAC of any frame and put it in the MAC table for the port it came in on, and will unicast learned MACs to the ports on which the MAC table says they reside. This may be somewhat inconsistent with being able to specify a MAC for the bridged adapter of the guest (which I have also done in this case) If the switch portion is not flooding unlearned frames out to the guest machine virtual ports and also learning new MAC entries from frames sent by those ports, then the behavior may be efficient, but it will also be incorrect for Guests with their interfaces in promiscuous mode. 11 11 12 This bug is closely related to https://www.virtualbox.org/ticket/8965 and this version with the Linux host type is also referenced here: https://forums.virtualbox.org/viewtopic.php?f=7&t=42335&p=203067&hilit=openvpn#p20306712 This bug is closely related to #8965 and this version with the Linux host type is also referenced here: https://forums.virtualbox.org/viewtopic.php?f=7&t=42335&p=203067&hilit=openvpn#p203067
