#7338 closed defect (fixed)
NAT passes multicast packets from guest to host => Fixed in SVN
回報者: | mackyle | 負責人: | |
---|---|---|---|
元件: | network/NAT | 版本: | VirtualBox 4.0.4 |
關鍵字: | 副本: | ||
Guest type: | Linux | Host type: | Mac OS X |
描述 (由 作最後更新)
STEPS
1. Set up a guest (ubuntu linux for example) with a single network interface connected to NAT
2. Enable avahi (an mDNS server) in that guest
3. Run an mDNS observer on the host (Bonjour Browser http://www.tildesoft.com/ on Mac OS X for example)
4. Notice that the host sees the mDNS packets (UDP multicast to 224.0.0.251) from the guest
ANALYSIS
Running wireshark on the host shows that the mDNS packets appear to originate from the IP address assigned to en0 on the host (Mac OS X).
EXPECTED BEHAVIOR
While there may be a legitimate need to re-broadcast multicast packets from one side of the NAT to the other, that should be an opt-in behavior rather than always on. At the very least there should be a VBoxManage option to disable multicast packets passing through the NAT.
PROBLEM THIS CAUSES
If you have two interfaces configured for your guest, say NAT on one and HOST-only on the other, the expectation is that the host can only connect to the guest via the HOST-only interface. And that is the reality. However, because the NAT is passing multicast DNS packets from the guest to the host, the host sees both of the guest's interfaces' addresses advertised -- the HOST interface address which it legitimately receives via the mDNS packet over the HOST-only interface and the hidden, NAT-assigned address that is completely unreachable from the host (because the NAT rebroadcasts that mDNS announcement). When the host then attempts to lookup a .local mDNS address that resolves to the guest, it often picks just one address if multiple are available and which one is somewhat arbitrary -- if it picks the hidden NAT address, connectivity with the guest fails (this occurs quite frequently).
WORKAROUND
There is no good workaround, although it is possible to block UDP packets to port 5353 that appear to come from the en0 interface via the host's firewall.
NOTES
Have tested this with various guests, the problem is independent of the guest OS type. Have only tested with Mac OS X host though.
Same problem with guest: linux, host: linux, net: NAT and bridge