go558a83nk

bothersome? all you have to do is download a firmware file, upload it to your router, and wait about 3 minutes for the firmware to install.

my suggestion is to use merlin asus firmware, policy routing therein, and DNSFiltering to control which DNS is used for which client.

you seem to know what you are doing so I hesitate to ask if you made sure the tun device really is tun1. and your personal LAN has subnet 10.1.x.x?

merlin firmware is going to best support the AC68 as it's based on asus stock firmware with optimizations and additions. for openvpn clients merlin firmware has policy based routing and can block VPN routed clients if the tunnel goes down. it's also extremely easy to install entware which allows you to install (on USB storage) many more linux packages. you can even install stunnel so that you can use Air's openvpn through SSL tunnel option. (openvpn through SSH requires no additional package install.)

That warning about opening ports on your router is for if you are using the Eddie client on a computer. Since you are using your router to run openvpn you do need to forward ports using the iptables you know of. Since it's not working something isn't yet correct. Did you change the TUN device specified in the iptables to match that which your system uses for openvpn? If not, use ifconfig at the SSH prompt to see (while openvpn is running).

I'm not sure where you've read from Air about not using the same port. What they said was that you shouldn't open ports on your router from the WAN interface to your LAN. That's what the router GUI does. The rules I've given you forward from TUN to LAN. Make sure your torrent client is listening on the port that Air assigns you and that that port is forwarded to the proper IP address with the IP tables. The port checker will show the port as closed if there is no server listening on that port. Finally, it's best to SSH into the router and paste in the correct IP tables at the prompt. I don't know if your other method works.

Forwarding ports in router GUI doesn't work for VPN connections. Search this forum some more - staff even have a post in the how to section I think.

Study up on advanced ddwrt usage and read ddwrt forums. If you can install and run stunnel you're 90% done. If you have an Asus router I know it can be done by using Merlin firmware and installing entware. Entware then allows you to install many other packages common to Linux, including stunnel.

Interesting. I do know that Etamin was using TLS1.2 though it was added in May. Perhaps the change to TLS1.2 occurred during one of the maintenance sessions it had recently?

another update. I guess each server is different. Metallah still uses the TLS1.0 cipher.

ugh. losing Etamin will hurts me. I've never noticed problems but I've also never needed port-forwarding through it. I assume that's when I'd notice the "nulling" of the exit IP by the datacenter. Good luck to you Air staff - I hope you find excellent replacements.

latency is a description of the path from you to the server. the servers can't do anything to change latency. most likely peering/transit by your ISP has changed.

I say it in a lot of posts - try testing speed elsewhere. https://www.dslreports.com/speedtest is a good place to test your buffers are the first place to start in fixing any problem as FromtheWalls said.

you'll need your kindle fire hd to use a VPN tunnel to the UK then. probably easiest to just run VPN on a router so that all clients of the router (e.g. kindle fire hd and whatever else) will go through the VPN tunnel.

update. today I noticed that Air is now using the same TLS1.2 cipher as above. I'm glad for the change.

for this I use the extension for firefox called location guard. I use its fixed location function and place that in the city where the VPN server is.

To be fair, only Firefox-based browsers allow WebRTC to be disabled. Some extensions such as uBlock and Chrome's add-on allow leaks to be plugged, but they don't disable WebRTC completely. As 'leaks' are only an issue for those behind a VPN, it makes sense for VPN providers to offer a workaround, or at least some advice on how to achieve it. Since the OP's data is just that - raw data without any recommendation - I wouldn't call it a 'review'. That's not a negative, far from it. It's hard to find quantitative data about VPN companies, and I think the OP did a decent job. One thing that really bugs me about VPN 'reviews' in general is the speed tests. They are invariably carried out by someone on a <15 Mbps connection. Just... why? If nothing else for the love of God rent a decent gigabit plus VPS and set up a connection on there and leech some well seeded torrents. Plenty of 'superb high speed' VPN companies can't even half saturate my 160Mbps connection. Air does (usually). why should the VPN provider be the one to provide a workaround? why shouldn't the user just change browsers?

the whole webRTC thing needs to just die. it's not up to a VPN provider to protect you from a web browser function. In my opinion you shouldn't consider webRTC blockage in your review. users should instead just disable it in their browser if they don't want it.

get an asus AC56 if greater cost is prohibitive. those CPU can be overclocked to 1200megahertz. 50mbit/s openvpn is possible.

Air uses TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA for the control channel. I've noticed another VPN provider of mine is now using TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA Is there any reason to worry that Air still uses a TLSv1.0 control channel cipher?

https://www.dd-wrt.com/wiki/index.php/Linksys_E4200 see the link for specs. with that CPU you can't expect much more than the speed you're getting. look for a router with at least dual core 1000mhz CPU for acceptable openvpn speeds.

not showing up as available yet for me.

I disabled tcp timestamps on my windows 7 machine but it made no difference. VPN is run on my router. I disabled timestamps on it, too, but still no difference in test results.

just test other ways. there's no reason why Air would be slower than other VPN.

my first test shows MTU of 1392 though I am using and always use "mssfix 0". edit: my usage of "mtu-disc maybe" has no affect on perceived MTU by the script.