• First, thanks for putting this together.

    Just a quick FYI, the script "as is" doesn't work for me. It just deletes the existing entries in the network table -- but I found a way to make it work, even if it's not "automagically" - see below:

    The error:

    What I mean, before running the script, as per the instructions in https://communities.vmware.com/t5/VMware-Fusion-Discussions/Share-host-VPN-with-guest/td-p/2301323/highlight/true I get:

     % sudo pfctl -a com.apple.internet-sharing/shared_v4 -s nat 2>/dev/null
    Password:
    nat on en0 inet from 172.16.220.0/24 to any -> (en0:0) extfilter ei
    nat on en8 inet from 172.16.220.0/24 to any -> (en8:0) extfilter ei
    no nat on bridge100 inet from 172.16.220.1 to 172.16.220.0/24

    Then I run ./update-nat.py and then the same command returns empty:

    % ./update-nat.py
    NAT rules updated!
    % sudo pfctl -a com.apple.internet-sharing/shared_v4 -s nat 2>/dev/null
    %

    So it appears to be doings something wrong at the moment of updating.

    The workaround:

    Exploring the options of the command, I found a way to leverage the script using `./update-nat.py -o, thanks!

    1. Make a backup of the rules (in case we mess it up!):

      % sudo pfctl -a com.apple.internet-sharing/shared_v4 -N -f newrules.conf 2>/dev/null

    2. Use the script to generate the rules that it would create automatically:

      ./update-nat.py -o > newrules.conf.upd

    3. Import the new rules, replacing the "old" ones:

      % sudo pfctl -a com.apple.internet-sharing/shared_v4 -N -f newrules.conf.upd

    The resulting set of rules allows the VM to access the systems on the VPN!!

    (I also believe that the newrules.conf.upd rule set generated instep 2, will probably the valid even after machine reboots - I mean, the rules look generic enough that would cover any VMs being booted up.. but I have't tried it, TBH)

    So thanks a million for putting this together!!

  • I also thank both Adam and Javier for all of this. I'd like to share my personal experience, with Big Sur 11.2.3 and Fusion 12.1.1. Once the new nat rules have been determined via the python script, I dumped them in a single file.

    It turned out that the command used to update the NAT rules for the tunnelling network interface had to be issued each and every time the virtual machine started.

    My hypothesis is: since I'm forced to use an internal virtual network between the host and the guest, such a network is created when the 1st VM is spun up, and is destroyed after the last VM is shut down, or at least recreated when I restart Fusion.

    Bottom line: for me, it is best to have a script that updates on demand the NAT rules.

  • If you are using macOS Big Sur, you should use the latest beta version of Tunnelblick. You should allow Tunnelblick to automatically check for updates on the "Preferences" panel of Tunnelblick's "VPN Details" window. Be sure to put a check in "Check for updates to beta versions". दो इंसानों को अलग करने का मंत्र

  • I got the python script working with the following changes:

    diff --git a/update-nat.py b/update-nat.py
    index 8c8ff12..72e4218 100644
    --- a/update-nat.py
    +++ b/update-nat.py
    @@ -88,14 +88,18 @@ if not args.u:
             if not args.i or tun in args.i:
                 NAT_CONFIG.append(f'nat on {tun} inet from {NETWORK} to any -> ({tun}) extfilter ei')
     
    -fh = tempfile.NamedTemporaryFile()
    +fh = tempfile.NamedTemporaryFile(delete=False)
     fh.write(('\n'.join(line for line in NAT_CONFIG)).encode('utf-8'))
    +fh.write('\n'.encode('utf-8'))
     
     if args.o:
         fh.seek(0)
         print(fh.read().decode('utf-8'))
    +    fh.close()
    +    os.unlink(fh.name)
         exit(0)
     
    +fh.close()
     r = subprocess.run(
         ['sudo', 'pfctl', '-a', 'com.apple.internet-sharing/shared_v4', '-N', '-f', fh.name],
         stdout=subprocess.PIPE,
    @@ -107,4 +111,4 @@ else:
         print('Error processing new rules:')
         print(r.stderr.decode('utf-8'))
     
    -fh.close()
    +os.unlink(fh.name)
  • @jjarava -- Thanks for the report, I forgot to flush() the temp file before loading it with pfctl, this is now fixed! Thanks for your report!

    @meiser79 -- Thanks for the report, adding the new line and flushing the file was needed, the source is updated to reflect this.

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment