VPN for your server
Home / Self Hosting / VPN for your server
23 Jul 2024
Here’s some links that helped me get this working:
- https://blog.lambda.cx/posts/openbsd-wireguard-vpn-gateway/
- Make sure the edge firewall on the provider side allows UDP packets from the server IP and port 51820
Key detail is: We then have to rewrite it into OpenBSD’s hostname.if(5) format. We’ll call it /etc/hostname.wg0 to create a Wireguard interface and execute the following commands when it’s created.
Some notes here
route -T <rtable> exec <program>
# vi /etc/hostname.wg0
inet 10.2.0.1/32 wgkey PRIVATEKEY wgpeer PUBLICKEY wgaip 0.0.0.0/0 wgendpoint 123.123.123.123 51820 !route -T 1 add -inet default 10.2.0.2
# vi /etc/pf.conf
pass in quick proto udp from 123.123.123.123 port 51820 to $ip_primary pass out quick proto udp from $ip_primary to 123.123.123.123 port 51820
Be sure that only the desired traffic is allowed on the wg0
interface as usual in pf.conf
23 Jul 2024
Some additional informative links
What if you have a dedicated server with a static IP address but don’t want to expose it when the server needs to contact other servers?
Perhaps you have invidious running and don’t want your IP address to be exposed. Or you are running continuous integration and deployment which requires fetching packages from third party servers.
I don’t like it that building a go binary by defaults contact’s google servers to fetch the dependencies. I also don’t need to advertise to the local routers and exchanges that the server is contacting (or not contacting!) update servers for a particular OS at particular times.
Or perhaps you have several servers with different providers and you want to avoid exposing the direct connection between them.
For this situation, we can use wireguard with proton vpn
Our network providers will know that we are contact proton servers, but won’t know what is being communicated (though guesses can be made based on side channels such as bandwidth usage and timing). Proton server naturally can see all our traffic since VPN is a man-in-the-middle, but they promise not to log it. Even if we don’t fully trust them, their alleged third party audit is perhaps a better bet than making direct connections on known (or highly-suspected) tapped lines.
No matter what, someone has to direct our connections to their destination. In this case, proton is acting as our ISP. And even if the “privacy” of the connection is no different materially, at least we have the ability to rotate outgoing IP addresses. This in itself is good enough motivation.