go558a83nk

I'm not sure how much this issue can be pushed onto Air staff. They can't control what routing a datacenter has but they can set standards for what datacenters they use so that routing is most likely good for everybody. Examples of datacenters that VPN companies use in Singapore Leaseweb Singapore - http://bgp.he.net/AS59253#_peers Softlayer Singapore - http://bgp.he.net/AS36351#_peers Digital Ocean Singapore - http://bgp.he.net/AS133165#_peers 8 to Infinity Singapore - http://bgp.he.net/AS45470#_peers (only two real peers, but iptransit and Telin are enough)

If user and password are used isn't ca.crt the certificate that's needed? Is that type of connection even possible with Air?

will there be another Dallas server eventually? Your post in the USA servers cancellation thread said "a couple" Dallas servers were on the way.

I just checked out Antares (Singapore) and Hadar (HK) 5 minute average charts for today. Earlier today Antares reached a peak of about 240mbit/s inbound and outbound (480mbit/s total) while Hadar is barely used. They are 1000mbit/s servers. I don't know if that's 1000mbit/s total or in each direction. Staff will have to answer that. If total, then that would mean that the 240mbit/s peak on Antares was still only half capacity (240 inbound + 240 outbound). If 1000 each way then it's only 1/4 capacity. So, I don't think any slowness can be blamed on Air.

two more in Sweden??

nice!

those are just basic iptables. if those don't work in the latest tomato then the whole router shouldn't work

Im on windows 7 Virgin Media SuperHub (100Mb Connection) Connected using the Airvpn Eddie 2.8.8 Connected Via Wireless as i never use the Ethernet wire. SSH Tunnel Port 22 using Eddie 2.88 Any help guys? is your superhub in modem only mode as suggested to try?

admit that my ISP routing to leaseweb singapore is off and on. just in the last couple days I'm back to going through NTT router direct to Antares. However, I went several months with routing going through USA before this. I'm still not convinced it's the fault of anybody but my ISP. Leaseweb probably feels they are covered by the peerage they have. The peerage of Pacnet and NTT is impressive.

You could also try forcing the kernel (not openvpn) to adjust the packet size by disabling mssfix with "mssfix 0" in case the other options don't work. what operating system does the OP use?

the quote is wrong. I didn't say that. but anyway, routing to a server is a complicated matter. there is a very good chance your ISP is who's really at fault for bad routing.

can you show an MTR to Antares and Hadar?

latency is a description of the path to the server, not an indicator of the health of the server itself. please keep in mind that AirVPN and the datacenters they use can NOT affect internet peerage, IP transit agreements and overall routing though I'm sure they wish they could so that all customers were happy.

I use 4 different 4G LTE and a number of ADSL and fibre connections. They all have problems with the SG server. I conclude the server has poor routing for the Asian region. In fact the usa servers have better latency. Ever heard of load balancing ? The previous 100 mbits servers were much better and were balanced across 4 servers. 1 gbits server isn't as good as the previous 4. I agree - routing to Leaseweb Singapore seems to be lacking.

I think there were five. They also had a quite bad reputation, mostly because of their latency. I think it's Singapore's lines' fault. 4 or 5, 100mbit/s. they actually worked quite well for me. my ISP routing to that datacenter was nice. most of the time routing to Leaseweb Singapore takes me to USA first, then back to Singapore. LOL

If I recall correctly the 4 servers were 100 mbit/s each. The 1 now is 1gbit/s. Latency is a descriptor of the path to the server, not of the server itself. In other words, if you are seeing latency problems, blame your ISP peerage/routing/IPtransit agreements or perhaps a fault in a line somewhere.

when running VPN on the router you do NOT use the port forwarding built into router firmware GUI. you must do a DNAT as the IP tables linked to by Staff do. SSH into the router and paste those lines into the command line, editing them to suit your setup. to get a forwarded port, just go into your client area of this web page, forwarded ports section, and click the add button. You will be assigned a port. That port is what goes into the IP tables.

I am using 2.9.2 experimental No. I am always using NL and it is leaking as well. Hello! Can you please confirm that: - "Force DNS" is ticked - "Network Lock" is active - IPv6 is enabled - no firewall other than Windows Firewall is running and under these conditions you have DNS leaks in your Windows system with Eddie 2.9.2 Experimental? Can you send us the output of the command "ipconfig /all" (issued from a command prompt) while the system is connected to the VPN with the aforementioned settings? Kind regards IPv6 should be *disabled*, no?

just another try to point in the direction of this thread. have you tried the buffer changes ddrnewb? https://airvpn.org/topic/13652-eddie-udp-443-on-windows-vs-linux/

hmmm...nothing else changed in your AirVPN setup? I'm thinking a packet fragmentation problem with the new ISP

or the AC87 would be a good step up over the AC68.

yeah the databases often think Persei is in NL

yeah, the way Staff handled this whole thing wasn't correct. they need to be slower to come to a conclusion, and ask questions if there are still unknowns.

I've noticed that too. most likely a geolocation database problem.

Hello, how can you know whether the other provider provides connections to the same ports with the same ciphers and same protocol tried on our servers by ddrnewb or not? And even if it did, you can't assume that ddrnewb tested exactly under the same conditions both services. Actually ddrnewb did not specify anything about that, so it's not correct to make such an assumption. And as you can see from the results he/she posted, we were right, either his/her ISP is performing traffic shaping or it's his/her system to do that. Kind regards I didn't assume as much as you think. 1) the OP says he doesn't like TCP, so I deduced that he would NOT have used TCP for the other VPN provider. 2) from what I can see IPvanish employs no special obfuscation techniques. 3) I think it's a big assumption to say that the speed difference shown is due to protocol. it could just be because of the different time of day and all the many other things that determine internet quality. I believe that point is made in the third speed test posted, where the speed is back down to being similar to the first even though it was an SSL tunnel test.