WireGuard in CloudShell

Challenge accepted.

What is AWS CloudShell?

AWS CloudShell is a browser-based shell that makes it easier to securely manage, explore, and interact with your AWS resources.

That's straight from the product page. The more salient description, in my opinion, is that it's this button in the console (far left of the footer on every console page):

That's pretty prominent placement for an undersold feature. And let me just put it out there that if you aren't using CloudShell, you're missing out. It's automatically authenticated, can run in whatever region you need (that's super helpful for testing global systems).

But, that's not my point today. My goal is proving Google wrong, again.

What is WireGuard?

Wow. Where to start? If you haven't actually heard about it then I'm not sure this article is for you (just kidding).

WireGuard is a VPN technology (handshake and encryption, plus routing). In a nutshell, it allows secure bridging between two otherwise disconnected or only insecurely connected networks. It was the invention of one person. I was not that person.

You can read more about WireGuard all over the internet. Just don't trust AI about it.

Let's Make this Happen

First things first, Google doesn't even get the language right. There is no such thing as a "server" in WireGuard parlance -- it's all about peers. Peers talking to peers. Strike one, Google.

But the real questions here are "can it be installed?" and "does it work?"

CloudShell runs Amazon Linux, a distribution of its own. So the package manager may not even have it. Let's find out:

That's a "yes". Installed. Strike two, Google.

Let's try to configure it. First we need to generate a key pair for the CloudShell peer and find a public key for another peer to talk with, then we add them both to a configuration file under /etc/wireguard:

wg genkey > private.key
wg pubkey < private.key > public.key
cat demo.conf << EOF
[Interface]
PrivateKey = $(cat private.key)
Address = 192.168.4.219/24

[Peer]
PublicKey = ${EXTERNAL_WG_KEY}
Endpoint = ${EXTERNAL_WG_ENDPOINT}
AllowedIPs = 192.168.4.0/24
PersistentKeepalive = 25
EOF
sudo mv demo.conf /etc/wireguard/

You'll need to support your own EXTERNAL_WG_KEY and EXTERNAL_WG_ENDPOINT values for a public WireGuard endpoint. Or, you can skip all the above and use the demo script provided by the maintainers:

wget https://git.zx2c4.com/wireguard-tools/tree/contrib/ncat-client-server/client-quick.sh
chmod +x client-quick.sh
./client-quick.sh

Either way, once that's done if we can stand up the tunnel and see traffic moving it means WireGuard can run in CloudShell. So...

Dang it, is Google right? Nah. You'll see that error if you chose the client-quick.sh route above because it adds a DNS configuration block to the demo.conf file. We don't need that, and we can replace the demo.wireguard.com domain name with the IP address as well:

With that in place we can try again:

Promising. But is data being passed? Let's send a quick message through the tunnel and see if traffic flows:

echo "Hi!" > /dev/udp/192.168.4.11/1234
sudo wg

And there you have it, a working WireGuard tunnel in CloudShell. Strike three, Google, you're done.

The caveat is that this tunnel will only work as long as I'm using the CloudShell session. Once it goes idle, AWS shuts down the shell and the tunnel goes with it. On the plus side, all I have to do to get it back is run sudo wg-quick up demo.

Conclusion

Two things here:

1. Don't trust an LLM that says it can't be done. They are wrong about all the interesting things because they haven't yet been done (as far as they know, because they aren't in the training set).
2. CloudShell is awesome.