Quick VPN Setup with AWS Lightsail and WireGuard
mcoliver.substack.com
mcoliver.substack.com
The big advantage offered by many of the VPN vendors this article looks down on is the fact they can give you a residential IP in the target country - this can be a vast quality of life improvement for many browsing scenarios.
~5-6 years ago a self-hosted VPN exit node in AWS worked so much better than today in my experience, so many services have since added IP range blocks. This really matters for the common use case of trying to access TV streaming services in other countries, as one example.
I still run a private WireGuard setup at home to take advantage of my personal residential IP, but that's only good for content in my home country naturally - still handy when traveling, or to get more secure access on public wifi.
Another benefit is that your traffic can be pooled with other users coming from an exit IP which can be useful (as opposed from a single endpoint you control as I wrote about in this article). Tradeoffs.
The cloud provider may have a less favorable privacy policy.
If you need access to regional services, a common VPN use case and one outlined in the original article, its the single most important factor.
This is almost always not true.
There are "residential" VPN providers, but they are scammy AF. The only way to get access to a true residential IP is via some proxy/gateway software run by a customer of a real home ISP. These are usually obtained via botnets of infected PCs.
Users of residential VPNs are usually using them to scrape sites which try to prevent scraping and so are probably happy to turn a blind eye to where they get their IPs from.
They're also much more expensive then traditional VPNs.
This was a huge controversy not long ago. The biggest issue I see from it is that it opens the user up to a fair amount of legal liability for what other users of the VPN service do while connected to the VPN service. If the user failed to understand what they agreed to in installing the VPN service and agreeing to it then it can make for some very awkward conversations when law enforcement comes knocking.
As a cybersecurity person I also think users fail to understand what information they are potentially making available to some rando running the VPN software on their PC. I can (and have before) see any traffic that you are sending through that VPN, and potentially tamper with that traffic. If you thought Nord or PIA could not be trusted with your traffic then how do you feel about Joe Random being able to see and tamper with your traffic?
If you read my statement, "they can give you a residential IP in the target country" - I never said this was universal.
Some private VPN companies will offer you a residential IP or dedicated IP, sometimes for additional fee - I'm paying for such a service right now. I perhaps should have broadened statement to "dedicated IP" etc, but it remains true you can get a far more "useable" IP from some private VPN providers.
One such example - and I know from my own testing this dedicated IP has far fewer issues with region locked content such as the BBC iPlayer or Netflix, where as almost every IP AWS has assigned me, including elastic IPs, has been blocked in the last few years:
˜ https://nordvpn.com/features/dedicated-ip/
Same thing, different vendor:
- https://www.privateinternetaccess.com/vpn-features/dedicated...
And another...
- https://surfshark.com/dedicated-ip
etc etc
In this instance consider the SBC a lightweight, low-power, always on server sitting behind his/her router.
You can split the tunnel based on IP routing, but I think that's as good as it gets. So if you want to Wireguard specific traffic to your peer then you're fine. For instance, we have our internal cloud network linked to our offices via wireguard, but traffic to anything that is not that network goes to the public Internet via our fiber.
But if we wanted to send HTTP requests always through the WG, that is not possible to configure because WG acts as an L3 VPN and Layer 3 has no conception of anything but the network. You couldn't say "Send HTTP requests through my normal fiber, but DNS requests through my VPS peer".
I would strongly recommend switching from iptables to nftables -- drastically reduces wtfs/minute metric during the configuration.
If you'd like -- I can send you the relevant parts of the firewall settings with some comments. My email is in the profile.
Or you could post a link to a GitHub "gist" of a "sanitized" version of it it, so other random folks (like me; it sounds interesting / useful) can also benefit from it without you havin' to email it to a zillion random people. ;~)
The problem you’re trying to solve is basically one of routing. You have a packet leaving your phone to the internet, and you want it to route it through the VPS, from VPS to SBC, SBC to your home router, then out to the internet. Start from one end and figure out each step.
From your phone, you basically just need your wireguard config to specify 0.0.0.0/0 in the allowed IPs. That will specify that all traffic should go to the peer. So that’s the easy part down.
Next is you need your VPS to route all traffic out through the tunnel to your SBC. You’ll need to enable IP forwarding, then you’ll need to set up the routes to accomplish this. You can’t just globally route 0.0.0.0/0 otherwise your VPS will no longer be connectable. All the traffic coming in via the wireguard interface from your phone will need to be marked via iptables’ fwmark to use a separate routing table (actually wireguard may do this by default…). So that table is where you’ll need to configure a route for 0.0.0.0/0 to your SBC as the next hop. Otherwise you just need to make sure you have allow rules in place on the forward chain to permit the packets to pass.
Once it hits your SBC, it gets easier. It needs IP forwarding enabled. Depending on whether you want to use double NAT or not you can do this a couple of ways. One is to set up masquerading/NAT and call it a day. The other is to, again, simply allow it to forward the packets along (passing them to your home router) and let your router handle the NAT.
The difference between the approaches will mostly play into how you set up all the reverse routes. As long as you can add routes to your home router, you can add a route for your wireguard range(s) to be routed through the SBC and it _should_ cooperate. If your router doesn’t allow you to set up routing like this, you’ll need to do the NAT on your SBC.
Then reverse route from SBC to VPS for wireguard range. (Can control this through the AllowedIPs in the wireguard config.) Your VPS shouldn’t need any extra work because it’s directly connected to your phone.
And you’re done! Maybe! Good luck!
One option would be to host the wg server on your SBC (guessing a raspi or something like it?) and make the VPS a peer thus routing everything out your home network. You can also use AllowedIPs to only route specific ranges on the wg network which allows other traffic to follow the route tables on that device and exit accordingly.
But if what you are asking is how do you have different peers on a wg network route their traffic out to the internet on various different peers you're going to need to get fancy with routes/iptables/virtual network interfaces/policy based routing using PostUp commands.
Hopefully that gives you something to go on.
Unsure if/how/why you want to modify firewalls and iptables.
If you're ok running ubuntu or debian, the commands for ufw as a firewall are pretty straight forward to setup and maintain and can be scriptable.
Algo is a nice install that works just fine installed as a docker image running on a linux VPS. Installing docker and docker-compose are essential for this.
If after reading this you are saying there is no comprehensive step by step article that does this, let me know, and I can see if I have my install notes and the install script I created to put up somewhere.
I think sometimes enough years of linux and looking things up can be at fault for some of the documentation needs.
https://www.procustodibus.com/blog/2022/06/multi-hop-wiregua...
I’m not a huge fan of the VPN operators, but there are real differences in the trust required with each.
Tor isn't much better, as security services have been able to gain enough control or surveillance ability to match traffic as it ingresses and egresses Tor, to then identify where the traffic originated from.
With enough of a tinfoil hat you can perpetually be paranoid and chasing "anonymity" for a long while. It's really about what you're trying to conceal and what effort you put in to securing the infrastructure at the beginning and end of an end-to-end encrypted session, as well as the level of security of the end-to-end encrypted session itself.
But be aware that the IP address may not be private in cloud instances.
Is it known to what extent the traffic is logged on AWS EC2 or Lightsail?
None! that's an enterprise feature, you'll have to contact sales for pricing
I thought some metadata is logged, at least for security or to fight abuse, but probably for more reasons. But I’m not sure.
If your government wants them, they’ll probably get them for free.
Which...those types of instances have their use. But the fact that AWS kind of hides the whole CPU credit thing in LightSail is a bit misleading.
More and more cloud providers look for and block vpn's self-hosted with vps providers, in which case, finding access to residential connections (trading) or a provider is a way to go.
Hetzner might be worth looking into but the cheapest isn’t always the best value.
Digital ocean should be avoided for all production uses
So, the phone wants to connect to a media server at home. In hub and spoke vpn, both connect to a vpn server. The problem is, the traffic decrypted on VPS. I want the packers from phone go to vps then to home, with end to end encryption. The VPS acts as a relay.
The connection between peers need not be direct (peer to peer). The traffic could go through the central hub if needed. I just don’t want the hub to access the decrypted traffic.
Tor is another, onion layers of tunnels.
But maybe there is an easy networking solution, like creating a route table on VPS implementing a relay or STUN server , that says traffic coming from the peers public key is exchanged on VPS server.
Https://vpn.democratize.cloud
You just run it on your server and it does most of things, including generating WireGuard keys for clients and showing QR codes.
Which sucks on 464xlat networks, as the proxy dies after a while making you lose incoming connections.
All you need is any ubuntu vps - in fact any systemd distro if you ignore the "ufw" commands - and the 50 or so lines following "Wireguard Setup".
It doesn't get more simple than this.
Just copy/paste them commands in any linux vps. You don't need aws, at least lightsail is cheap. Ionos (1&1) is cheaper.
You could totally use an Ansible playbook. I've used a lot of them over the years. Ansible, Terraform, Salt, Chef, Puppet, etc... As I said at the end of the article I glossed over a lot of things and the beauty of tech is there are lots of ways to do things. Do what works for you. Tradeoffs all over the place.
I do think that shell scripts provide lower level insight to people that may be trying to understand what is going on rather than the magic of something like Ansible that abstracts things away. Or maybe I'm just old school :D
But also one more dependancy.
More and more I'm finding having a bash script that can work on most debian/ubuntu systems is pretty handy to be able to run remotely whether it's a VPS or more.