Question regarding HTTP/latency?

[jgalt 1]

I seem to have a strange problem. When I am connected through the VPN (to US/Sirus), surfing the web feels like going through a modem. I get very slow load speeds, even to something like google.com

So I did a tracert and I do indeed see packets being dropped at certain routers.. this might explain why i get partial loading of websites too.

For example, I did a tracert to mail.google.com (with nothing running on my pc to suck bandwidth)

2 46 ms 43 ms 42 ms hosted.by.leaseweb.com [108.59.8.190]

3 233 ms 397 ms 195 ms 108.59.15.191

4 42 ms 41 ms 44 ms te3-3.msc2.hdcs.leaseweb.net [217.20.125.12]

5 149 ms 148 ms 144 ms te0-10-0-11.crs.evo.leaseweb.net [217.20.125.23]

6 * * * Request timed out.

7 201 ms 206 ms 207 ms 209.85.249.54

8 136 ms * 136 ms 72.14.232.76

9 192 ms 178 ms 137 ms 209.85.241.226

10 186 ms 157 ms 177 ms 66.249.95.21

11 150 ms 148 ms 148 ms 72.14.235.187

12 * * * Request timed out.

13 152 ms 153 ms 171 ms de-in-f18.1e100.net [74.125.24.18]

Is this normal?

Thanks

[Staff 9770]

Hello!

It does not seem normal. Do you experience the same with other servers? Did you test a connection on a TCP port? Can you please send us the logs of your client?

Kind regards

[jgalt 1]

Thanks.. Yea I tried TCP next.. didn't seem that great either.. Let me do a comprehensive test tonight and I will post back

[jgalt 1]

Ok.. I just tested Sirius with TCP/443 right this moment. Worst I've seen it. I am running Shib's Tomato firmware on my router.. so I'll check to make sure there's not some weird setting on there that's causing performance issues.

Tracing route to googlemail.l.google.com [74.125.139.17]

over a maximum of 30 hops:

1 * * * Request timed out.

2 * * * Request timed out.

3 * * * Request timed out.

4 2349 ms 1070 ms * te2-2.msc2.hdcs.leaseweb.net [217.20.125.10]

5 * * * Request timed out.

6 * * * Request timed out.

7 * * * Request timed out.

8 * * * Request timed out.

9 * *

10/15/2012 - 7:45 PM AirVPN client version: 1.7

10/15/2012 - 7:45 PM Reading options from D:\Program Files\AirVPN\AirVPN.xml

10/15/2012 - 7:45 PM OpenVPN bundle version: OpenVPN 2.2.2

10/15/2012 - 7:45 PM OpenVPN current version: OpenVPN 2.2.2

10/15/2012 - 7:45 PM Ready.

10/15/2012 - 7:46 PM Login...

10/15/2012 - 7:46 PM Login success.

10/15/2012 - 7:46 PM Contacting service...

10/15/2012 - 7:46 PM Connecting...

10/15/2012 - 7:46 PM OpenVPN 2.2.2 Win32-MSVC++ [sSL] [LZO2] [PKCS11] built on Dec 15 2011

10/15/2012 - 7:46 PM NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

10/15/2012 - 7:46 PM LZO compression initialized

10/15/2012 - 7:46 PM Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]

10/15/2012 - 7:46 PM Socket Buffers: R=[8192->8192] S=[8192->8192]

10/15/2012 - 7:46 PM Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]

10/15/2012 - 7:46 PM Local Options hash (VER=V4): '958c5492'

10/15/2012 - 7:46 PM Expected Remote Options hash (VER=V4): '79ef4284'

10/15/2012 - 7:46 PM Attempting to establish TCP connection with 108.59.8.147:443

10/15/2012 - 7:46 PM TCP connection established with 108.59.8.147:443

10/15/2012 - 7:46 PM TCPv4_CLIENT link local: [undef]

10/15/2012 - 7:46 PM TCPv4_CLIENT link remote: 108.59.8.147:443

10/15/2012 - 7:46 PM TLS: Initial packet from 108.59.8.147:443, sid=1e1e457a 5a091645

10/15/2012 - 7:46 PM VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org_CA/emailAddress=info@airvpn.org

10/15/2012 - 7:46 PM VERIFY OK: nsCertType=SERVER

10/15/2012 - 7:46 PM VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=server/emailAddress=info@airvpn.org

10/15/2012 - 7:46 PM Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key

10/15/2012 - 7:46 PM Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

10/15/2012 - 7:46 PM Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key

10/15/2012 - 7:46 PM Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

10/15/2012 - 7:46 PM Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

