reversevpn

Contact me directly at spacetimemperor@protonmail.com, and we can talk about how I can help you by agreeing to a video call.

The reason there is leakage is that you'retch not NAT'ing the traffic from the Synology to AirVPN. My suggestion is to do the following: For the purposes of this guide, I'll call whatever device you're using to access the OpenWRT Web Interface as "laptop", but in reality, it can be a desktop, smartphone, tablet, or anything else with a web browser. (Topmost Menu is the Black Bar of OpenWRT LUCI, which has, by default: OpenWRT, Status, System, Network,Tools): 1. Reset your OpenWRT router to default settings(but the firmware should still be OpenWRT, not the stock firmware). 2.For now, Just plug your laptop into a LAN port so you can configure the router according to the next steps here and the WAN port to your pre-existing network, so that you can install Wireguard . 3. Install the OpenWRT Package for Wireguard 4. Download the AirVPN config file you want to use onto your laptop. 5. Disconnect the router from your pre-existing network that was attached via the WAN port, but leave your laptop plugged in. From here on out, you will not have internet access as you're configuring the OpenWRT router, but you will regain it later at the step where I tell you to reattach the cable from the network to your OpenWRT. You MUST do this, else the next step will fail. DO NOT plug your pre-existing network into any hole on the OpenWRT till you reach the step where I tell you to do so. 4. !!!VERY IMPORTANT!!! PLEASE READ THIS STEP IN FULL, INCLUDING THE EXPLANATION AT THE END Go to Network>Switch and assign 1 port to VLAN 1(We'll use this for LAN) and VLAN 2(We'll use this for your NAS). To assign a router port to a VLAN, within a single row, select "untagged" for the port you want to assign to the VLAN, "off" for very other port, and "tagged" for CPU(eth0). Your table can look like this(I'm going to write it out in JSON-style, where a JSON single object is a table row, the key is a column header, and the value is either what you write in the empty box or select from a dropdown in the empty box. I'm doing this because actually recreating a table in text is more challenging than I'd like) {VLAN ID:1, Description:"", CPU(eth0): tagged, LAN 1: untagged, LAN 2: untagged, LAN 3: off, LAN 4: off, WAN: off }, {VLAN ID:2, Description:"", CPU(eth0): tagged, LAN 1: off, LAN 2: off, LAN 3: off, LAN 4: off, WAN: untagged }, {VLAN ID:3, Description:"For NewLAN", CPU(eth0): tagged, LAN 1: off, LAN 2: off, LAN 3: untagged, LAN 4: off, WAN: off }, {VLAN ID:4, Description:"For NAS", CPU(eth0): tagged, LAN 1: off, LAN 2: off, LAN 3: off, LAN 4: untagged, WAN: off } You're free to choose different ports than what I choose here, as long as your choices are consistent between this step and the following steps. Notice that when I donate a port to NAS and to NewLAN, I remove those same ports from LAN. That is, when I mark them as untagged for the New VLANS I create, I mark them as off for the pre-existing LAN bridge. Whatever you do, DO NOT donate the port that your laptop is currently plugged into to NewLAN or to NAS. 5. Go to the Network>Interfaces Section of OpenWRT and create 3 interfaces, NewLAN, AirVPN(This is what I'll call your Wireguard Interface from now on), and NAS. 5.1.Set the Device of NewLAN to the VLAN ID 3 from earlier, then give it an IP address that is in the same subnet as your pre-existing LAN(i.e. if your pre-existing LAN's gateway is 192.168.1.1, then a potentially nice candidate is 192.168.1.254, if you don't have another device sitting there yet), but not part of the DHCP range. Set the gateway to be the address of your pre-existing router. DO NOT plug the OpenWRT into your pre-existing LAN yet. DO NOT enable DHCP Server on this interface 5.2. Set the Device of NAS to VLAN ID 4. Then, give this interface an IP address that is outside your pre-existing subnet, and also that is not in AirVPN's IP 10.0.0.0/8 range. For example, if your pre-existing LAN is 192.168.1.0/24, then make this interface have address 192.168.2.1. If you have more than 1 LAN, choose a new address that is not part of any network you have yet. Enable DHCP Server on this interface. Set the MTU to be the same as the MTU of your Wireguard conf from AirVPN. 5.3. Copy the Wireguard config file into the AirVPN interface. You will be able to select the Device to bind the new interface to in the Device: field after clicking the "Add new interface..." button in network Interfaces. Do not assign any pre-existing firewall zone to any of these new interfaces. Create a new zone for each. 6. In Network>Firewall, if these zones do not exist yet, create 3 new zones called NewLAN, NAS, and AirVPN. Enable Masquerading for all of these interfaces. Allow NAS to forward to AirVPN. Allow NewLAN to forward to NAS. Allow INPUT, OUTPUT, and Intrazone Forward for NewLan and NAS. Allow OUTPUT but block INPUT and Intrazone Forward for AirVPN. If they already exist, still configure them as I told you. 7. Go back to Network>Interfaces, then edit NewLAN, AirVPN, and NAS interfaces. For each of them go to the Firewall Settings tab (visible after clicking Edit) and set each interface to the firewall zone with the same name. 8. Plug your pre-existing router into the port you donated to NewLAN. 9. Plug your NAS into the ethernet port you donated to NAS. 10. Find out what the IP of the NAS is from Status->Overview and scrolling down. 11. Go to Network->DHCP and DNS->Static Leases and add a static lease for the NAS using the IP address you learned from step 10. Set the lease time to infinite 12. Go to Network->Firewall->Port Forwards and Add a Rule. Specify AirVPN as Source Zone and NAS as Destination Zone. Fill Internal Address with what you learned from step 10. Try your best to make the internal and external port the same. If you cannot, either remap the port from AirVPN's Port Forward page in the Client Area or here in OpenWRT's Port Forward Window. 12. Activate the Wireguard Profile 13. Test the setup 14. Please report the results back here. If there is an error in this guide, let me know so I can correct it.

