reversevpn

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.

That depends who you are hiding the sensitive, private data from, and whether it was already encrypted before you sent it through AirVPN. If who you are hiding it from has no power over the jurisdiction of the AirVPN server you connected to AND no power over the jurisdiction that you are sending your data to, NOR over any intermediate points between the AirVPN server and the final destination of your data, and the data was not encrypted to begin with, then yes, your security has improved a little, because your data is now being decrypted in a jurisdiction that your adversary has no power over. In this sense, AirVPN prevents adversaries from sniffing your data. However, in today's internet, it is bad practice to rely on your adversary not being in any jurisdiction, because it is hard(but not impossible) to know the full path that your data travels over, especially once it leaves the AirVPN server. It would be better if you had encrypted the data BEFORE sending it through AirVPN. If the data was already end-to-end encrypted so that only your intended recipient can decrypt your data, then AirVPN helps only in the sense that 3rd part observers will not know that YOU are the one sending data to your intended recipient(provided that your recipient is not cooperating with your adversary and has not been compromised by your adversary). If your goal is to hide your data from everybody other than your intended recipient (this would be the norm), but you do not care that people see that you are sending something to your intended recipient (provided that they cannot understand what you are sending), then using AirVPN would not really improve your security. If your goal is to hide your data from everybody other than your intended recipient and you do not want them to know that you are even sending anything to your intended recipient (they will still see that you are sending something to AirVPN, not that they can understand what you are sending), then yes, AirVPN does improve your security. Either way, it would be best to encrypt your data end-to-end before sending it. DO NOT rely on AirVPN to keep the data encrypted end-to-end, because the only way AirVPN can send the data to your recipient is to decrypt your data and send it to the recipient.

It appears you don't have wintun on your computer. Try installing wintun and repeating the connection procedure with wintun already installed.

If the distro that your router runs supports iptables-persistent, then iptables-persistent is the canonical way of making iptables rules survive past reboot. As for /etc/rc.local, that is the generic way of running commands at startup if your distro doesn't have systemd. However, if jffs is idiomatic for Asus Merlin, then you've probably done the right thing. Depends on the idioms of your distro.

Either put them in /etc/rc.local, or install the iptables-persistent package.