10/15/2012 - 7:46 PM [server] Peer Connection Initiated with 108.59.8.147:443

10/15/2012 - 7:46 PM SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

10/15/2012 - 7:46 PM PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.5.0.1,comp-lzo no,route 10.5.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.5.0.38 10.5.0.37'

10/15/2012 - 7:46 PM OPTIONS IMPORT: timers and/or timeouts modified

10/15/2012 - 7:46 PM OPTIONS IMPORT: LZO parms modified

10/15/2012 - 7:46 PM OPTIONS IMPORT: --ifconfig/up options modified

10/15/2012 - 7:46 PM OPTIONS IMPORT: route options modified

10/15/2012 - 7:46 PM OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

10/15/2012 - 7:46 PM ROUTE default_gateway=192.168.1.1

10/15/2012 - 7:46 PM TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{84B5D280-044A-4F78-944D-9D95274C210E}.tap

10/15/2012 - 7:46 PM TAP-Win32 Driver Version 9.9

10/15/2012 - 7:46 PM TAP-Win32 MTU=1500

10/15/2012 - 7:46 PM Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.5.0.38/255.255.255.252 on interface {84B5D280-044A-4F78-944D-9D95274C210E} [DHCP-serv: 10.5.0.37, lease-time: 31536000]

10/15/2012 - 7:46 PM Successful ARP Flush on interface [18] {84B5D280-044A-4F78-944D-9D95274C210E}

10/15/2012 - 7:46 PM TEST ROUTES: 2/2 succeeded len=1 ret=1 a=0 u/d=up

10/15/2012 - 7:46 PM C:\WINDOWS\system32\route.exe ADD 108.59.8.147 MASK 255.255.255.255 192.168.1.1

10/15/2012 - 7:46 PM ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4

10/15/2012 - 7:46 PM Route addition via IPAPI succeeded [adaptive]

10/15/2012 - 7:46 PM C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.5.0.37

10/15/2012 - 7:46 PM ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4

10/15/2012 - 7:46 PM Route addition via IPAPI succeeded [adaptive]

10/15/2012 - 7:46 PM C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.5.0.37

10/15/2012 - 7:46 PM ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4

10/15/2012 - 7:46 PM Route addition via IPAPI succeeded [adaptive]

10/15/2012 - 7:46 PM C:\WINDOWS\system32\route.exe ADD 10.5.0.1 MASK 255.255.255.255 10.5.0.37

10/15/2012 - 7:46 PM ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4

10/15/2012 - 7:46 PM Route addition via IPAPI succeeded [adaptive]

10/15/2012 - 7:46 PM Initialization Sequence Completed

10/15/2012 - 7:46 PM Starting Management Interface...

10/15/2012 - 7:46 PM Checking...

10/15/2012 - 7:46 PM Retrieve statistics...

10/15/2012 - 7:46 PM Connected.

10/15/2012 - 7:50 PM Disconnecting...

10/15/2012 - 7:50 PM TCP/UDP: Closing socket

10/15/2012 - 7:50 PM Disconnected.

10/15/2012 - 7:50 PM C:\WINDOWS\system32\route.exe DELETE 10.5.0.1 MASK 255.255.255.255 10.5.0.37

10/15/2012 - 7:50 PM Route deletion via IPAPI succeeded [adaptive]

10/15/2012 - 7:50 PM C:\WINDOWS\system32\route.exe DELETE 108.59.8.147 MASK 255.255.255.255 192.168.1.1

10/15/2012 - 7:50 PM Route deletion via IPAPI succeeded [adaptive]

10/15/2012 - 7:50 PM C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 10.5.0.37

10/15/2012 - 7:50 PM Route deletion via IPAPI succeeded [adaptive]

10/15/2012 - 7:50 PM C:\WINDOWS\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 10.5.0.37

10/15/2012 - 7:50 PM Route deletion via IPAPI succeeded [adaptive]

10/15/2012 - 7:50 PM Closing TUN/TAP interface

10/15/2012 - 7:50 PM SIGTERM[hard,] received, process exiting

[jgalt 1]

Hmm.. I may be on to something.. Maybe my VPN link it's picking up the right DNS settings.. for example, I went to the speed test and it couldn't resolve speedtest.air

You tried to visit speedtest.air, which is not loading.

OpenDNS: Sign in

Results 1 - 7 of 12,600,000 for speedtest

I do use opendns for my personal connection, so I don't know if this was using yours or mine.

[Staff 9770]

Hmm.. I may be on to something.. Maybe my VPN link it's picking up the right DNS settings.. for example, I went to the speed test and it couldn't resolve speedtest.air

