Poor Man’s BeyondCorp with WireGuard

Stripped of all its complicated implementation details, the core BeyondCorp architecture looks like the following, where a user device on any public network is able to connect to a private internal web application through a BeyondCorp access proxy:

The access proxy terminates the TLS connection from the device. It uses the user and device credentials included as part of the underlying HTTP request to identify the user and device, and verifies with the BeyondCorp access control engine that the user and device is authorized to access the app. If so, it proxies the HTTP request to the back-end web-app server for the server to process and respond.

There’s a lot of special sauce that goes into the BeyondCorp access proxy and access control engine, as well as the user and device identification process. That special sauce, while powerful, makes a true BeyondCorp system difficult to implement.

A dumbed-down version of this with WireGuard and nftables would look like the following:

With this simplified architecture, HTTP requests from the device are tunneled through WireGuard to the WireGuard hub, and from the WireGuard hub to the app server. Devices are authenticated via their WireGuard key, and nftables access-control rules on the WireGuard hub reject requests from devices that have not been authorized for the app.

This gets you 80% of the benefits of BeyondCorp, but with 20% of the difficulty. Like BeyondCorp, it enables a user device anywhere in the world to connect securely to a private internal app. Unlike BeyondCorp, however, it authenticates and authorizes only devices, not users — it relies on the internal application itself for user authentication and authorization.

But a big advantage of this simplified version is that it can also be used with non-web applications — secure shell (SSH), remote desktop (RDP, VNC, etc), file shares (SMB, NFS, etc), mail (SMTP, IMAP, etc), voice over IP (SIP, RTP, etc), printing (LDP, IPP, etc), and so on — just as easily as it can be used with web apps. And you can still plug in whatever SSO (Single Sign-On) solution you might use with BeyondCorp into each individual application.

The original BeyondCorp paper identifies the following as the major steps for setting up a BeyondCorp architecture:

Here’s how each step compares to our simplified WireGuard and nftables implementation:

In this guide, we’ll set up WireGuard on all user devices (as well as back-end applications). Our WireGuard hub will use the public-key pair we generate on each device to securely identify the device.

While this is pretty good, it’s not as strong as the BeyondCorp vision, which calls for identifying devices via a key stored in the TPM (Trusted Platform Module) of the device (so the key can’t be stolen and used on an different device); plus using other device information (such as the device location or patch level) to derive a graduated level of trust for the device.

This is the main piece missing from our simplified BeyondCorp implementation — unlike a true BeyondCorp architecture, it does not attempt to identify, authenticate, and authorize the user who’s using the device. (But note that you could add user authentication via WireGuard MFA with Pro Custodibus.)

This guide will show you how to set up a host-based firewall with nftables on each application server (and user device) to block access to each host except through the WireGuard hub. While this is perfectly adequate, in a real implementation of this simplified BeyondCorp architecture (like with a full BeyondCorp architecture) you would usually also use network-level firewalls and segmentation.

Instead of implementing a protocol-aware proxy like a true BeyondCorp architecture, in this guide we’ll simply send all device-to-application traffic, internal and external, through a central WireGuard hub. WireGuard can handle any IP-based protocol (HTTP, SSH, RDP, SMB, etc), without having to be customized for the semantics of the protocol itself.

And unlike with a true BeyondCorp access proxy, where you’d use DNS hostnames for applications that resolve to the proxy’s own IP address, with this simplified BeyondCorp implementation, we’ll use the WireGuard IP address of each application server to access its hosted application. However, if you still want to use DNS names for your services, you can simply set up a private DNS server that resolves hostnames to WireGuard IP addresses (like to point mail.corp.example.com to the WireGuard IP address for the Mail Server in our example, 10.0.0.3).

In the grand BeyondCorp vision, this is where the magic happens: a specialized access control engine sorts through a multitude of user and device information, and evaluates a sophisticated set of access control policies to determine if a particular user is authorized to access a particular application from a particular device.

With our poor man’s BeyondCorp, we’ll just use some simple nftables rules on the WireGuard hub to define and enforce our inventory-based access control. WireGuard’s cryptokey routing system enables us to securely map devices to IP addresses; and with nftables it’s easy to set up rules to grant access through our WireGuard hub from each authorized device IP address to each application IP address (and deny all other access).

First, provision a Linux server for your WireGuard Hub, and install WireGuard on it. For our little example WireGuard network, you wouldn’t need a beefy server — something as small as a Raspberry Pi would be fine (but for a larger network, you’ll probably need a more capable server). Make sure the server’s WireGuard port is exposed to the Internet; in our example, this UDP port is 51821.

Generate a WireGuard public-key pair on the server, as described by the Generate WireGuard Keys section of the hub-and-spoke guide. Copy the public key to your server inventory. You’ll need it, plus the server’s public IP address and WireGuard port, to configure WireGuard on all the other spokes.

