Perfect as Infrastructure

[reversevpn 4]

AirVPN's static ips and port forwarding can be leveraged to create site-to-site VPNs at a fraction of the cost of obtaining public ips from my ISP, which is great for me as a network admin. For those who are so inclined, you can combine nginx, flask, airvpn, and your choice of hardware to replace even VPS services as a backend for your apps. If you have high-speed internet, you will never find a VPS solution more cost-effective than AirVPN + your own hardware. As an added bonus, your services become somewhat shielded from DDoS attacks because you don't have to reveal your machine's physical IP, and you can use the 5 allowed sessions to perform multihoming and provide redundancy.

[benfitita 35]

Sure, if you accept the :port in URLs.

[OpenSourcerer 1361]

Something of a guide would be quite a boon for the community, I think.

[reversevpn 4]

Which part, the site-to-site VPN or AirVPN as app backend?

[benfitita 35]

Both are very interesting use cases.

[reversevpn 4]

A High-Level Guide to Both Use Cases (Ask if you need to go deeper down to implementation details):

Site-to-Site VPN:
Example Scenario: You have a head office whose LAN is 192.168.100.0/24, and you have a branch office whose LAN is 192.168.200.0/24. You want seamless IP routing between both offices, so that any machine on one LAN can access any machine on the other LAN.
1. Download an AirVPN Wireguard Config File for a server physically close to the head office.
2. Forward a random UDP port using AirVPN's port-forwarding menu, but remember what port it is. Let's call this port X.
3. Create a systemd-nspawn container on a machine on a Linux box in the head office.
4. Upload the wireguard config file from step 1 into the container in step 3.
5. Using iptables in the container, port-forward port X as-is from the container to the machine that the container is running on(iptables -t nat -A PREROUTING).
6. Also using iptables on the container, masquerade traffic coming from the host machine and exiting through the AirVPN wireguard interface, and vice-versa (iptables -t nat -A POSTROUTING (insert -i and -o directives here) -j MASQUERADE)
7. On the container, block all traffic that neither goes to/comes from the AirVPN server, nor is to/from port X, nor has been established yet.
8. On the host machine of the container in the headoffice, setup a listening wireguard process (configuration in /etc/wireguard) that listens on port x, has address 192.168.y.z, where y and z are arbitrary numbers between 0 and 255 that do not correspond to an existing IP address in either the head office or the branch office, and that has a peer for whom the allowed IPS are 192.168.y.w (y is the same y as you chose earlier, w is a number that causes 192.168.y.w as a whole to not be a currently used IP address ) and 192.168.200.0/24.
9. Appropriately setup routing rules on both the host machine that the container in the headoffice is running on, and the router in the head office, if the host machine of the container is not also the router.
10. On a Linux machine in the branch office, set up a wireguard process that has IP address 192.168.y.w and has a peer whose endpoint is a.b.c.d:X , whose AllowedIPs are 192.168.y.z and 192.168.100.0/24, whose PublicKey is a match for the private key of the wireguard process in step 8, and whose PersistentKeepalive is 10. a.b.c.d is the Exit Ipv4 address of the AirVPN server you picked in step 1. You can find this in the Sessions section of AirVPN's client area.
11. Appropriately set up routing rules on both the box that Wireguard is running on in the branch office, and the router of the branch office, if the machine that the wireguard process you created in step 10 is running on is not also the router of the branch office.
12. If you did everything right, the site-to-site VPN should now be fully operational.

AirVPN as app backend:
1. Follow steps 1-7 from the Site-to-Site VPN guide, except that the head office is now simply where you have your physical server, and you are now forwarding TCP instead of UDP on port X.
2. Change the host->container mtu to 1420, but leave the container->host mtu at 1500.
3. Install nginx on the host machine of the container in step 1.
4. For each HTTP endpoint that your app uses,  add a location/endpoint {} block in /etc/nginx/sites-enabled with a single proxy_pass directive to whatever process your backend is. For example, if you have a gunicorn server listening at 127.0.0.1:5000, then you should write proxy_pass http://127.0.0.1:5000/{name_of_endpoint}l in each endpoint's location block.
5. Set up SSL on the nginx server, so that traffic between your users is HTTPS. It's ok that the traffic between nginx and your backend is unencrypted HTTP, provided that both are running on the same machine and that you configured the backend to listen ONLY on the localhost interface. This completes the backend of your app.
6. In the frontend of your app(could be a PWA, Desktop app, Android App, or an iOS app; the point is that this is the part of your app that your users interact with), direct all http requests to a.b.c.d:X, where a.b.c.d is the exit address of the AirVPN server you chose, and X is the random port you chose. 
7. Test your app to verify that it is working as intended.

Interesting note: Provided that you ship your app as a native app(Desktop app, android app, or iOS app) instead of a PWA app, most of your users will never notice that you are using port X. The more technically inclined among them may find out using tcpdump or wireshark, but the vast majority will behave as though you hosted your backend on AWS or similar instead of hosting it on a machine sitting behind AirVPN. However, if you buy a 3-year plan from AirVPN during Halloween, you have probably by now both reduced your recurring cost to 20% of what it would have been had you gone with a modest VPS plan AND you now have unlimited egress/ingress traffic thanks to AirVPN's unlimited bandwidth policy.

In case you do not want a single point of failure but want several copies of the backend running in different places, you can have up to 5 backends(1 for each session AirVPN gives you) by repeating steps 1 to 4 for each copy of your backend. Just configure your frontend to randomly choose which backend to connect to, then choose a different one if the connection fails.

Note that this method is agnostic of what your application actually does. It could be a scheduling app, a turn-based game, an online store, or whatever you can imagine, except perhaps a real-time game where even single frames matter. The only drawback is the increased latency because of including the AirVPN server in the path between your users and your backend, but if your app is not latency-sensitive, or if your server is extremely, physically close to one of AirVPN's servers(think same city block), latency will not be a problem.

[benfitita 35]

Thank you for sharing the details. 

ad 1. Did you have to modify MTU for the head office - branch tunnel? It’s a tunnel in a tunnel setup. 

ad 2. It used to be possible to use CloudFlare as a proxy, so it should be possible to use standard HTTPS port. But you need to trust Cloudflare and this is another moving part in the whole setup. 

[reversevpn 4]

ad 1. In theory, yes. In practice, for some reason, this was not necessary. I was able to access the resources of the branch network even through a wireguard tunnel with an inner MTU of 1420 and an outer MTU of 1500 which passed through AirVPN's tunnel with an inner MTU of 1420 and an outer MTU of 1500. I think wireguard automatically adjusts its UDP packet size to correct for MTU issues. However, trying to send TCP traffic through a wireguard tunnel without decreasing the TCP traffic's MTU at some point before reaching the container connected to AirVPN's server via Wireguard is problematic. By problematic, I mean sites like microsoft.com and duckduckgo would fail to load.

ad.2. There is another way: Host the frontend on a commercial (or even free, as in Github pages or google sites) provider who offers to host just static sites (these providers will ask you to bundle up your site in a folder, then they just share what's in the folder), then just keep your backend behind AirVPN.  Of course, this means that you have to correctly configure CORS on the backend that you're keeping behind AirVPN. But still, this approach allows you to run powerful sites not limited by what your user's browsers can do at a fraction of the cost of a VPS. There is a reason that I called this AirVPN as App Backend instead of just AirVPN as app platform.