Opened 5 years ago

Closed 4 years ago

#242 closed Bug / Defect (notabug)

I couldn't access a webpage even the vpn gets connected successfully.

Reported by: Ramy Owned by:
Priority: minor Milestone:
Component: Generic / unclassified Version: OpenVPN 2.2.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: windows
Cc:

Description

VPN Version : 2.2.0/2.1.4
Browser : Windows8/7 64 bit
Internet Connection : 3G internet

I have installed the openvpn 2.2.0 on my system and pasted the client certificated and keys to config folder. Then, I am trying to connect the openvpn gui; it gets connected successfully but i couldn't access a webpage(client website). I got the error as webpage is not available. This happens only on connecting the VPN through 3G internet.

Note:
VPN gets connected successfully and could access the pages(client websites) after i ran OpenVPN GUI through LAN connection.

Attachments (4)

OpenVPN GUI.jpg (32.0 KB) - added by Ramy 5 years ago.
Webpage.jpg (179.2 KB) - added by Ramy 5 years ago.
Tracert testing.ohloh.net_Connect through LAN.txt (288 bytes) - added by Ramy 5 years ago.
Open VPN Log Files_Connect through LAN.txt (7.3 KB) - added by Ramy 5 years ago.

Download all attachments as: .zip

Change History (8)

Changed 5 years ago by Ramy

Attachment: OpenVPN GUI.jpg added

Changed 5 years ago by Ramy

Attachment: Webpage.jpg added

comment:1 Changed 5 years ago by Gert Döring

Priority: blockerminor

please attach the openvpn log file, otherwise it's nearly impossible to say anything about this.

Please do also include more meaningful diagnostics, like "tracert testing.ohloh.net" (from a cmd.exe prompt) so we can see whether routing is set up properly. A web page screenshot without a specific error message can be anything, like "the web server was down at that time, just by chance".

Quite likely, your 3G provider is messing with your traffic, and OpenVPN handshake (small packets) manage to get through, while data traffic (large packets) don't. But again, without the log, this is just guesswork.

comment:2 Changed 5 years ago by Ramy

Tracert testing.ohloh.net from cmd_Connect VPN through 3G

C:\Users\ramyar>tracert testing.ohloh.net

Tracing route to testing.ohloh.net [92.242.132.8]
over a maximum of 30 hops:

1 885 ms 428 ms 349 ms 10.22.0.1
2 927 ms 419 ms 929 ms 10.1.0.1
3 507 ms 1099 ms 399 ms 10.1.14.4
4 763 ms 987 ms 988 ms svlb1.blackducksoftware.com [10.1.20.4]
5 1436 ms 459 ms 768 ms fa0-1.na01.b002133-1.bos06.atlas.cogentco.com [3

8.122.52.33]

6 1147 ms 1218 ms 939 ms vl3542.mag01.bos06.atlas.cogentco.com [38.20.39.

109]

7 756 ms 1129 ms 819 ms te3-8.ccr01.bos06.atlas.cogentco.com [154.54.85.

41]

8 1018 ms 769 ms 1128 ms te0-4-0-4.ccr21.bos01.atlas.cogentco.com [66.28.

4.41]

9 689 ms 1118 ms 708 ms te0-1-0-2.ccr21.lon13.atlas.cogentco.com [154.54

.1.94]

10 1055 ms 1228 ms 1309 ms te0-0-0-0.ccr21.lon01.atlas.cogentco.com [154.54

.57.113]

11 468 ms 799 ms 839 ms te7-8.ccr01.lon02.atlas.cogentco.com [130.117.1.

218]

12 737 ms 869 ms 799 ms te2-3.mag01.lon02.atlas.cogentco.com [130.117.50

.118]

13 896 ms 879 ms 848 ms verio.lon02.atlas.cogentco.com [130.117.14.174]

14 895 ms 459 ms 519 ms crt0-the-ge0-0-0.router.uk.catalyst2.net [213.13

0.48.214]

15 456 ms 469 ms 1039 ms 84.18.192.138
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete.

Open VPN Log Files_Connect through 3G :

