[SOLVED] New connection problem!

[r0yal 0]

It finally working again, for the first time since yesterday. Thanks! What did you do to fix the problem?

[YLwpLUbcf77U 32]

I hate to be a party pooper but I've been receiving the Already Connected message since I disconnected (no data was going through) about 15 minutes ago.

Castor.

Admin, could you consider the two solutions I proposed in the beginning of this thread? (IE, give the end-user the ability to kill an active connection possibly with the use of a secondarily-created 'overkill' password).

[enigma 0]

Hello

15.09.2012 - 21:19 AirVPN client version: 1,7

15.09.2012 - 21:19 Reading options from C:\Users\Antonio\AppData\Roaming\AirVPN\Air\1.0.0.0\AirVPN.xml

15.09.2012 - 21:19 OpenVPN bundle version: OpenVPN 2.2.2

15.09.2012 - 21:19 OpenVPN current version: OpenVPN 2.2.2

15.09.2012 - 21:19 Login...

15.09.2012 - 21:19 Login success.

15.09.2012 - 21:20 Contacting service...

15.09.2012 - 21:20 Connecting...

15.09.2012 - 21:20 OpenVPN 2.2.2 Win32-MSVC++ [sSL] [LZO2] [PKCS11] built on Dec 15 2011

15.09.2012 - 21:20 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

15.09.2012 - 21:20 LZO compression initialized

15.09.2012 - 21:20 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]

15.09.2012 - 21:20 Socket Buffers: R=[8192->8192] S=[8192->8192]

15.09.2012 - 21:20 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]

15.09.2012 - 21:20 Local Options hash (VER=V4): '22188c5b'

15.09.2012 - 21:20 Expected Remote Options hash (VER=V4): 'a8f55717'

15.09.2012 - 21:20 UDPv4 link local: [undef]

15.09.2012 - 21:20 UDPv4 link remote: 31.193.12.98:443

15.09.2012 - 21:20 TLS: Initial packet from 31.193.12.98:443, sid=b60f1541 9f3f0d29

15.09.2012 - 21:20 VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org_CA/emailAddress=info@airvpn.org

15.09.2012 - 21:20 VERIFY OK: nsCertType=SERVER

15.09.2012 - 21:20 VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=server/emailAddress=info@airvpn.org

15.09.2012 - 21:20 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key

15.09.2012 - 21:20 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

15.09.2012 - 21:20 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key

15.09.2012 - 21:20 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

15.09.2012 - 21:20 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

15.09.2012 - 21:20 [server] Peer Connection Initiated with 31.193.12.98:443

15.09.2012 - 21:20 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

15.09.2012 - 21:20 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.4.0.1,comp-lzo no,route 10.4.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.4.0.170 10.4.0.169'

15.09.2012 - 21:20 OPTIONS IMPORT: timers and/or timeouts modified

15.09.2012 - 21:20 OPTIONS IMPORT: LZO parms modified

15.09.2012 - 21:20 OPTIONS IMPORT: --ifconfig/up options modified

15.09.2012 - 21:20 OPTIONS IMPORT: route options modified

15.09.2012 - 21:20 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

15.09.2012 - 21:20 ROUTE default_gateway=192.168.1.1

15.09.2012 - 21:20 TAP-WIN32 device [AirVPN] opened: \\.\Global\{4360408B-BEBC-43A7-97E3-29F3836A8E35}.tap

15.09.2012 - 21:20 TAP-Win32 Driver Version 9.9

15.09.2012 - 21:20 TAP-Win32 MTU=1500

15.09.2012 - 21:20 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.4.0.170/255.255.255.252 on interface {4360408B-BEBC-43A7-97E3-29F3836A8E35} [DHCP-serv: 10.4.0.169, lease-time: 31536000]

15.09.2012 - 21:20 Successful ARP Flush on interface [28] {4360408B-BEBC-43A7-97E3-29F3836A8E35}

