reversevpn

But if I select a bigger MTU than what you have server-side, won't the effective MTU of the applications running in the tunnel still be constrained to the server MTU?

Why is the MTU on files generated from AirVPN's config generator just 1320 instead of the normal 1420 for Wireguard? Not saying that this is a bad thing, but just curious.

What OS are you using?

Just use the config generator in AirVPN's client area, then use the official WireGuard client at wireguard.com

It's also possible that systemd-resolved is installed but not enabled. Try sudo systemctl enable --now systemd-resolved before taking the DNS directive from the wireguard file. Source: https://bugzilla.redhat.com/show_bug.cgi?id=1732487

Did you install systemd-resolved yet? If not, do so and try again. If you already have, then just erase the DNS= line from the America.conf file, and manually change /etc/resolv.conf to 10.128.0.1 after the America interface has been raised if you wish to use airvpn's DNS. Alternatively, if you have your own DNS server like dnsmasq and want it to query airvpn's DNS, edit /etc/dnsmasq.conf and add a server=10.128.0.1 directive to it.

If the above failed, try installing systemd-resolved using sudo dnf install systemd-resolved, then try raising the interface using the systemctl method again

Try copying the file to /etc/wireguard and doing sudo systemctl start wg-quick@wg . This should bypass freedesktop and enable you to raise the interface. You can replace "wg" in systemctl start wg-quick@wg with whatever name your config file is. I use wg because your file is named wg.conf, but I do recommend renaming it after the airvpn server you are using, or some other nickname you have for it, like america. So, try copying it as america.conf into /etc/wireguard, then doing systemctl start wg-quick@america. If it fails, do systemctl status wg-quick@america and show the logs here

Go here using AirVPN website, ensure both machines have a different key, and reconnect one of your machines(I suggest reconnecting the remote machine) under a different key. If it still doesn't work, disconnect both sides from AirVPN, wait 5 minutes, and reconnect on both sides, ensuring that you selected a different key on both sides even before you start a connection.

Go to client area-> VPN Devices->Manage, then add a second device for your remote machine. Make sure to select that new key when using Eddie on the remote device, or, if you're using the config generator, choose the new key when generating the config

Did you make sure that the two machines were connected to two distinct AirVPN servers? If they were connected to the same AirVPN server, then AirVPN will block that connection to mitigate Port Fail. Example: You connect both computers to Okab, then you cannot have a remote desktop session, but if you connect one to Okab and the other to Sulafat, then you can get a successful connection. Also, assign different keys to both computers. AirVPN allows you to create up to ten keys at once and use up to five of those 10 concurrently.

Here's what you can do to take advantage of AirVPN's protections(no logging) and reachability while using ShadowSocks, or for that matter, any proxy software that AirVPN does not natively support: 1. Sign up for a 3-year AirVPN plan during Halloween, when you'll get a massive discount 2. Download a Wireguard config using AirVPN's configuration generator 3. Log in to your VPS and set up a Wireguard connection using the config you just downloaded; take extra steps to make sure you don't lock yourself out, such as putting the wireguard connection in a separate network namespace, either using systemd-nspawn or any containerization technology of your choice 4. Set up whatever proxy software you want(I personally recommend and use shadowsocks-rust) 5. Port-forward from your AirVPN account to whatever proxy you just set up This way, you combine the reachability of AirVPN with the versatility of any proxy software of your choice. FYI, shadowsocks-rust can be configure to use chacha20-ietf-poly1305, the same cipher used in Wireguard, but now obscured by Shadowsocks.

As long as your counterparty is not throttling AirVPN's connections by IP on purpose, and as long as your hardware has enough processing power, you can leverage a Wireguard connection to AirVPN to get a connection that operates at linespeed.

Try this: 1. Set up one VM whose only job is to connect to AirVPN. From now on, I will call this VM airproxy. Install Eddie onto airproxy and exclude from Eddie the subnet of the network interface that airproxy uses to connect to the host. 2. Enable ip forwarding and IP masquerading on airproxy 3. Assuming that all your VMs are on an internal network on which your host machine has a connected interface (that is, your host machine is forwarding packets from the VMs as though they were ethernet-connected to the host machine), you can do the following: 3.1. Masquerade all traffic coming from the host and entering airproxy using iptables -t nat -o airproxy -j MASQUERADE on the host (Replace airproxy with the real interface name of airproxy) 3.2 Make a new routing table on the host machine. I will call this airtable from now on. Edit /etc/iproute2/rt_tables to include airtable. 3.3. Set the IP address of airproxy as the default gateway of airtable 3.4. For every VM you want to route through AirVPN, input an ip rule on the host machine to lookup airtable for traffic orginating from that VM Example: You have a VM with IP address 192.168.75.2. The command to enter on the host is "ip rule add from 192.168.75.2 lookup airtable" 3.5. For each VM you added in step 3.3, enter ip route add from $IP_ADDRESS_OF_VM dev $VM_INTERFACE table airtable, where you substitute IP_ADDRESS_OF_VM with whatever the real IP address of the VM is, and you substitute $VM_INTERFACE for the real interface name of the VM.

As long as the cipher you encrypted the database with is secure (ie. AES-256, not blowfish or 3DES), and you are sure your adversaries don't have the decryption key, there is no issue with sending your data under the Atlantic. The TCP protocol will take care of sending your data reliably. However, if you have reason to suspect that your data would be compromised by an adversary in the middle of transit, i suggest you take a sha256sum hash of the data on the sending side, before sending, then another sha256sum on the receiving side, after the data has been received. If the 2 hashes are byte-for-byte equal, you can be certain that your data has not been tampered with or corrupted. Also, if these premises are satisfied (secure encryption scheme, secure encryption key, equal hashes), then using AirVPN adds an extra benefit only if you do not want anybody to know that you are sending data under the Atlantic (in that case, pick an AirVPN server in America that the sender connects to, and another AirVPN server in Europe that the receiver connects to, then all anybody tapping the wires under the Atlantic will see is one AirVPN server talking to another. They will not be able to trace the activity back to you.) If you do not care that the data transfer can be traced back to you, then AirVPN does not help you at all.