Interesting one. I'll try it out on my Parallels VM and see if I get the same results in my UniFi's client list. If the VM is getting an IP from your DHCP server, I suspect all is well with that. The question is, what's the modem-router unit you're using? Halloween Events In Sierra Vista Az on this page. I know Netgear have a security function (completely user configurable of course), which can block internet access to newly added devices until you add the device into the 'allowed devices' list. It's very likely this is what's causing you grief.

I've always used my Windows VM in shared mode, as I've never had a need to have it in the same subnet for anything I do but I'll certainly experiment with it and see what shows up in my UniFi's client list. So, I've done some homework, tweaked bits and pieces here and there, tried a few other things suggested by other users of Parallels on completely unrelated WiFi networks (i.e.

Not using Ubiquiti). I'm not a networking expert by any means but I know how to fix stuff, to a point, so bear with me here. When running a bridged network for a VM using a wired ethernet connection, it's pretty straightforward and it all works as intended. Unfortunately, WiFi connectivity seems to bring on a few complications which makes it less straightforward. Hopefully one of the UBNT gurus can shed some light on this if my theory at the end of all this is not entirely accurate.

So, I've done some homework, tweaked bits and pieces here and there, tried a few other things suggested by other users of Parallels on completely unrelated WiFi. Which networking mode (Bridged, Shared. The settings of this virtual subnet can be accessed from the Parallels Desktop Preferences >Network. Bridged: Wi-Fi. 3d Blocks For Autocad more.

What I found was that I could get an address assigned to my VM from the DHCP server (running on my Juniper router), just like you. It would receive all the DNS addresses as well. I could ping to all the devices on my LAN but with one exception - the router itself.

I tried pinging from the router to the VM but again, the same bad result. However, if I manually set the IP address in the WIndows VM along with the gateway, being the router's IP, then I could ping to my router. So then I proceeded to manually set the DNS IP addresses as well.

Lo and behold, the thing was working 100%! So is it the Windows DHCP client which is killing bridged connections? I don't think so.

If it did, it would have to kill bridged connections on wired ethernet as well. Is it the VM refusing to pass anything beyond the laptop's physical IP address?

I think there's more to it than just doing that but this is where I concluded the problem is likely to be. I'll go more into the theory I think could be behind this. Is it the UniFi AP refusing to route any traffic back to the gateway/router? I wouldn't think so because if it did, then manually setting the network configuration in the Windows VM shouldn't work either.

Is it the router? Well, I took a look through the DHCP server bindings and found the VM with the virtual MAC address were properly picked up and noted in the table. If it were the router at fault, then I would expect no DHCP client information would be issued to the VM. So while the workaround (setting the IP details manually) is good enough to get you going, it alone offers absolutely no explanation as to why that works but it fails with DHCP enabled. It's like there's something else being spat at it that it just doesn't like and it's keeping it out. At any rate, the quick and dirty workaround is, if you want to get access to the internet in bridged mode, it seems like this is the effective way to do it - set the IP address manually within the Windows VM (not the actual VM settings in Fusion). But if you want to fix it properly, well, here's what I discovered with my Parallels installation - using promiscuous mode is the fix.