Decide what range of private IP addresses you want to use for your WireGuard network (see RFC 6890 for options). If all your devices and applications support IPv6, you can use IPv6 ranges; otherwise you’ll need to stick with IPv4. In this guide, we’ll mix all our applications and devices together in the 10.0.0.0/24 block — but you may want to group your various WireGuard peers into an orderly hierarchy of IP address blocks, with devices and applications (and other infrastructure) grouped into the roles for which they will be authorized (like say the devices used by the IT team in the 172.31.1.0/24 block, devices of the R&D team in the 172.31.2.0/24 block, devices of the Sales team in the 172.31.3.0/24 block, etc).

In your device/server inventory, assign a unique WireGuard IP address in the appropriate range to each device, application server, or other host that will be connected to this WireGuard network.

On each user device, install WireGuard, and generate a WireGuard key pair for it. This key pair is what’s used for Securely Identifying the Device in our simplified BeyondCorp architecture. Copy the public key to your device inventory.

Then set up a WireGuard config on each device similar to the Configure WireGuard for Endpoint A section of the hub-and-spoke guide. This is what we’d use for Bob’s Workstation:

In the [Interface] section of the config, put the private key you generated for the device in the PrivateKey field, and the WireGuard address you assigned to it in the Address field.

In the [Peer] section of the config, put the public key you generated for the WireGuard Hub in the PublicKey field, the public IP address and UDP port of the WireGuard Hub in the Endpoint field, and all the IP address ranges included in your WireGuard network in the AllowedIPs field.

On each user device, install nftables (or some other host-based firewall). Configure the firewall to deny all new inbound connections (while allowing established connections). With nftables, we’d simply use the base configuration from the nftables guide:

However, since our user devices will always be the initiator of new connections, and never the recipient, we don’t need the base configuration’s rules to accept new WireGuard or SSH connections — we’ve omitted them above.

On each application server, install WireGuard. Then generate a WireGuard key pair, and copy the public key to your server inventory.

Set up the WireGuard config on each server similar to the Configure WireGuard for Endpoint B section of the hub-and-spoke guide. This is what we’d use for the VNC Server:

In the [Interface] section of the config, put the private key you generated for the server in the PrivateKey field, the WireGuard address you assigned to the server in the Address field, and the public UDP port you want WireGuard to use on the server in the ListenPort field.

In the [Peer] section of the config, put the public key you generated for the WireGuard Hub in the PublicKey field, and all the IP address ranges included in your WireGuard network in the AllowedIPs field.

On each application server, install nftables (or some other host-based firewall). Configure the firewall to deny all new inbound connections except:

With nftables, we’d start with the base configuration from the nftables guide, and customize it for the server’s WireGuard port and application ports. For the VNC Server, we’d use this (where the VNC daemon is listening on TCP port 5900):

With our BeyondCorp architecture, we’re going to send all traffic, including SSH, through the WireGuard Hub, so we won’t include the rule from the base configuration that accepts new SSH connections on the public interface. Instead, with this configuration, we’re going to accept new SSH and other application-specific connections only through the WireGuard interface, via these two rules:

For convenience, we’ve defined the specific ports the application accepts at the top of the config file, with these two variables:

For the VNC Server, we expose only one port, TCP port 5900. On other servers, we’ll expose multiple ports — like on the Mail Server, we’ll expose TCP ports 22 (SSH), 25 (SMTP), and 143 (IMAP):

In this way we can use the same core configuration on each app server, and just plug in the custom server-specific values at the top of the config.

On the WireGuard Hub, set up its WireGuard config similar to the Configure WireGuard on Host C section of the hub-and-spoke guide. Make sure you add a [Peer] entry for each user device and application server (or other host) that you want to be part of the WireGuard network. With our example WireGuard network, it would look like this:

In the [Interface] section of the config, put the private key you generated for the WireGuard hub in the PrivateKey field, the WireGuard address you assigned to it in the Address field, and the public UDP port WireGuard will use on the hub in the ListenPort field.

To ensure that the hub has packet forwarding turned on, in this example we’ve also used a PreUp command in the [Interface] section to turn it on when the WireGuard interface is started up. If you’ve turned on packet forwarding elsewhere (like via /etc/sysctl.conf or a /etc/sysctl.d/ config file), you don’t need to do it here. If you’re using IPv6 addresses, make sure you set the IPv6 version of this property (net.ipv6.conf.all.forwarding) instead.

Configure one user device or application server in each [Peer] section, putting the device or server’s WireGuard public key in the PublicKey field, and WireGuard IP address in the AllowedIPs field.

Since our user devices will always be the initiator of WireGuard connections, we don’t need to include an Endpoint setting for them in their [Peer] sections. Our application servers will usually be the recipient of WireGuard connections, however, and not the initiator, so we do need to configure an Endpoint setting for each. Put the public IP address of the application server and its WireGuard port in the Endpoint setting for each app server.

WireGuard’s strict cryptokey routing system ensures that when the hub, with the above WireGuard config for example, sees a packet from 10.0.0.2 come in on its wg0 interface, it knows the packet’s source must have had access to the private key generated on Alice’s Workstation. This allows us to trust that the packet legitimately came from Alice’s Workstation (to the extent we trust that the private key never left her workstation).