You tried to visit speedtest.air, which is not loading.

OpenDNS: Sign in

Results 1 - 7 of 12,600,000 for speedtest

I do use opendns for my personal connection, so I don't know if this was using yours or mine.

Hello!

Your system did not use the VPN server DNS: speedtest.air is resolved only by them. Can you please send us the output of "ipconfig /all" while your computer is connected to a VPN server?

Kind regards

[jgalt 1]

Sure.. here's then TUN adapter when I'm connected (Librae UDP 443 right now)

Ethernet adapter Local Area Connection 2:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : TAP-Win32 Adapter V9

Physical Address. . . . . . . . . : 00-FF-BF-8C-AB-E3

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

IPv4 Address. . . . . . . . . . . : 10.4.8.22(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.252

Lease Obtained. . . . . . . . . . : Monday, October 15, 2012 10:04:31 PM

Lease Expires . . . . . . . . . . : Tuesday, October 15, 2013 10:04:30 PM

Default Gateway . . . . . . . . . :

DHCP Server . . . . . . . . . . . : 10.4.8.21

DNS Servers . . . . . . . . . . . : 10.4.0.1

NetBIOS over Tcpip. . . . . . . . : Enabled

[Staff 9770]

Sure.. here's then TUN adapter when I'm connected (Librae UDP 443 right now)

Hello!

That's fine, as it is just as expected from the logs (DNS push ok). We asked however for the "ipconfig /all" output (feel free to delete of course possible sensitive data), just to check the DNS of your physical adapter(s): if your system keeps refusing to send DNS queries to 10.4.0.1, you can force it by setting 10.4.0.1 as primary DNS in your physical interface. See also https://airvpn.org/specs

Kind regards

[jgalt 1]

Just FYI.. I just configured the same Librea settings with OpenVPN under my Archlinux box ( to make sure it wasn't some crazy Windows thing). I still get partial HTTP pages. So I'm going to focus on my router now to make sure it's not that.. Most likely it is me, else I'm sure you would have a lot of other complaints. So don't spend anymore time on this thread until I can narrow it down (or heck, maybe my ISP decided to do something funky.. I do see lots of tcp retransmissions however).

[jgalt 1]

Ok last question.. I just ran a test connecting to Sirius on port 80. I ran a tcpdump on the tun0 interface, and captured all packets going across the wire. All I did was try to reach airvpn.org through my linux browser. Would attaching that capture help you guys in determining the issue? reason I ask is because even this time it looked like this for tracepath

??(130:22:43:%)?? tracepath google.com ??(Mon,Oct15)??

1: 10.7.0.18 0.240ms pmtu 1500

1: 10.7.0.1 240.190ms

1: no reply

2: no reply

3: no reply

1: 10.7.0.1 10948.162ms

1: 10.7.0.1 14226.358ms

1: 10.7.0.1 13392.127ms

2: hosted.by.leaseweb.com 15744.036ms

2: hosted.by.leaseweb.com 19899.546ms

2: hosted.by.leaseweb.com 23902.328ms

3: 108.59.15.205 25312.213ms

3: 108.59.15.205 24515.707ms

3: 108.59.15.207 28665.258ms

4: te3-3.msc1.hdcs.leaseweb.net 32728.634ms

4: te2-2.msc2.hdcs.leaseweb.net 36793.515ms

5: xe1-0-0.ms1.iad.leaseweb.net 83.094ms

6: te0-1-0-6.crs.evo.leaseweb.net 132.803ms

[jgalt 1]

Well, FWIW, I just tested Sirius UDP 443 directly inside my router connection, and http surfing was still slow and sometimes wouldn't pull the whole page in. I guess it's just the nature of VPN

[Staff 9770]

Hello!

You have enormous latency and probably packet loss, unfortunately. If it's not a hardware problem, then there are major peering issues between your ISP and all the servers you have tested. In order to see which bandwidth you can obtain with our servers with normal peering and no packet loss, please see the table "Top 10 Users Speed" on the right of the following page:

https://airvpn.org/status

Kind regards

[jgalt 1]

Do you all have the openvpn "fragment" setting set on the server side per chance? I'm thinking I'm getting MTU/mss issues

[jgalt 1]

SOLVED!

I did some research and based on the packet retries and such I was seeing, I believed fragmenting was occuring. I set this option in my openvpn config file for UDP/443 Sirus and surfing is SIGNIFICANTLY better.. not perfect.. but much better

mssfix 1300

I'm not sure how high to keep testing it, but it's a start. Don't know if it's due to Time Warner or what.. but something is causing the fragmentation.

[Staff 9770]

SOLVED!

I did some research and based on the packet retries and such I was seeing, I believed fragmenting was occuring. I set this option in my openvpn config file for UDP/443 Sirus and surfing is SIGNIFICANTLY better.. not perfect.. but much better

mssfix 1300

I'm not sure how high to keep testing it, but it's a start. Don't know if it's due to Time Warner or what.. but something is causing the fragmentation.

Hello!

Excellent, thank you for the information. You can fine-tune the parameter trying to lower (or increase) it in small steps and test each time whether the performance improves or gets worse. Do not exceed 1500, of course.

Our servers are configured with default OpenVPN MTU size in order to provide best performance with UDP in case of no or low packet loss/fragmentation. Probably a guide is necessary for clients which have fragmentation issues in order to mitigate the issue on the client side only, we'll be working on it (not difficult, the OpenVPN community wrote a lot about it).

Kind regards

[Staff 9770]

SOLVED!

I did some research and based on the packet retries and such I was seeing, I believed fragmenting was occuring. I set this option in my openvpn config file for UDP/443 Sirus and surfing is SIGNIFICANTLY better.. not perfect.. but much better

mssfix 1300

I'm not sure how high to keep testing it, but it's a start. Don't know if it's due to Time Warner or what.. but something is causing the fragmentation.

Hello!

This will help you:

http://openvpn.net/archive/openvpn-users/2004-11/msg00044.html

Ping the entry-IP address of the server you wish to connect to in order to have a quicker approximation of the size you need to set with mssfix.

Kind regartds

[jgalt 1]

Thanks for the link! What's weird is when I removed the mssfix from my config to start testing with pings, everything is working perfectly. Full fast bandwidth, pages loading fast.. strange. I'm connected to Librae UDP 443.. so maybe that guy is good to go?

[Staff 9770]

Thanks for the link! What's weird is when I removed the mssfix from my config to start testing with pings, everything is working perfectly. Full fast bandwidth, pages loading fast.. strange. I'm connected to Librae UDP 443.. so maybe that guy is good to go?

Hello!

That's fine, we're glad to know it. Probably so. Or maybe your ISP had a temporary problem.

Just in case you'll need it in the future (hopefully not) when you perform ping tests with different packet sizes toward the entry-IP of a VPN server to determine the optimal value (if necessary) for mssfix, you don't need to be connected to that VPN server, and even if you're connected to that server, it's not relevant removing the mssfix directive because packets to/from the entry-IP will not be tunneled of course. In general, you need to perform the test while you are not connected to any VPN server.

[EDIT - for readers' comfort and future reference, an excerpt from OpenVPN 2.2.2 manual]

--mtu-test

To empirically measure MTU on connection startup, add the --mtu-test option to

your configuration. OpenVPN will send ping packets of various sizes to the remote

peer and measure the largest packets which were successfully received. The --mtu-

test process normally takes about 3 minutes to complete.

--fragment max

Enable internal datagram fragmentation so that no UDP datagrams are sent which are

larger than max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e.

the UDP packet size after encapsulation overhead has been added in, but not

including the UDP header itself.

The --fragment option only makes sense when you are using the UDP protocol (

--proto udp ).

--fragment adds 4 bytes of overhead per datagram.

See the --mssfix option below for an important related option to --fragment.

It should also be noted that this option is not meant to replace UDP fragmentation

at the IP stack level. It is only meant as a last resort when path MTU discovery

is broken. Using this option is less efficient than fixing path MTU discovery for

your IP link and using native IP fragmentation instead.

Having said that, there are circumstances where using OpenVPN's internal fragmen?

tation capability may be your only option, such as tunneling a UDP multicast

stream which requires fragmentation.

--mssfix max

Announce to TCP sessions running over the tunnel that they should limit their send

packet sizes such that after OpenVPN has encapsulated them, the resulting UDP

packet size that OpenVPN sends to its peer will not exceed max bytes. The default

value is 1450.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e.

the UDP packet size after encapsulation overhead has been added in, but not

including the UDP header itself.

The --mssfix option only makes sense when you are using the UDP protocol for Open?

VPN peer-to-peer communication, i.e. --proto udp.

--mssfix and --fragment can be ideally used together, where --mssfix will try to

keep TCP from needing packet fragmentation in the first place, and if big packets

come through anyhow (from protocols other than TCP), --fragment will internally

fragment them.

Both --fragment and --mssfix are designed to work around cases where Path MTU dis?

covery is broken on the network path between OpenVPN peers.

The usual symptom of such a breakdown is an OpenVPN connection which successfully

starts, but then stalls during active usage.

Kind regards