Fairly off-topic, but I've been having the hardest time finding a Wireguard configuration guide that lets me connect two peers (my phone and an SBC at my house behind my router) to a VPS peer (with a public IP) in a way that routes all the traffic from my phone through the SBC (via WG) and out to the internet via my home fiber connection. All the blog posts and tutorials I've seen have traffic going out through the VPS peer, with little explanation of how all the firewall and iptables commands might change if I wanted a different configuration. Has anyone seen a configuration like that, or know which networking concepts I should keep searching for to go in the right direction?
Since you’re just asking for concepts I can take a probably wrong guess that might lead you to something useful with some googling. (I’ve done stuff like this a lot, but not lately and this is all from memory.)
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.
I have a vps as the wireguard "hub" with my phone, DNS and internal services being the spokes. I don't route traffic through home, but I do use home DNS as adblocker on the go. DNS also does the split horizon to route the phone to internal services over wg.
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.
> If you'd like -- I can send you the relevant parts of the firewall settings with some comments.
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. ;~)
Wireguard is L3, right? So it behaves like a network layer VPN. That means that you can't switch how traffic is flowing based on application protocol. But I'm not super familiar with VoIP stuff.
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'm not sure I fully understand your setup or what you are trying to accomplish so apologies beforehand if I misunderstand.
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.
Would something like AlgoVPN installed at the appropriate point in your hierarchy/network map simplify this?
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.