With this guarantee in place, we only need a few basic nftables rules to accomplish Implementing Inventory-Based Access Control in our simplified BeyondCorp architecture. We’ll start with the hub configuration (“Host C”) from the nftables guide, and customize it with the Network ACLs we laid out above for our example network:

The “boilerplate” parts of this configuration are:

The “interesting” parts of the configuration are the inventory definitions at the top of the config:

And the access-control rules that use those definitions in the middle of the wg-forward chain:

The host definitions at the top of the config make the access-control rules easy to read — and notice how the rules line up neatly with the Network ACLs table laid out at the beginning of the Implementation section.

Without this nftables configuration, any user device on our WireGuard network would be able to access any application service; but with it in place, only authorized devices can access the applications for which they’ve been authorized.

In this example we don’t have any applications which use UDP; but if you do, you’ll need to add a second access-control rule section specifically for UDP ports. For example, if you added a NTP server with UDP port 123 exposed to your WireGuard network, you’d need to add the following below the TCP access-control rules to grant access to it from specific devices:

Start up WireGuard and nftables on your WireGuard Hub. On Linux with systemd, run the following commands:

To ensure that both start up on system boot, also run the following commands:

Do the same for all connected user devices and app servers.

Then try out the connections. From Alice’s Workstation, SSH into the WireGuard Hub:

SSH into the Mail Server:

Access the Web Server:

And so on. You should be able to access each application from each device that’s been granted access to the app through the hub’s access-control rules.

With port forwarding, you don’t have to make any WireGuard changes to any hosts — just apply the same App WireGuard Config to the WireGuard Spoke that you would otherwise apply to the app server itself.

You do need a different nftables configuration, however — one similar to the “Host β” configuration from the Point to Site With Port Forwarding section of the nftables guide (but with a few different details). For the VNC Server, we’d use this nftables config on its WireGuard spoke (to forward TCP port 5900 connections from the WireGuard spoke to the VNC Server at IP address 192.168.200.52 on the private subnet):

Unlike our standard App Nftables Config, here we don’t accept connections to the application’s ports in the input chain (we accept only SSH connections to the WireGuard Spoke itself, for remote administration). Instead, we add the following to the forward chain, to send incoming traffic from WireGuard to the site-forward chain for filtering:

And we set up this custom site-forward chain to accept connections to the application’s ports (much like we accept them in the input chain of the standard App Nftables Config):

If we fully trusted the WireGuard Hub, we could have alternatively just omitted the custom site-forward chain, and set up our forward chain like this:

The advantage of adding this extra filtering through our site-forward chain is that even if the WireGuard Hub is compromised (or misconfigured), only minimal access to the application server is exposed through the WireGuard Spoke.

The most important part of this nftables config, however, is actually the last part — the nat table with its prerouting and postrouting chains:

This is what does the actual port forwarding, with the prerouting chain using nftables DNAT (Destination Network Address Translation) rules to forward our configured ports (TCP port 5900 in this example) to the application server. The postrouting chain uses SNAT (Source Network Address Translation) to “masquerade” forwarded packets from the WireGuard network as if their source was from the WireGuard Spoke itself (so that the VNC Server will send replies back through the WireGuard Spoke).

One last configuration change we need to make on the WireGuard Spoke is to enable packet forwarding. The easiest way to do that is to add it as a PreUp command to the [Interface] section of the WireGuard config on the spoke:

With that in place, for the VNC Server in our example scenario, Alice will be able to access the VNC Server on her workstation using the WireGuard IP address of the WireGuard Spoke:

The WireGuard Spoke will transparently forward the VNC connection to the actual VNC Server, running at 192.168.200.52 on the private subnet it shares with the spoke.

As an alternative to using port forwarding, you could instead set up the WireGuard Spoke as a gateway from the app server on its private subnet (its local “site”) to the WireGuard network. With this approach, however, you do need to make some changes to your WireGuard configuration — both on the hub, and potentially on every other spoke as well.

With the site gateway approach, the app server’s IP address on the private subnet needs to be exposed to the rest of the WireGuard network, as part of the AllowedIPs configuration setting of each member in the network (although you can omit this IP address from the configuration of user devices and other app servers that don’t actually need to access the app server — but, of course, special-casing this on some devices and not others can quickly become a maintenance burden). If you need to use this approach for several servers on several different subnets, you may want to group all such subnets into a larger range of IP addresses (eg 192.168.192.0/20) that you can safely add as a single block to the AllowedIPs setting on all devices (as long as that range doesn’t collide with any other private network ranges that the devices may need to access).

Even with the additional subnet IP address (or addresses) exposed, the central WireGuard Hub will still control access from each individual user device to each individual app server — including the special-cased app server (or servers) — using the same nftables access-control rules as before. The only difference is that the access control rules will use the subnet IP address instead of WireGuard IP address for each special-cased app server.

For a concrete example, we’ll add a dedicated WireGuard server as a spoke in the VNC Server’s private subnet, making the following changes to our standard BeyondCorp configuration: