Set up a personal VPN in the cloud
Find a file
Dan Guido f668af22d0
Fix VPN routing on multi-homed systems by specifying output interface (#14826)
* Fix VPN routing by adding output interface to NAT rules

The NAT rules were missing the output interface specification (-o eth0),
which caused routing failures on multi-homed systems (servers with multiple
network interfaces). Without specifying the output interface, packets might
not be NAT'd correctly.

Changes:
- Added -o {{ ansible_default_ipv4['interface'] }} to all NAT rules
- Updated both IPv4 and IPv6 templates
- Updated tests to verify output interface is present
- Added ansible_default_ipv4/ipv6 to test fixtures

This fixes the issue where VPN clients could connect but not route traffic
to the internet on servers with multiple network interfaces (like DigitalOcean
droplets with private networking enabled).

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Fix VPN routing by adding output interface to NAT rules

On multi-homed systems (servers with multiple network interfaces or multiple IPs
on one interface), MASQUERADE rules need to specify which interface to use for
NAT. Without the output interface specification, packets may not be routed correctly.

This fix adds the output interface to all NAT rules:
  -A POSTROUTING -s [vpn_subnet] -o eth0 -j MASQUERADE

Changes:
- Modified roles/common/templates/rules.v4.j2 to include output interface
- Modified roles/common/templates/rules.v6.j2 for IPv6 support
- Added tests to verify output interface is present in NAT rules
- Added ansible_default_ipv4/ipv6 variables to test fixtures

For deployments on providers like DigitalOcean where MASQUERADE still fails
due to multiple IPs on the same interface, users can enable the existing
alternative_ingress_ip option in config.cfg to use explicit SNAT.

Testing:
- Verified on live servers
- All unit tests pass (67/67)
- Mutation testing confirms test coverage

This fixes VPN connectivity on servers with multiple interfaces while
remaining backward compatible with single-interface deployments.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Fix dnscrypt-proxy not listening on VPN service IPs

Problem: dnscrypt-proxy on Ubuntu uses systemd socket activation by default,
which overrides the configured listen_addresses in dnscrypt-proxy.toml.
The socket only listens on 127.0.2.1:53, preventing VPN clients from
resolving DNS queries through the configured service IPs.

Solution: Disable and mask the dnscrypt-proxy.socket unit to allow
dnscrypt-proxy to bind directly to the VPN service IPs specified in
its configuration file.

This fixes DNS resolution for VPN clients on Ubuntu 20.04+ systems.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Apply Python linting and formatting

- Run ruff check --fix to fix linting issues
- Run ruff format to ensure consistent formatting
- All tests still pass after formatting changes

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Restrict DNS access to VPN clients only

Security fix: The firewall rule for DNS was accepting traffic from any
source (0.0.0.0/0) to the local DNS resolver. While the service IP is
on the loopback interface (which normally isn't routable externally),
this could be a security risk if misconfigured.

Changed firewall rules to only accept DNS traffic from VPN subnets:
- INPUT rule now includes -s {{ subnets }} to restrict source IPs
- Applied to both IPv4 and IPv6 rules
- Added test to verify DNS is properly restricted

This ensures the DNS resolver is only accessible to connected VPN
clients, not the entire internet.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Fix dnscrypt-proxy service startup with masked socket

Problem: dnscrypt-proxy.service has a dependency on dnscrypt-proxy.socket
through the TriggeredBy directive. When we mask the socket before starting
the service, systemd fails with "Unit dnscrypt-proxy.socket is masked."

Solution:
1. Override the service to remove socket dependency (TriggeredBy=)
2. Reload systemd daemon immediately after override changes
3. Start the service (which now doesn't require the socket)
4. Only then disable and mask the socket

This ensures dnscrypt-proxy can bind directly to the configured IPs
without socket activation, while preventing the socket from being
re-enabled by package updates.

Changes:
- Added TriggeredBy= override to remove socket dependency
- Added explicit daemon reload after service overrides
- Moved socket masking to after service start in main.yml
- Fixed YAML formatting issues

Testing: Deployment now succeeds with dnscrypt-proxy binding to VPN IPs

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Fix dnscrypt-proxy by not masking the socket

Problem: Masking dnscrypt-proxy.socket prevents the service from starting
because the service has Requires=dnscrypt-proxy.socket dependency.

Solution: Simply stop and disable the socket without masking it. This
prevents socket activation while allowing the service to start and bind
directly to the configured IPs.

Changes:
- Removed socket masking (just disable it)
- Moved socket disabling before service start
- Removed invalid systemd directives from override

Testing: Confirmed dnscrypt-proxy now listens on VPN service IPs

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Use systemd socket activation properly for dnscrypt-proxy

Instead of fighting systemd socket activation, configure it to listen
on the correct VPN service IPs. This is more systemd-native and reliable.

Changes:
- Create socket override to listen on VPN IPs instead of localhost
- Clear default listeners and add VPN service IPs
- Use empty listen_addresses in dnscrypt-proxy.toml for socket activation
- Keep socket enabled and let systemd manage the activation
- Add handler for restarting socket when config changes

Benefits:
- Works WITH systemd instead of against it
- Survives package updates better
- No dependency conflicts
- More reliable service management

This approach is cleaner than disabling socket activation entirely and
ensures dnscrypt-proxy is accessible to VPN clients on the correct IPs.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Document debugging lessons learned in CLAUDE.md

Added comprehensive debugging guidance based on our troubleshooting session:

- VPN connectivity troubleshooting order (DNS first!)
- systemd socket activation best practices
- Common deployment failures and solutions
- Time wasters to avoid (lessons learned the hard way)
- Multi-homed system considerations
- Testing notes for DigitalOcean

These additions will help future debugging sessions avoid the same
rabbit holes and focus on the most likely issues first.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Fix DNS resolution for VPN clients by enabling route_localnet

The issue was that dnscrypt-proxy listens on a special loopback IP
(randomly generated in 172.16.0.0/12 range) which wasn't accessible
from VPN clients. This fix:

1. Enables net.ipv4.conf.all.route_localnet sysctl to allow routing
   to loopback IPs from other interfaces
2. Ensures dnscrypt-proxy socket is properly restarted when its
   configuration changes
3. Adds proper handler flushing after socket configuration updates

This allows VPN clients to reach the DNS resolver at the local_service_ip
address configured on the loopback interface.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Improve security by using interface-specific route_localnet

Instead of enabling route_localnet globally (net.ipv4.conf.all.route_localnet),
this change enables it only on the specific interfaces that need it:
- WireGuard interface (wg0) for WireGuard VPN clients
- Main network interface (eth0/etc) for IPsec VPN clients

This minimizes the security impact by restricting loopback routing to only
the VPN interfaces, preventing other interfaces from being able to route
to loopback addresses.

The interface-specific approach provides the same functionality (allowing
VPN clients to reach the DNS resolver on the local_service_ip) while
reducing the potential attack surface.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Revert to global route_localnet to fix deployment failure

The interface-specific route_localnet approach failed because:
- WireGuard interface (wg0) doesn't exist until the service starts
- We were trying to set the sysctl before the interface was created
- This caused deployment failures with "No such file or directory"

Reverting to the global setting (net.ipv4.conf.all.route_localnet=1) because:
- It always works regardless of interface creation timing
- VPN users are trusted (they have our credentials)
- Firewall rules still restrict access to only port 53
- The security benefit of interface-specific settings is minimal
- The added complexity isn't worth the marginal security improvement

This ensures reliable deployments while maintaining the DNS resolution fix.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Fix dnscrypt-proxy socket restart and remove problematic BPF hardening

Two important fixes:

1. Fix dnscrypt-proxy socket not restarting with new configuration
   - The socket wasn't properly restarting when its override config changed
   - This caused DNS to listen on wrong IP (127.0.2.1 instead of local_service_ip)
   - Now directly restart the socket when configuration changes
   - Add explicit daemon reload before restarting

2. Remove BPF JIT hardening that causes deployment errors
   - The net.core.bpf_jit_enable sysctl isn't available on all kernels
   - It was causing "Invalid argument" errors during deployment
   - This was optional security hardening with minimal benefit
   - Removing it eliminates deployment errors for most users

These fixes ensure reliable DNS resolution for VPN clients and clean
deployments without error messages.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* Update CLAUDE.md with comprehensive debugging lessons learned

Based on our extensive debugging session, this update adds critical documentation:

## DNS Architecture and Troubleshooting
- Explained the local_service_ip design and why it requires route_localnet
- Added detailed DNS debugging methodology with exact steps in order
- Documented systemd socket activation complexities and common mistakes
- Added specific commands to verify DNS is working correctly

## Architectural Decisions
- Added new section explaining trade-offs in Algo's design choices
- Documented why local_service_ip uses loopback instead of alternatives
- Explained iptables-legacy vs iptables-nft backend choice

## Enhanced Debugging Guidance
- Expanded troubleshooting with exact commands and expected outputs
- Added warnings about configuration changes that need restarts
- Documented socket activation override requirements in detail
- Added common pitfalls like interface-specific sysctls

## Time Wasters Section
- Added new lessons learned from this debugging session
- Interface-specific route_localnet (fails before interface exists)
- DNAT for loopback addresses (doesn't work)
- BPF JIT hardening (causes errors on many kernels)

This documentation will help future maintainers avoid the same debugging
rabbit holes and understand why things are designed the way they are.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>
2025-08-17 22:12:23 -04:00
.github Bump actions/checkout from 4 to 5 (#14819) 2025-08-16 02:53:17 -04:00
configs ECDSA fixed 2016-07-24 14:44:59 +03:00
docs fix: Prevent sensitive information from being logged (#14779) 2025-08-17 15:58:19 -04:00
files/cloud-init feat: Add comprehensive performance optimizations to reduce deployment time by 30-60% 2025-08-03 16:42:17 -07:00
library Fix VPN routing on multi-homed systems by specifying output interface (#14826) 2025-08-17 22:12:23 -04:00
playbooks Fix AWS Lightsail deployment error (boto3 parameter) (#14823) 2025-08-16 03:39:00 -04:00
roles Fix VPN routing on multi-homed systems by specifying output interface (#14826) 2025-08-17 22:12:23 -04:00
scripts Fix VPN routing on multi-homed systems by specifying output interface (#14826) 2025-08-17 22:12:23 -04:00
tests Fix VPN routing on multi-homed systems by specifying output interface (#14826) 2025-08-17 22:12:23 -04:00
.ansible-lint Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
.dockerignore Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
.gitignore Fix AWS Lightsail deployment error (boto3 parameter) (#14823) 2025-08-16 03:39:00 -04:00
.yamllint fix: Prevent sensitive information from being logged (#14779) 2025-08-17 15:58:19 -04:00
algo Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
algo-docker.sh chore: Conservative dependency updates for Jinja2 security fix (#14792) 2025-08-03 07:45:26 -04:00
algo-showenv.sh Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
algo.ps1 Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
ansible.cfg feat: Add comprehensive performance optimizations to reduce deployment time by 30-60% 2025-08-03 16:42:17 -07:00
CLAUDE.md Fix VPN routing on multi-homed systems by specifying output interface (#14826) 2025-08-17 22:12:23 -04:00
cloud.yml Ansible upgrade 6.1 (#14500) 2022-07-30 15:01:24 +03:00
CODEOWNERS Add CODEOWNERS file (#14599) 2023-07-25 14:55:28 +03:00
config.cfg fix: Prevent sensitive information from being logged (#14779) 2025-08-17 15:58:19 -04:00
CONTRIBUTING.md Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
deploy_client.yml Ansible upgrade 6.1 (#14500) 2022-07-30 15:01:24 +03:00
Dockerfile Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
input.yml Fix AWS Lightsail deployment error (boto3 parameter) (#14823) 2025-08-16 03:39:00 -04:00
install.sh Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
inventory Refactor to support Ansible 2.8 (#1549) 2019-09-28 08:10:20 +08:00
LICENSE AGPLv3 change (#1351) 2019-03-17 11:19:24 -04:00
logo.png Closes #82, again 2017-02-07 16:35:23 -05:00
main.yml Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
PULL_REQUEST_TEMPLATE.md Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
pyproject.toml Bump ansible from 11.8.0 to 11.9.0 (#14821) 2025-08-16 02:53:39 -04:00
README.md fix: Prevent sensitive information from being logged (#14779) 2025-08-17 15:58:19 -04:00
requirements.yml Implement self-bootstrapping uv setup to resolve issue #14776 (#14814) 2025-08-06 22:10:56 -07:00
SECURITY.md Create SECURITY.md (#14669) 2023-12-12 19:17:59 +03:00
server.yml fix: Prevent sensitive information from being logged (#14779) 2025-08-17 15:58:19 -04:00
users.yml Fix AWS Lightsail deployment error (boto3 parameter) (#14823) 2025-08-16 03:39:00 -04:00
uv.lock Fix AWS Lightsail deployment error (boto3 parameter) (#14823) 2025-08-16 03:39:00 -04:00

Algo VPN

Twitter

Algo VPN is a set of Ansible scripts that simplify the setup of a personal WireGuard and IPsec VPN. It uses the most secure defaults available and works with common cloud providers.

See our release announcement for more information.

Features

  • Supports only IKEv2 with strong crypto (AES-GCM, SHA2, and P-256) for iOS, MacOS, and Linux
  • Supports WireGuard for all of the above, in addition to Android and Windows 11
  • Generates .conf files and QR codes for iOS, macOS, Android, and Windows WireGuard clients
  • Generates Apple profiles to auto-configure iOS and macOS devices for IPsec - no client software required
  • Includes helper scripts to add, remove, and manage users
  • Blocks ads with a local DNS resolver (optional)
  • Sets up limited SSH users for tunneling traffic (optional)
  • Privacy-focused with minimal logging, automatic log rotation, and configurable privacy enhancements
  • Based on Ubuntu 22.04 LTS with automatic security updates
  • Installs to DigitalOcean, Amazon Lightsail, Amazon EC2, Vultr, Microsoft Azure, Google Compute Engine, Scaleway, OpenStack, CloudStack, Hetzner Cloud, Linode, or your own Ubuntu server (for advanced users)

Anti-features

  • Does not support legacy cipher suites or protocols like L2TP, IKEv1, or RSA
  • Does not install Tor, OpenVPN, or other risky servers
  • Does not depend on the security of TLS
  • Does not claim to provide anonymity or censorship avoidance
  • Does not claim to protect you from the FSB, MSS, DGSE, or FSM

Deploy the Algo Server

The easiest way to get an Algo server running is to run it on your local system or from Google Cloud Shell and let it set up a new virtual machine in the cloud for you.

  1. Setup an account on a cloud hosting provider. Algo supports DigitalOcean (most user friendly), Amazon Lightsail, Amazon EC2, Vultr, Microsoft Azure, Google Compute Engine, Scaleway, DreamCompute, Linode other OpenStack-based cloud hosting, Exoscale or other CloudStack-based cloud hosting, or Hetzner Cloud.

  2. Get a copy of Algo. The Algo scripts will be run from your local system. There are two ways to get a copy:

    • Download the ZIP file. Unzip the file to create a directory named algo-master containing the Algo scripts.

    • Use git clone to create a directory named algo containing the Algo scripts:

      git clone https://github.com/trailofbits/algo.git
      
  3. Set your configuration options. Open config.cfg in your favorite text editor. Specify the users you want to create in the users list. Create a unique user for each device you plan to connect to your VPN. You should also review the other options before deployment, as changing your mind about them later may require you to deploy a brand new server.

  4. Start the deployment. Return to your terminal. In the Algo directory, run the appropriate script for your platform:

    macOS/Linux:

    ./algo
    

    Windows:

    .\algo.ps1
    

    The first time you run the script, it will automatically install the required Python environment (Python 3.11+). On subsequent runs, it starts immediately and works on all platforms (macOS, Linux, Windows via WSL). The Windows PowerShell script automatically uses WSL when needed, since Ansible requires a Unix-like environment. There are several optional features available, none of which are required for a fully functional VPN server. These optional features are described in the deployment documentation.

That's it! You can now set up clients to connect to your VPN. Proceed to Configure the VPN Clients below.

    "#                          Congratulations!                            #"
    "#                     Your Algo server is running.                     #"
    "#    Config files and certificates are in the ./configs/ directory.    #"
    "#              Go to https://whoer.net/ after connecting               #"
    "#        and ensure that all your traffic passes through the VPN.      #"
    "#                     Local DNS resolver 172.16.0.1                    #"
    "#        The p12 and SSH keys password for new users is XXXXXXXX       #"
    "#        The CA key password is XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX       #"
    "#      Shell access: ssh -F configs/<server_ip>/ssh_config <hostname>  #"

Configure the VPN Clients

Certificates and configuration files that users will need are placed in the configs directory. Make sure to secure these files since many contain private keys. All files are saved under a subdirectory named with the IP address of your new Algo VPN server.

Important for IPsec users: If you want to add or delete users later, you must select yes at the Do you want to retain the keys (PKI)? prompt during the server deployment. This preserves the certificate authority needed for user management.

Apple

WireGuard is used to provide VPN services on Apple devices. Algo generates a WireGuard configuration file, wireguard/<username>.conf, and a QR code, wireguard/<username>.png, for each user defined in config.cfg.

On iOS, install the WireGuard app from the iOS App Store. Then, use the WireGuard app to scan the QR code or AirDrop the configuration file to the device.

On macOS, install the WireGuard app from the Mac App Store. WireGuard will appear in the menu bar once you run the app. Click on the WireGuard icon, choose Import tunnel(s) from file..., then select the appropriate WireGuard configuration file.

On either iOS or macOS, you can enable "Connect on Demand" and/or exclude certain trusted Wi-Fi networks (such as your home or work) by editing the tunnel configuration in the WireGuard app. (Algo can't do this automatically for you.)

If you prefer to use the built-in IPsec VPN on Apple devices, or need "Connect on Demand" or excluded Wi-Fi networks automatically configured, see the Apple IPsec client setup guide for detailed configuration instructions.

Android

WireGuard is used to provide VPN services on Android. Install the WireGuard VPN Client. Import the corresponding wireguard/<name>.conf file to your device, then set up a new connection with it. See the Android setup guide for detailed installation and configuration instructions.

Windows

WireGuard is used to provide VPN services on Windows. Algo generates a WireGuard configuration file, wireguard/<username>.conf, for each user defined in config.cfg.

Install the WireGuard VPN Client. Import the generated wireguard/<username>.conf file to your device, then set up a new connection with it. See the Windows setup instructions for more detailed walkthrough and troubleshooting.

Linux

Linux clients can use either WireGuard or IPsec:

WireGuard: WireGuard works great with Linux clients. See the Linux WireGuard setup guide for step-by-step instructions on configuring WireGuard on Ubuntu and other distributions.

IPsec: For strongSwan IPsec clients (including OpenWrt, Ubuntu Server, and other distributions), see the Linux IPsec setup guide for detailed configuration instructions.

OpenWrt

For OpenWrt routers using WireGuard, see the OpenWrt WireGuard setup guide for router-specific configuration instructions.

Other Devices

For devices not covered above or manual configuration, you'll need specific certificate and configuration files. The files you need depend on your device platform and VPN protocol (WireGuard or IPsec).

  • ipsec/manual/cacert.pem: CA Certificate
  • ipsec/manual/.p12: User Certificate and Private Key (in PKCS#12 format)
  • ipsec/manual/.conf: strongSwan client configuration
  • ipsec/manual/.secrets: strongSwan client configuration
  • ipsec/apple/.mobileconfig: Apple Profile
  • wireguard/.conf: WireGuard configuration profile
  • wireguard/.png: WireGuard configuration QR code

Setup an SSH Tunnel

If you turned on the optional SSH tunneling role, local user accounts will be created for each user in config.cfg, and SSH authorized_key files for them will be in the configs directory (user.pem). SSH user accounts do not have shell access, cannot authenticate with a password, and only have limited tunneling options (e.g., ssh -N is required). This ensures that SSH users have the least access required to set up a tunnel and can perform no other actions on the Algo server.

Use the example command below to start an SSH tunnel by replacing <user> and <ip> with your own. Once the tunnel is set up, you can configure a browser or other application to use 127.0.0.1:1080 as a SOCKS proxy to route traffic through the Algo server:

ssh -D 127.0.0.1:1080 -f -q -C -N <user>@algo -i configs/<ip>/ssh-tunnel/<user>.pem -F configs/<ip>/ssh_config

SSH into Algo Server

Your Algo server is configured for key-only SSH access for administrative purposes. Open the Terminal app, cd into the algo-master directory where you originally downloaded Algo, and then use the command listed on the success message:

ssh -F configs/<ip>/ssh_config <hostname>

where <ip> is the IP address of your Algo server. If you find yourself regularly logging into the server, it will be useful to load your Algo SSH key automatically. Add the following snippet to the bottom of ~/.bash_profile to add it to your shell environment permanently:

ssh-add ~/.ssh/algo > /dev/null 2>&1

Alternatively, you can choose to include the generated configuration for any Algo servers created into your SSH config. Edit the file ~/.ssh/config to include this directive at the top:

Include <algodirectory>/configs/*/ssh_config

where <algodirectory> is the directory where you cloned Algo.

Adding or Removing Users

Algo makes it easy to add or remove users from your VPN server after initial deployment.

For IPsec users: You must have selected yes at the Do you want to retain the keys (PKI)? prompt during the initial server deployment. This preserves the certificate authority needed for user management. You should also save the p12 and CA key passwords shown during deployment, as they're only displayed once.

To add or remove users, first edit the users list in your config.cfg file. Add new usernames or remove existing ones as needed. Then navigate to the algo directory in your terminal and run:

macOS/Linux:

./algo update-users

Windows:

.\algo.ps1 update-users

After the process completes, new configuration files will be generated in the configs directory for any new users. The Algo VPN server will be updated to contain only the users listed in the config.cfg file. Removed users will no longer be able to connect, and new users will have fresh certificates and configuration files ready for use.

Privacy and Logging

Algo takes a pragmatic approach to privacy. By default, we minimize logging while maintaining enough information for security and troubleshooting.

What IS logged by default:

  • System security events (failed SSH attempts, firewall blocks, system updates)
  • Kernel messages and boot diagnostics (with reduced verbosity)
  • WireGuard client state (visible via sudo wg - shows last endpoint and handshake time)
  • Basic service status (service starts/stops/errors)
  • All logs automatically rotate and delete after 7 days

Privacy is controlled by two main settings in config.cfg:

  • strongswan_log_level: -1 - Controls StrongSwan connection logging (-1 = disabled, 2 = debug)
  • privacy_enhancements_enabled: true - Master switch for log rotation, history clearing, log filtering, and cleanup

To enable full debugging when troubleshooting, set both strongswan_log_level: 2 and privacy_enhancements_enabled: false. This will capture detailed connection logs and disable all privacy features. Remember to revert these changes after debugging.

After deployment, verify your privacy settings:

ssh -F configs/<server_ip>/ssh_config <hostname>
sudo /usr/local/bin/privacy-monitor.sh

Perfect privacy is impossible with any VPN solution. Your cloud provider sees and logs network traffic metadata regardless of your server configuration. And of course, your ISP knows you're connecting to a VPN server, even if they can't see what you're doing through it.

For the highest level of privacy, treat your Algo servers as disposable. Spin up a new instance when you need it, use it for your specific purpose, then destroy it completely. The ephemeral nature of cloud infrastructure can be a privacy feature if you use it intentionally.

Additional Documentation

Setup Instructions for Specific Cloud Providers

Install and Deploy from Common Platforms

Setup VPN Clients to Connect to the Server

  • Setup Windows clients
  • Setup Android clients
  • Setup Linux clients with Ansible
  • Setup Ubuntu clients to use WireGuard
  • Setup Linux clients to use IPsec
  • Setup Apple devices to use IPsec
  • Setup Macs running macOS 10.13 or older to use WireGuard

Advanced Deployment

If you've read all the documentation and have further questions, create a new discussion.

Endorsements

I've been ranting about the sorry state of VPN svcs for so long, probably about time to give a proper talk on the subject. TL;DR: use Algo.

-- Kenn White

Before picking a VPN provider/app, make sure you do some research https://research.csiro.au/ng/wp-content/uploads/sites/106/2016/08/paper-1.pdf ... or consider Algo

-- The Register

Algo is really easy and secure.

-- the grugq

I played around with Algo VPN, a set of scripts that let you set up a VPN in the cloud in very little time, even if you dont know much about development. Ive got to say that I was quite impressed with Trail of Bits approach.

-- Romain Dillet for TechCrunch

If youre uncomfortable shelling out the cash to an anonymous, random VPN provider, this is the best solution.

-- Thorin Klosowski for Lifehacker

Support Algo VPN

PayPal Patreon

All donations support continued development. Thanks!

  • We accept donations via PayPal and Patreon.
  • Use our referral code when you sign up to Digital Ocean for a $10 credit.
  • We also accept and appreciate contributions of new code and bugfixes via Github Pull Requests.

Algo is licensed and distributed under the AGPLv3. If you want to distribute a closed-source modification or service based on Algo, then please consider purchasing an exception . As with the methods above, this will help support continued development.