15.09.2012 - 21:20 TEST ROUTES: 2/2 succeeded len=1 ret=1 a=0 u/d=up

15.09.2012 - 21:20 C:\WINDOWS\system32\route.exe ADD 31.193.12.98 MASK 255.255.255.255 192.168.1.1

15.09.2012 - 21:20 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4

15.09.2012 - 21:20 Route addition via IPAPI succeeded [adaptive]

15.09.2012 - 21:20 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.4.0.169

15.09.2012 - 21:20 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4

15.09.2012 - 21:20 Route addition via IPAPI succeeded [adaptive]

15.09.2012 - 21:20 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.4.0.169

15.09.2012 - 21:20 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4

15.09.2012 - 21:20 Route addition via IPAPI succeeded [adaptive]

15.09.2012 - 21:20 C:\WINDOWS\system32\route.exe ADD 10.4.0.1 MASK 255.255.255.255 10.4.0.169

15.09.2012 - 21:20 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4

15.09.2012 - 21:20 Route addition via IPAPI succeeded [adaptive]

15.09.2012 - 21:20 Initialization Sequence Completed

15.09.2012 - 21:20 Starting Management Interface...

15.09.2012 - 21:20 Checking...

15.09.2012 - 21:21 Offline.

this is with all server

[Staff 10118]

  Quote

It finally working again, for the first time since yesterday. Thanks! What did you do to fix the problem?

Hello!

The backend server was replying to VPN servers but incorrectly and it also had a low load. So the VPN servers assumed that the 1st backend server they queried was ok and would not try a connection to the subsequent backend server. On the contrary the primary frontend (website etc.) correctly connected to a different backend server (the backend servers have a clustered database so they are constantly "aligned").

The result was a refusal of any new connection from the VPN servers, while the website was still up. Another detrimental consequence was that the monitoring system did not detect any problem, so it did not send any urgent warning message to the techies.

Some changes have been applied on the backend server which had this problem. Since it has happened for the first time after we implemented, some months ago, a clustered database, we're still investigating to gain a deeper understanding of the issue.

Kind regards

[Staff 10118]

  Quote

Hello

15.09.2012 - 21:20 Initialization Sequence Completed

15.09.2012 - 21:20 Starting Management Interface...

15.09.2012 - 21:20 Checking...

15.09.2012 - 21:21 Offline.

this is with all server

Hello!

The connections is correctly established but the check from the Air client fails. Usually there are two main reasons for this:

- the connection drops immediately after it has been established, OR

- after the connection the client can't access anymore airvpn.org for the security check of established connection

Can you please try a connection directly with OpenVPN, or with the OpenVPN GUI? When you have connected (or tried a connection) with OpenVPN, can you please send us the output of the commands "route print" and "ipconfig /all" (from a command prompt or the PowerShell)?

Kind regards

[FPyro 2]

Hi!

No problems here all day!

I'm connecting to Tauri with TCP:80 using Viscosity. Not tried with the AirClient though.

Anyhow, I almost never used to connect with TCP, but it's MUCH more stable. I get no drops in connectivity and much more stable ping. The speeds are somewhat slower, and they are REALLY slow when using a far-away server, which is a shame.

With UDP I used to get random drops of the connection...like 0 upload for 10 ot do seconds...which is SO annoying in games and calls

There is basically no advantage to using the AirClient and using the OpenVPN Gui directly connects me faster somehow...no checking for 30 seconds...

What happens during the "checking" phase anyway?

Thanks a lot

[Staff 10118]

  Quote

Hi!

What happens during the "checking" phase anyway?

Thanks a lot

Hello!

In the "Checking" phase the Air client asks airvpn.org "Which IP address do you see me connecting from?". The frontend replies and if the IP address is one of the VPN servers exit-IP addresses the Air client is sure that the tunnel is working. If the IP address is not one of them, the Air client starts a new connection.

Kind regards