I have problems with bridging a VM's network card to the (wireless) network card of the Windows host, in such a way that packets from the VM actually use the VMware MAC address on outgoing packets (and not the host's one paired with the VM's IP address - this is working but breaks in secured networks where a client is supposed to have only one IP associated with any MAC address ...).
I did some forum search and and don't seem to be the only one with this problem 
Which is quite relieving, but I would like to really understand what's going on and why. Before I describe the exact situation here is a list of things I already tried/verified:
\- VMware Bridge Protocol is correctly bound to the wireless adapter in question
\- I also tried disabling automatic bridging and nailing VMnet0 to the wireless adapter - to no avail
\- as firewall "only" the XP SP2 Microsoft firewall is in place (but disabling the firewall and/or also the corresponding windows service didn't help either)
\- no network adapters are bridged together by windows
\- when configuring the VM to use NAT (VMnet8) everything works fine - but the application to be used is not nat-able and needs dynamic incoming connections ;-(
\- bridging also works fine when not using the wireless card but the laptop's built-in wired NIC
\- the wireless AP has no MAC filtering configured
All this - from my point of view - rules out some generic installation/configuration problem of VMware Server. Correct?
So here's my situation (Subnetmask is 255.255.255.0 everywhere):
Guest VM (WinXP SP2, VMnet0, IP(DHCP-reservation) 192.168.10.12, MAC 00-0C-29-68-8A-BD)
\ |
Laptop - VMware Server host (WinXP SP2, Server 1.0.1-29996, Intel BG2200 wireless card, wireless driver v9.0.4.26, IP(DHCP-reservation) 192.168.10.10, MAC 00-0E-35-60-5B-C9)
\ |
Wireless AP (Linksys WRT54G, IP 192.168.10.250, MAC 00-12-17-70-90-c7)
\ |
Linux server (IP 192.168.10.1, MAC 00-03-47-09-24-73)
Some notes:
\- the linux server serves as (the only) DHCP server and hands out IP addresses to anyone - BUT OTHERWISE only accepts any traffic from "known" MAC-IP-pairs (the laptop being one, for example)
\- the wireless AP acts like a bridge, no filtering/firewalling/etc.
Here are the steps that I investigated (and details can be found for each step further down):
1) Guest VM acquiring an IP address from DHCP server (works somewhat)
2) ping guest -> laptop (=host) - works, but strange
3) ping guest -> wireless AP - works, but strange
4) ping guest -> linux server - doesn't work
5) ping linux server -> guest - works, but again strange
6) ARP requests seem to be handled strangely
Step 1: acquiring DHCP address
==============================
The guest VM gets its IP address assigned by the DHCP server fine, as can be seen from the following output:
C:\Programme\VMware\VMware Server>vnetsniffer /e VMnet0
len 342 src 00:0c:29:68:8a:bd dst ff:ff:ff:ff:ff:ff IP src 0.0.0.0 dst 255.255.255.255 UDP
len 353 src 00:03:47:09:24:73 dst ff:ff:ff:ff:ff:ff IP src 192.168.10.1 dst 255.255.255.255 UDP
len 354 src 00:0c:29:68:8a:bd dst ff:ff:ff:ff:ff:ff IP src 0.0.0.0 dst 255.255.255.255 UDP
len 353 src 00:03:47:09:24:73 dst ff:ff:ff:ff:ff:ff IP src 192.168.10.1 dst 255.255.255.255 UDP
len 60 src 00:0c:29:68:8a:bd dst ff:ff:ff:ff:ff:ff ARP sender 00:0c:29:68:8a:bd 192.168.10.12 target 00:00:00:00:00:00 192.168.10.12 ARP request
len 60 src 00:0c:29:68:8a:bd dst ff:ff:ff:ff:ff:ff ARP sender 00:0c:29:68:8a:bd 192.168.10.12 target 00:00:00:00:00:00 192.168.10.12 ARP request
len 60 src 00:0c:29:68:8a:bd dst ff:ff:ff:ff:ff:ff ARP sender 00:0c:29:68:8a:bd 192.168.10.12 target 00:00:00:00:00:00 192.168.10.12 ARP request
But when sniffing this conversation on the linux server you can see that even the DHCP packtes originate from the laptop's MAC address (00-0E-35-60-5B-C9) and the DHCP server can only hand out the correct reservation's address because the real client MAC address is encapsulated again within the packet. To sum it up:
\- the above vnetsniffer output shows the correct originating MAC address, so everything's fine within the virtual environment
\- but already sniffing on the laptop shows that packets leave the host with the host's MAC address
\- packets arrive on the linux server with the hosts's MAC (I can upload a tcpdump trace if someone wants to look at it)
=> the MAC address is changed on/by the VMware server host!?
Step 2: ping guest -> laptop (=host)
====================================
Pinging the host works but it seems that somehow \_two_ answer packets are generated on the host (which seem to be ignored by Windows) - see vnetsniffer output below !?
C:\Dokumente und Einstellungen\up>ping 192.168.10.10
Ping wird ausgefhrt fr 192.168.10.10 mit 32 Bytes Daten:
Antwort von 192.168.10.10: Bytes=32 Zeit=3ms TTL=128
Antwort von 192.168.10.10: Bytes=32 Zeit=4ms TTL=128
Antwort von 192.168.10.10: Bytes=32 Zeit=3ms TTL=128
Antwort von 192.168.10.10: Bytes=32 Zeit=4ms TTL=128
Ping-Statistik fr 192.168.10.10:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 3ms, Maximum = 4ms, Mittelwert = 3ms
C:\Dokumente und Einstellungen\up>arp -a
Schnittstelle: 192.168.10.12 --- 0x2
Internetadresse Physikal. Adresse Typ
192.168.10.1 00-03-47-09-24-73 dynamisch
192.168.10.10 00-0e-35-60-5b-c9 dynamisch
len 74 src 00:0c:29:68:8a:bd dst 00:0e:35:60:5b:c9 IP src 192.168.10.12 dst 192.168.10.10 ICMP ping request
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.10 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.10 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0c:29:68:8a:bd dst 00:0e:35:60:5b:c9 IP src 192.168.10.12 dst 192.168.10.10 ICMP ping request
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.10 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.10 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0c:29:68:8a:bd dst 00:0e:35:60:5b:c9 IP src 192.168.10.12 dst 192.168.10.10 ICMP ping request
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.10 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.10 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0c:29:68:8a:bd dst 00:0e:35:60:5b:c9 IP src 192.168.10.12 dst 192.168.10.10 ICMP ping request
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.10 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.10 dst 192.168.10.12 ICMP ping reply
Step 3: ping guest -> wireless AP
=================================
Pinging the first off-host hop also works, but again there are two answer packets generated. Take a close look at the src MAC addresses of the reply packets in the vnetsniffer output below: the first reply seems to come from the right device (the AP at 00:12:17:70:90:c7), but the second seems to originate from the VMware host itself (MAC 00:0e:35:60:5b:c9)!?
Where is that second packet coming from? Is it generated by the bridging logic? Why? Sniffing on the host with Ethereal/Wireshark also shows the duplicate packets (and their different originating MAC addresses)
C:\Dokumente und Einstellungen\up>ping 192.168.10.250
Ping wird ausgefhrt fr 192.168.10.250 mit 32 Bytes Daten:
Antwort von 192.168.10.250: Bytes=32 Zeit=53ms TTL=64
Antwort von 192.168.10.250: Bytes=32 Zeit=41ms TTL=64
Antwort von 192.168.10.250: Bytes=32 Zeit=83ms TTL=64
Antwort von 192.168.10.250: Bytes=32 Zeit=102ms TTL=64
Ping-Statistik fr 192.168.10.250:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 41ms, Maximum = 102ms, Mittelwert = 69ms
C:\Dokumente und Einstellungen\up>arp -a
Schnittstelle: 192.168.10.12 --- 0x2
Internetadresse Physikal. Adresse Typ
192.168.10.1 00-03-47-09-24-73 dynamisch
192.168.10.10 00-0e-35-60-5b-c9 dynamisch
192.168.10.250 00-12-17-70-90-c7 dynamisch
len 60 src 00:0c:29:68:8a:bd dst ff:ff:ff:ff:ff:ff ARP sender 00:0c:29:68:8a:bd 192.168.10.12 target 00:00:00:00:00:00 192.168.10.250 ARP request
len 42 src 00:12:17:70:90:c7 dst 00:0c:29:68:8a:bd ARP sender 00:12:17:70:90:c7 192.168.10.250 target 00:0c:29:68:8a:bd 192.168.10.12 ARP reply
len 74 src 00:0c:29:68:8a:bd dst 00:12:17:70:90:c7 IP src 192.168.10.12 dst 192.168.10.250 ICMP ping request
len 74 src 00:12:17:70:90:c7 dst 00:0c:29:68:8a:bd IP src 192.168.10.250 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.250 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0c:29:68:8a:bd dst 00:12:17:70:90:c7 IP src 192.168.10.12 dst 192.168.10.250 ICMP ping request
len 74 src 00:12:17:70:90:c7 dst 00:0c:29:68:8a:bd IP src 192.168.10.250 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.250 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0c:29:68:8a:bd dst 00:12:17:70:90:c7 IP src 192.168.10.12 dst 192.168.10.250 ICMP ping request
len 74 src 00:12:17:70:90:c7 dst 00:0c:29:68:8a:bd IP src 192.168.10.250 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.250 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0c:29:68:8a:bd dst 00:12:17:70:90:c7 IP src 192.168.10.12 dst 192.168.10.250 ICMP ping request
len 74 src 00:12:17:70:90:c7 dst 00:0c:29:68:8a:bd IP src 192.168.10.250 dst 192.168.10.12 ICMP ping reply
len 74 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.250 dst 192.168.10.12 ICMP ping reply
Step 4: ping guest -> linux server
==================================
The packets make it to the server but are rejected by the firewall there because they arrive with the wrong MAC address (the pairs
"guest VM IP 192.168.10.12 - guest VM MAC 00:0c:29:68:8a:bd" and
"host IP 192.168.10.10 - host MAC 00:0e:35:60:5b:c9"
are allowed, but not the seen combination of
"guest VM IP 192.168.10.12 - host MAC 00:0e:35:60:5b:c9"
Below is an excerpt from the linux server's firewall log showing the rejection - which account for the "ICMP unknown type 3" packets in the vnetsniffer output. Note that also those rejects appear twice (again once from the real source and once from the host's MAC address)
C:\Dokumente und Einstellungen\up>ping 192.168.10.1
Ping wird ausgefhrt fr 192.168.10.1 mit 32 Bytes Daten:
Antwort von 192.168.10.1: Zielanschluss nicht erreichbar.
Antwort von 192.168.10.1: Zielanschluss nicht erreichbar.
Antwort von 192.168.10.1: Zielanschluss nicht erreichbar.
Antwort von 192.168.10.1: Zielanschluss nicht erreichbar.
Ping-Statistik fr 192.168.10.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
C:\Dokumente und Einstellungen\up>arp -a
Schnittstelle: 192.168.10.12 --- 0x2
Internetadresse Physikal. Adresse Typ
192.168.10.1 00-03-47-09-24-73 dynamisch
len 60 src 00:0c:29:68:8a:bd dst ff:ff:ff:ff:ff:ff ARP sender 00:0c:29:68:8a:bd 192.168.10.12 target 00:00:00:00:00:00 192.168.10.1 ARP request
len 60 src 00:03:47:09:24:73 dst 00:0c:29:68:8a:bd ARP sender 00:03:47:09:24:73 192.168.10.1 target 00:0c:29:68:8a:bd 192.168.10.12 ARP reply
len 74 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping request
len 102 src 00:03:47:09:24:73 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP unknown type 3
len 102 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP unknown type 3
len 74 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping request
len 102 src 00:03:47:09:24:73 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP unknown type 3
len 102 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP unknown type 3
len 74 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping request
len 102 src 00:03:47:09:24:73 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP unknown type 3
len 102 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP unknown type 3
len 74 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping request
len 102 src 00:03:47:09:24:73 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP unknown type 3
len 102 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP unknown type 3
Feb 25 18:01:52 calvin kernel: Shorewall:eth0_mac:REJECT:IN=eth0 OUT= MAC=00:03:47:09:24:73:00:0e:35:60:5b:c9:08:00 SRC=192.168.10.12 DST=192.168.10.1 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=1099 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=28160
Feb 25 18:01:53 calvin kernel: Shorewall:eth0_mac:REJECT:IN=eth0 OUT= MAC=00:03:47:09:24:73:00:0e:35:60:5b:c9:08:00 SRC=192.168.10.12 DST=192.168.10.1 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=1100 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=28416
Feb 25 18:01:54 calvin kernel: Shorewall:eth0_mac:REJECT:IN=eth0 OUT= MAC=00:03:47:09:24:73:00:0e:35:60:5b:c9:08:00 SRC=192.168.10.12 DST=192.168.10.1 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=1101 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=28672
Feb 25 18:01:55 calvin kernel: Shorewall:eth0_mac:REJECT:IN=eth0 OUT= MAC=00:03:47:09:24:73:00:0e:35:60:5b:c9:08:00 SRC=192.168.10.12 DST=192.168.10.1 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=1102 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=28928
Step 5: ping guest -> linux server
==================================
This works somewhat - somewhat because the ping request packets leave the linux server only once (as tcpdump shows), but are also duplicated on the VMware host and therefore two replies are generated and sent to the linux server (which points out this fact as can be seen below). The ARP cache shows that both the host and guest VM IP address are associated to the same MAC address (just like proxy-arp'ing took place)
calvin:/home/up# ping -c 4 192.168.10.12
PING 192.168.10.12 (192.168.10.12) from 192.168.10.1 : 56(84) bytes of data.
64 bytes from 192.168.10.12: icmp_seq=1 ttl=128 time=3.00 ms
64 bytes from 192.168.10.12: icmp_seq=1 ttl=128 time=3.41 ms (DUP!)
64 bytes from 192.168.10.12: icmp_seq=2 ttl=128 time=3.78 ms
64 bytes from 192.168.10.12: icmp_seq=2 ttl=128 time=3.95 ms (DUP!)
64 bytes from 192.168.10.12: icmp_seq=3 ttl=128 time=4.33 ms
64 bytes from 192.168.10.12: icmp_seq=3 ttl=128 time=4.49 ms (DUP!)
64 bytes from 192.168.10.12: icmp_seq=4 ttl=128 time=1.74 ms
\--- 192.168.10.12 ping statistics ---
4 packets transmitted, 4 received, +3 duplicates, 0% loss, time 3027ms
rtt min/avg/max/mdev = 1.748/3.532/4.493/0.871 ms
linux:/home/up# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.10.12 ether 00:0E:35:60:5B:C9 C eth0
192.168.10.10 ether 00:0E:35:60:5B:C9 C eth0
192.168.10.20 ether 00:11:09:C0:06:8D C eth0
len 98 src 00:03:47:09:24:73 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP ping request
len 98 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP ping request
len 98 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping reply
len 98 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping reply
len 98 src 00:03:47:09:24:73 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP ping request
len 98 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP ping request
len 98 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping reply
len 98 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping reply
len 98 src 00:03:47:09:24:73 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP ping request
len 98 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP ping request
len 98 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping reply
len 98 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping reply
len 98 src 00:03:47:09:24:73 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP ping request
len 98 src 00:0e:35:60:5b:c9 dst 00:0c:29:68:8a:bd IP src 192.168.10.1 dst 192.168.10.12 ICMP ping request
len 98 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping reply
len 98 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 IP src 192.168.10.12 dst 192.168.10.1 ICMP ping reply
Step 6: ARP requests seem not to be handled correcty
====================================================
Once you let vnetsniffer run for some time you can observe that the linux server tries to refresh its arp cache by requesting the MAC address for the guest VM's IP address. It therefore tries to direct its ARP request atfirst directly to the MAC address that was associated before but does not seem to get an answer (because it tries 3 times); only after that it falls back to broadcasting the ARP request, which both reaches the guest VM and makes it send a response.
Why is such a behaviour seen? If the VMware bridging algorithm really does some sort of proxy-arping (as the previous steps suggest) shouldn't it handle those ARP requests for one if its VMs better?
len 60 src 00:03:47:09:24:73 dst 00:0e:35:60:5b:c9 ARP sender 00:03:47:09:24:73 192.168.10.1 target 00:00:00:00:00:00 192.168.10.12 ARP request
len 60 src 00:03:47:09:24:73 dst 00:0e:35:60:5b:c9 ARP sender 00:03:47:09:24:73 192.168.10.1 target 00:00:00:00:00:00 192.168.10.12 ARP request
len 60 src 00:03:47:09:24:73 dst 00:0e:35:60:5b:c9 ARP sender 00:03:47:09:24:73 192.168.10.1 target 00:00:00:00:00:00 192.168.10.12 ARP request
len 60 src 00:03:47:09:24:73 dst ff:ff:ff:ff:ff:ff ARP sender 00:03:47:09:24:73 192.168.10.1 target 00:00:00:00:00:00 192.168.10.12 ARP request
len 60 src 00:0c:29:68:8a:bd dst 00:03:47:09:24:73 ARP sender 00:0c:29:68:8a:bd 192.168.10.12 target 00:03:47:09:24:73 192.168.10.1 ARP reply
So far for the tests I did. As petr pointed out in http://www.vmware.com/community/thread.jspa?forumID=19&threadID=14320&messageID=149023#149023 there is something different with bridging to wireless NICs, but I don't quite understand what and why. Where does the restriction come from?
\- technical reason within bridging algorithm - I can't imagine this
\- problems with wireless NIC drivers not allowing/passing on packets with foreign MACs? If so, why is it not made public (so that people know and driver manufacturers can fix this)
\- problems with wireless APs/MAC address filtering? This would also not be VMware's problem as long as people would know which hardware is needed and how is is to be configured to make it work
Also http://kb.vmware.com/kb/760 says nothing special about such things as long as the windows side is concerned (assuming VMware Server is the same "generation" as WS 5.x).
If this is not strange enough already, I am very positive (although not 100% sure) that this setup worked some time in the past with Workstation 4.5.1. The specific guest VM was installed quite a while ago and it once had internet access (which means: could connect to the linux server, which is the internet gateway). Since then unfortunately a lot of things changed on the laptop: Microsoft security updates, upgraded to WS 4.5.2, upgraded the WLAN drivers ... Installation of VMware Server was in fact my last hope that the problem could be solved by reinstalling the VMware software (in doesn't work with WS 4.5.2 either - haven't investigated so deep though).
To sum it up here are my questions:
1) Has this strange behaviour something to do with my laptop, its installation and/or configuration (and thus is no general phenomenon)?
2) Is bridging to a wireless NIC (on windows) only supposed to work the way I experience it? If so why isn't there anything mentioned in any documentation that bridging onto a wireless NIC isn't actually bridging what you think it would be? Or did I miss something?
3) somewhat off-topic: is sniffing on the Windows VMware host with Ethereal/Wireshark going to give you correct results when it comes to troubleshooting such problems (where is the capture driver located in the drivers stack with regard to the VMware bridging stuff)?
Any help with this is greatly appreciated!
Thanks for your (remarkable) patience anyway if you made it here