If you can't dedicate a middlebox to just your NAS, you can use your main machine as the middlebox, if it runs Linux with systemd. If you do have that, then you can use iproute2 and systemd-nspawn to just send the NAS's trafic over the VPN without sending your main computer's traffic over the VPN, unless you also want to send your main computer's traffic over the VPN.

Is it possible for you to insert a middlebox between your synology and the upstream router? By middlebox, I mean any computer that can run Linux (i.e. Debian) and that you can give at least two ethernet interfaces (oen or both can be USB ethernet if you don't have enough built-in Ethernet ports). If it is possible, you can have the middlebox do wireguard, then just set the mtu between the synology and the middlebox to be 1420 (or 1320, if you leave the AirVPN config file as-is), and then just have the middlebox NAT all the synology's traffic into the Wireguard tunnel.

OpenVPN might just be too heavy for your synology NAS to do without sacrificing significant performance. Try wireguard instead.

If you have any friends inside the US with a residential IP willing to help out, you can perform a reverse VPN connection as follows: 1. On your AirVPN account, forward any UDP Port from the Client Area>Ports(Let's just call it x for the sake of this guide). 2.On your machine, set up a wireguard server with the following parameters: [Interface] PrivateKey=(Insert your own wg privatekey here) ListenPort=x Address=192.168.181.2/24 [Peers] PublicKey=(Insert your friend's publicKey here) AllowedIPs=192.168.181.1 PresharedKey=(Insert presharedkey here) 3.Give your friend a wireguard conf like this: [Interface] PrivateKey=(Insert your friend's wg privatekey here) Address=192.168.181.1/24 [Peers] PublicKey=(Insert your own publicKey here) Endpoint= (Insert Your AirVPN Exit IP here):x AllowedIPs=192.168.181.2 PresharedKey=(Insert presharedkey here) PersistentKeepalive=10 4. Get your friend to install shadowsocks server on their machine. Their config file should look something like this: { "server": "192.168.181.1", "server_port": 8388, "password": "(Insert your own password here)", "method": "chacha20-ietf-poly1305" } 5.Get them to start ssserver with the config.json I specified 6. Install shadowsocks on your own machine, and configure it as follows: { "server": "192.168.181.1", "server_port": 8388, "password": "(Insert same password you gave your friend here)", "method" : "chacha20-ietf-poly1305", "local_address": "127.0.0.1", "local_port": 9500 } Run sslocal on your side 7. If you haven't already, install mozilla firefox or one of its many forks on your machine. 8.In your Firefox, go to Settings>General>Proxy Settings>Configure proxy, and set up as follows: 9. Go to ipleak.net on your firefox to verify that you are using your friend's residential IP. 10. You may now connect to handshake AI in Firefox

Did you configure UFW or iptables to allow the port through?

What is your response to the requiring of OS-Level Age Verification in California? For companies like AirVPN, what does it even mean to indicate an age during OS Setup? Are you planning to withdraw your servers from there?

I've got a Monero full node + P2Pool over AirVPN server. BTC seems too difficult to mine and doesn't have the same privacy protections.

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.

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.