go558a83nk

are you using the eddie client?

do you have your server listening on the port that AirVPN assigns you when you test?

Another reason there is no server in Australia is the outrageous cost of bandwidth there.

https://blog.cloudflare.com/the-relative-cost-of-bandwidth-around-the-world/

no, they can. it's that the openvpn server sees that the IP is internal to Air's servers (coming from the SSL daemon or SSH daemon).

performance depends on how fast your ISP line is.  There are several routers that have dual core CPU running 1000mhz or so.  They can do openvpn at 50mbit/s+

if you want 200mbit/s speed then you'll need a pro router. but, chances are you'll struggle to get that anyway from any VPN provider.  (downloading at 200bit/s is 2/5 of a 1gbit/s server's bandwidth because your download is inbound and outbound for the server)

at a loss for words here.

TFTP window?  Are you not using the web GUI of the router?  Are you checking the hash of the downloaded firmware to confirm it's correct?

https://github.com/RMerl/asuswrt-merlin/wiki

for openvpn the main improvement merlin has is policy routing.  this is what you are asking about in the previous post.

found something interesting today.  With another VPN provider I use I can use the "mssfix 0" setting and no openvpn is detected.  Witch reports an MTU of 1500.

But, with AirVPN the mssfix 0 setting does not disguise openvpn use and MTU is reported to be 1392.

here is the VPN config of the other provider:

proto udp
mssfix 0
dev tun
tls-client
ns-cert-type server
key-direction 1
comp-lzo
auth SHA1
cipher AES-256-CBC
keysize 256
verb 3
nobind
persist-tun
persist-key
mute-replay-warnings
script-security 2
ping 6
hand-window 20
socket-flags TCP_NODELAY
topology subnet
pull
route-metric 2
 

That provider also claims to normalize IP packet TTL to prevent VPN detection by TTL analysis. 

What could be the difference between the two VPN providers to cause this difference in result by witch?

back to the topic....

Pavonis (Chicago) had maintenance earlier today and now is using TLSv1.2 control channel cipher.  Prior to the maintenance it was TLSv1.0.

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.

I probed all servers a few weeks ago: All servers added to AirVPN since 19 Jun 2015 use TLSv1.2. All other servers use TLSv1.

 

I don't think it makes much of a difference but it'd still be interesting to hear from staff what they changed in their infrastructure and whether they plan to upgrade the older servers as well.

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.

 

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.

 

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?