I'm using VMware Fusion 12.0.0 (16880131) in macOS Big Sur Beta 10. In macOS (host), I'm connected to a VPN. I want to share the VPN connection with my Windows 10 2004 (guest), but this doesn't work. Internet connection is available but websites which are only available in VPN aren't. The guest network is connected via NAT. How can I archive the sharing or isn't this possible currently?
If you need any further information, please let me know.
@AlishaMahajan , @Longstag unfortunately I have no experience with CiscoAnyConnect, probably it do a different aproach to build up net network part of the VPN. Just installed F12.1.0 and for me the workaround is still working.
My only suggestion to hunt down the problem (but probably you've already done these or at least a part of these...):
1. stop any vpn, vm and check that the vm networking set to 'share with my mac'
2. start ciscoanyconnect vpn
3. start the vm
4. check the NAT rules -> should reset the sharing_v4 anchor so there's should be no any custom added part
5. check ifconfig for any unusual thing 🙂 -> ciscoanyconnect can build a different netinterface than utun or other bridge, than you should change the custom part of the solution
6. check 'netstat -rn -f inet' (this will print the routing table of ip4 addresses) -> to see every route you need is defined or just to see a big table of addresses 😀
7. in the VM check that you can reach the VPN local ip by pinging it (only the local ip could be reachd!) -> if you can't then there is something different than the "basic" case, so it needs an other workaround
8. ping anything from the vm and check 'sudo tcpdump -i bridge100' which gives you a clue about what trafic leaves the vm netinterface. -> should see the outgoing ping
9. ping a behing vpn adress from the vm and check 'sudo tcpdump -i <vpn interface>' which gives you a clue about what trafic goest to the vpn netinterface -> should see the incoming ping source address is the guest's private ip, which is 'wrong'
9. add the custom rule and check from the VM if it can reach anything other than the default routes -> for example: internet, if it's not routed through the VPN
10. check the same tcpdump command to see if anything is changed
Any part fails, or do something unusual, then probably the soulution won't work and need a different approach to make it work or hopefully vmware will found something for you soon. 🙁
This mostly worked for me....
I was able to ping the host in question which is behind our VPN, but when I went to try and use kubectl (kubernetes control cli) I got the following message:
Unable to connect to the server: net/http: TLS handshake timeout
running macOS 11.0.1 Big Sur
guest os Ubuntu 18.0.4
here's my updated rules that I applied on the Mac side (4th line is what I added)
nat on en1 inet from 192.168.2.0/24 to any -> (en1:0) extfilter ei nat on en0 inet from 192.168.2.0/24 to any -> (en0:0) extfilter ei no nat on bridge100 inet from 192.168.2.1 to 192.168.2.0/24 nat on utun2 inet from 192.168.2.0/24 to any -> (utun2) extfilter ei
And this is the new output when I run pfctl...
nat on en1 inet from 192.168.2.0/24 to any -> (en1:0) extfilter ei nat on en0 inet from 192.168.2.0/24 to any -> (en0:0) extfilter ei no nat on bridge100 inet from 192.168.2.1 to 192.168.2.0/24 nat on utun2 inet from 192.168.2.0/24 to any -> (utun2) round-robin extfilter ei
so it added the part with "round-robin" not sure if that matters.
it seems like something else from the VM is not getting passed to the nat ?
What can I do to assist in troubleshooting this?
The previous work around running the sudo commands worked before the Big Sur update two days ago. I'm on
macOS 11.0.1 (20B29) and it no longer works. I hope VMWare fixes this problem.
I have MacOS Big Sur 11.1 and for me still work :
My VPN is on ppp0:
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1354
inet 10.100.xxx.xxx --> 169.254.38.179 netmask 0xff000000
And file look like this:
nat on en0 inet from 172.16.79.0/24 to any -> (en0:0) extfilter ei
no nat on bridge100 inet from 172.16.79.1 to 172.16.79.0/24
nat on ppp0 inet from 172.16.79.0/24 to any -> (ppp0) extfilter ei
Thats work !
@sergiohl1324 Sorry, but as my knowledge this cannot be make permanent because this is reset every time you start a vm.
All this problem is not technically related to any of the parties (Big Sur, VMWare Fusion) because it is a result of the change of disallowing kext-s in Big Sur and forcing apps to use the packet filter subsystem of the os, which was existed long before Big Sur as well. Previously Fusion used kext to present vmnet interfaces (special network drivers) and it did the magic of NAT and firewall and so on. Now Big Sur “force” these apps to use the internal Internet Sharing feature which do the same (kind of). But in VMWare when you start up a vm it shares only the base interfaces (lan, wlan) and not the others. This is where VPN will be broken with shared network in the vm.
This hack/workaround is about to adding the missing interface(s) to the OS’ packet filtering subsystem to act the same as the base interfaces. So it is more about changing the OS behaviour, than Fusion’s itself. It should work as long as this behaviour does not change or any of the used probrams (VPN, Fusion, Big Sur) fundamentally not change. 🙂
Hopefully one time VMWare will do this on its own and you don’t have to change it manually. Probably Big Sur missing something... as probably Apple again half baked the final product, so Fusion’s team need to find a workaroud to this function and have a hot line with apple. 😉
So few key points as a remainder:
- this will work only after the vpn and the vm-s started (the vpn is a semi exception... but you need this to find out the vpn interface)
- you have to repeat this after every vm restart. After a vpn restart you only need to redo this if the utun interface changes.
- the workaournd is only masking the traffic from the vm interface to the specific utun interface so every part (source address, destination interface) have to be matched, otherwise it won’t work.
Hope it helps and you found what ‘couse the problem after BS 11.1 update. But if you post some information (ips,names masked, etc.) probably we can figure out what’s go wrong.
And happy holidays for everyone!
You can a BRIDGE configuration between the Mac and the VM. This has worked today for me even with VPN. The downfall is that my VM is not connected to where I'm connecting with VPN without NAT 😞
My set up so far:
Please someone help me figure this out for IPV6 with VPN connected on host!
I followed the instructions on https://kb.vmware.com/s/article/80793 to set up a network interface.
Thanks, had same problem, in my case Big Sur, Fusion 12 and Tunnelblick 3.8.4a (build 5601). Doing ifconfig listed three tun interfaces which confused me - utun0, utun1 and utun2 - but I just added all three as per the instructions and that worked.
We had to add 3 networks and enable them on our dev VM at a minimum - Shared with Mac, Private to Mac and bridged - autodetect to get our environment running on Fusion. I had to also delete my other connection profiles. We use docker, the outer internets and our VM needs to talk with other local VMs on the fusion subnet
Based on the recommendations in the comments to add pfctl rules, I have created a launchd plist and script to have it automated for vmware fusion
The package can be found here: https://github.com/swinder0161/VMWareFusionVMNETMonitor
this will ensure that utun rules are added whenever virtual machine is started or resumed.
I found that vmware takes some time to set its pfctl rules sometimes, so my rules were getting overwritten.
Just to make sure my rules get reflected, i did it 5 time, see no problem after that
with 2 seconds, it was not working.
3 secs was flacky
so I went with 5secs