It's not possible to run server software on GitHub Actions using regular methods: the worker virtual machine is placed behind Network Address Translation (NAT), which prevents it from receiving direct inbound TCP/UDP connections.
This repository consists of GitHub Actions jobs for OpenVPN and WireGuard VPN servers which traverse NAT, making possible to establish VPN connection to the Actions worker machine directly, without any additional tunnel, third-party service, or port forwarding software.
This is a step-by-step, thoroughly documented practical UDP NAT traversal showcase using GitHub Actions with OpenVPN/WireGuard servers as an example, with only stock software from Ubuntu repositories.
NAT used on GitHub Actions is one of the most common ones: it's not the friendliest and not the ugliest.
Independent Mapping, Port Dependent Filter, random port, will hairpin
Once you learn the traversal principle used in this repository, you'll understand the general idea behind any modern NAT traversal implementation.
It is assumed that you run Linux.
- Fork this repository and clone your fork
- Place your SSH public key into
authorized_keysfile, git commit it - Make sure you have
stun-clientby hanpfei installed (apt install stun-clienton Debian/Ubuntu,dnf install stunon Fedora), as well asopenvpnand/orwireguard - Run
./run.sh openvpnfor OpenVPN server or./run.sh wireguardfor WireGuard server - Navigate to Actions tab of your repository, open corresponding job and check either
Print OpenVPN connection stringorPrint WireGuard configuration filefor VPN connection instructions - Connect to the VPN using the instructions from the Action
- After connecting to the VPN, run
ssh [email protected]to connect to your Actions worker
NOTE: your IP address will be visible in the commit history for everyone. Set the repository as private if you find this inappropriate for your threat model.
The Action jobs (openvpn, wireguard) in this repository:
- Wait for a specific commit message with IP address and port of the client
- Set up OpenVPN UDP/WireGuard server behind Actions worker NAT
- Determine external IP address and NAT port mapping for VPN port using STUN client
- Punch NAT with empty UDP packet every 28 seconds towards client's IP address and port from the VPN server port using
npinguntil the client is connected
The client-side run.sh script:
- Checks for NAT type on the client
- Determines mapped external source port using STUN
- git commits & pushes client's external IP address and mapped port discovered with STUN, as well as local source port to include it in configuration files and one-liners generated by the Actions job
- Keeps NAT mapping alive for non-port-preserving NATs
Yes, it bypasses NAT for UDP traffic of GitHub Actions worker running on Microsoft Azure infrastructure behind NAT of the following type:
Independent Mapping, Port Dependent Filter, random port, will hairpin
You will be able to connect to WireGuard/OpenVPN server running on your Actions worker directly, which is not possible otherwise.
Yes, you can connect to it if you're behind the most common NAT with "Independent Mapping" characteristics, either port-preserving or non-port-preserving (random port).
run.sh script will do everything for you, including NAT type identification.
The cone/port-restricted/symmetric NAT nomenclature is a bit outdated and does not describe all the NAT types found on the real Internet precisely.
Actions worker is placed after port-restricted NAT (which also does not preserve the source port).
For NAT type identification, refer to RFC4787 and RFC5128
The Actions workflow files (jobs) has detailed comments for each step, read it for openvpn and wireguard
General NAT traversal information:
Even more detailed writeup, covering all NAT aspects, will follow later.