Thu Dec 06 15:28:24 2012 NOTE: --user option is not implemented on Windows
Thu Dec 06 15:28:24 2012 NOTE: --group option is not implemented on Windows
Thu Dec 06 15:28:24 2012 OpenVPN 2.1.4 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 8 2010
Thu Dec 06 15:28:24 2012 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Thu Dec 06 15:28:24 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Dec 06 15:28:24 2012 LZO compression initialized
Thu Dec 06 15:28:24 2012 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu Dec 06 15:28:24 2012 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Dec 06 15:28:25 2012 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Dec 06 15:28:25 2012 Local Options hash (VER=V4): '69109d17'
Thu Dec 06 15:28:25 2012 Expected Remote Options hash (VER=V4): 'c0103fa8'
Thu Dec 06 15:28:25 2012 Attempting to establish TCP connection with 24.34.109.95:1194
Thu Dec 06 15:28:25 2012 TCP connection established with 24.34.109.95:1194
Thu Dec 06 15:28:25 2012 TCPv4_CLIENT link local: [undef]
Thu Dec 06 15:28:25 2012 TCPv4_CLIENT link remote: 24.34.109.95:1194
Thu Dec 06 15:28:26 2012 TLS: Initial packet from 24.34.109.95:1194, sid=e48f7d79 10c864e7
Thu Dec 06 15:28:34 2012 VERIFY OK: depth=1, /C=US/ST=MA/L=Waltham/O=BlackDuck_Software_Inc./OU=IT/CN=launchpad.blackducksoftware.com/emailAddress=root@…
Thu Dec 06 15:28:34 2012 VERIFY OK: depth=0, /C=US/ST=MA/O=BlackDuck_Software_Inc./OU=IT/CN=server/emailAddress=root@…
Thu Dec 06 15:28:51 2012 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Dec 06 15:28:51 2012 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Dec 06 15:28:51 2012 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Dec 06 15:28:51 2012 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Dec 06 15:28:51 2012 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Thu Dec 06 15:28:51 2012 [server] Peer Connection Initiated with 24.34.109.95:1194
Thu Dec 06 15:28:53 2012 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Thu Dec 06 15:28:55 2012 PUSH: Received control message: 'PUSH_REPLY,route 10.1.0.0 255.255.252.0,route 10.1.4.0 255.255.252.0,route 10.1.8.0 255.255.252.0,route 10.1.16.0 255.255.252.0,route 10.1.20.0 255.255.252.0,route 10.1.24.0 255.255.252.0,route 10.1.28.0 255.255.252.0,route 10.9.8.0 255.255.252.0,route 10.20.0.0 255.255.255.0,route 10.21.0.0 255.255.255.0,route 10.22.0.0 255.255.255.0,route 172.29.37.0 255.255.255.0,dhcp-option DNS 10.1.0.11,dhcp-option DOMAIN blackducksoftware.com,route 10.22.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.22.0.206 10.22.0.205'
Thu Dec 06 15:28:55 2012 OPTIONS IMPORT: timers and/or timeouts modified
Thu Dec 06 15:28:55 2012 OPTIONS IMPORT: --ifconfig/up options modified
Thu Dec 06 15:28:55 2012 OPTIONS IMPORT: route options modified
Thu Dec 06 15:28:55 2012 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Dec 06 15:28:55 2012 ROUTE default_gateway=223.235.79.46
Thu Dec 06 15:28:55 2012 TAP-WIN32 device [Local Area Connection 2] opened:
.\Global\{91D1AD39-0863-4CF0-A607-871F35A99D68}.tap
Thu Dec 06 15:28:55 2012 TAP-Win32 Driver Version 9.7
Thu Dec 06 15:28:55 2012 TAP-Win32 MTU=1500
Thu Dec 06 15:28:55 2012 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.22.0.206/255.255.255.252 on interface {91D1AD39-0863-4CF0-A607-871F35A99D68} [DHCP-serv: 10.22.0.205, lease-time: 31536000]
Thu Dec 06 15:28:55 2012 Successful ARP Flush on interface [29] {91D1AD39-0863-4CF0-A607-871F35A99D68}
Thu Dec 06 15:28:57 2012 TEST ROUTES: 14/14 succeeded len=13 ret=1 a=0 u/d=up
Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 24.34.109.95 MASK 255.255.255.255 223.235.79.46
The route addition failed: The object already exists.
Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.1.0.0 MASK 255.255.252.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.1.4.0 MASK 255.255.252.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.1.8.0 MASK 255.255.252.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.1.16.0 MASK 255.255.252.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.1.20.0 MASK 255.255.252.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.1.24.0 MASK 255.255.252.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.1.28.0 MASK 255.255.252.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.9.8.0 MASK 255.255.252.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.20.0.0 MASK 255.255.255.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.21.0.0 MASK 255.255.255.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.22.0.0 MASK 255.255.255.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 172.29.37.0 MASK 255.255.255.0 10.22.0.205

OK!

Thu Dec 06 15:28:57 2012 C:\WINDOWS\system32\route.exe ADD 10.22.0.0 MASK 255.255.255.0 10.22.0.205
The route addition failed: The object already exists.
Thu Dec 06 15:28:57 2012 Initialization Sequence Completed

comment:3 Changed 4 years ago by Samuli Seppänen

Keywords: windows added

Is this still a problem with latest release (2.3.2) and/or Git "master"?

comment:4 Changed 4 years ago by Gert Döring

Resolution: notabug
Status: newclosed

Sorry for not replying in a more timely fashion.

If it works via LAN but fails via 3G, this hints at "something in the 3G network", for example a problem with fragmentation and their NAT device, or with packet MTU.

This is not something we can diagnose in a ticket - it needs to be diagnosed with your VPN provider: see what goes into the VPN tunnel on the server side, how it is encapsulated (packet size, fragments, ...) and what part of it is arriving on your end. Then experiment with options like --mssfix to work around this.

As a starting point, you could just try to insert "mssfix 1000" into your client openvpn.config - this will make TCP packets smaller than the normal maximum of 1500 bytes, thus avoiding fragmentation, at the cost of a bit of overhead (more packets).

Note: See TracTickets for help on using tickets.