VMware Communities
asdasd123qd
Contributor
Contributor
Jump to solution

Share host VPN with guest

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!

49 Replies
AlishaMahajan
Contributor
Contributor
Jump to solution

@Longstag I am facing similar issue with CiscoAnyConnect. These commands didn't work for me either. No luck.

Reply
0 Kudos
PimpaDev
Contributor
Contributor
Jump to solution

@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. 🙁

Reply
0 Kudos
gskluzacek
Contributor
Contributor
Jump to solution

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?

Reply
0 Kudos
sys7em-adam
Contributor
Contributor
Jump to solution

I wrote a python3 script that will build and apply a config to accept NAT to all utun/VPN interfaces.

Can be found at:

https://gitlab.com/-/snippets/2043124

tinkerer13
Contributor
Contributor
Jump to solution

Does your script make there permanent or do we run it every time we need to make a connection?

Reply
0 Kudos
slgarwood
Enthusiast
Enthusiast
Jump to solution

Apple in Big Sur has mucked around with VPN support - maybe that's impacting you.

Reply
0 Kudos
sergiohl1324
Contributor
Contributor
Jump to solution

It´s work for me !!! Thanks ! Any option to make this change persistent ?

Reply
0 Kudos
tinkerer13
Contributor
Contributor
Jump to solution

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.

Reply
0 Kudos
GregB84
Contributor
Contributor
Jump to solution

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.

Reply
0 Kudos
sergiohl1324
Contributor
Contributor
Jump to solution

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 !

Reply
0 Kudos
PimpaDev
Contributor
Contributor
Jump to solution

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!

Reply
0 Kudos
lefiii
Contributor
Contributor
Jump to solution

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 😞

Reply
0 Kudos
digitalpollen
Contributor
Contributor
Jump to solution

My set up so far:

  • Host: macOS Big Sur
  • Hypervisor: VMWare Fusion 12.1.0
  • Guest: Ubuntu 20.04.1
  • VPN Client: Cisco AnyConnect 4.9.04053
  • VM Connectivity without VPN on host: yes
  • VM connectivity with VPN on host: for IPV4 only. Does not work for IPV6

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.

    1. Set up static IP for VPN free connection
      1. Turn off VPN
      2. Settings -> Network -> Wired -> Cog icon -> IPv4
      3. Manual 
        1. Adresses
          1. Adress: 192.168.83.128 - Static IP
          2. Netmask: 255.255.255.0
          3. Gateway: 192.168.83.1
          4. Even Gateway: 192.168.83.0 works - vmnet3 (The new network interface)’s subnet IP
        2. DNS
          1. 192.168.83.0
          2. 8.8.8.8
          3. 8.8.4.4
          4. 1.1.1.1
        3. Leave IPV6 as automatic and leave the defaults be
    2. Set up static IP for VPN connection in another wired network profile
      1. Adresses
        1. Adress: 192.168.83.128 - Static IP
        2. Netmask: 255.255.255.0
        3. Gateway: <VPN-> Statistics-> Address information -> Client (IPV4) value>
      2. DNS
        1. 192.168.83.0
        2. 8.8.8.8
        3. 8.8.4.4
        4. 1.1.1.1
      3. IPV6? I used to be able to see the IPV6 client on the AnyConnect statistics window. It is showing as not available now. I tried setting a static IPV6 address but I don't know how to provide a gateway with this custom network interface and AnyConnect not showing IPV6 client. How do I configure this? I understand I have to update the gateways every time Cisco resets the session. I'll live. I want it to just work ATM. Any help or pointers are appreciated.
Reply
0 Kudos
DavidGriffiths
Contributor
Contributor
Jump to solution

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.

digitalpollen
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
swinder0161
Contributor
Contributor
Jump to solution

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.

jboles_cmu
Contributor
Contributor
Jump to solution

nifty script - curious why does it call reset_pfctl function 5 times between 1s delays?

Reply
0 Kudos
swinder0161
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
rsemov
VMware Employee
VMware Employee
Jump to solution

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.

Reply
0 Kudos
PeterWhittaker
Contributor
Contributor
Jump to solution

@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:

  1. With the VPN disconnected, run ifconfig > vpnOff
  2. With the VPN connected, run ifconfig > vpnOn
  3. diff vpnOff vpnOn

The output of the diff will be the VPN device: Use that in @PimpaDev 's procedure.

Reply
0 Kudos