Hi,
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.
Thanks!
@Longstag I am facing similar issue with CiscoAnyConnect. These commands didn't work for me either. No luck.
@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
Fusion 12.1.0
guest os Ubuntu 18.0.4
kubectl 1.18.5
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?
I wrote a python3 script that will build and apply a config to accept NAT to all utun/VPN interfaces.
Can be found at:
Does your script make there permanent or do we run it every time we need to make a connection?
Apple in Big Sur has mucked around with VPN support - maybe that's impacting you.
It´s work for me !!! Thanks ! Any option to make this change persistent ?
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.
Exactly the same issue, it was working (the workaround provided by PimpaDev) , then it's not working with macOS BigSur upgrade 11.1 :'( Considering switching of product.
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 !
Hi all!
@GregB84 , @tinkerer13 I’m also using Big Sur 11.1 and the workaround still works. Nothing major changed in this area as I know.
@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
open shell
cd VMWareFusionVMNETMonitor
./install.sh
this will ensure that utun rules are added whenever virtual machine is started or resumed.
nifty script - curious why does it call reset_pfctl function 5 times between 1s delays?
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
I use GlobalProtect VPN on my Mac.
Since most of my traffic from the Linux VM -> Mac -> GlobalProtect is HTTP/HTTPs traffic I did two things to work around the issue, considering I don't want to run another GlobalProtect on my linux virtual machine:
1. installed Squid proxy on my mac and for better security, bound it to the NAT interface (172.16.211.*)
2. Installed the FoxyProxy Firefox Addon on my Linux VM browser and created a pattern/regex that tells it to only send requests with wildcard hostnames to the proxy (e.g. *.i-work-here.com). That ensures company-sourced URL's go through the proxy (i.e. the resources that otherwise fail to load because they don't get routed to the VPN) and everything else goes out directly.
If there's need for non-HTTP/s traffic to go through the VPN, then there's other solutions you can use like sshuttle and/or iptables on the VM to hack around the limitation
Unfortunately, this is the best solution for now, none of the NAT'ting rules listed by others above worked for me.
In the meantime we can sit tight and keep fingers crossed that a Vmware Fusion fix comes out quick.
@PimpaDev Your suggestion worked beautifully (and was much simpler than installing OpenVPN on all my VMs, as other posters had suggested).
FYI, for those looking to identify which interface is the VPN (I could not tell by inspection of ifconfig output), try this procedure:
The output of the diff will be the VPN device: Use that in @PimpaDev 's procedure.