Unstable VPN Tunnel

Got a problem with Viscosity or need help? Ask here!

pippobaudo

Posts: 6
Joined: Wed Nov 14, 2012 2:19 am

Post by pippobaudo » Sat Mar 02, 2013 1:06 am
Hello
I've a strange behaviour with viscosity and windows firewall on a windows 7 machine: the vpn tunnel is unstable it automatically reconnect.

I've this setup: Client with Viscosity ---> OPENVPN SERVER ---> WEBSERVER
- VPN uses certificate to perform authentication
- Web Server requires SSL CLient authenticaiton (same VPN certificate is used)
- WEB Server run an Applet that communicate with the server on some specific ports

On my machine with Windows 7 the vpn and the access to the server and everything works well.

As soon as I switch on the windows firewall I get a reconnection problem:

mar 1 01:33:04: Connection reset, restarting [-1]
mar 1 01:33:04: SIGUSR1[soft,connection-reset] received, process restarting
mar 01 01:33:04: State changed to Connecting

I also realized that this reconneciton sometimes happen when the Java Applet is in some way activate.


Do you have any idea?

The full logs:

mar 01 01:27:36: State changed to Connecting
mar 01 01:27:36: Viscosity 1.4.2 (1178)
mar 01 01:27:36: Running on Microsoft Windows 7 Professional
mar 01 01:27:36: Bringing up interface...
mar 01 01:27:43: Controllo la raggiungibilità della connessione…
mar 01 01:27:46: Connessione raggiungibile, inizio connessione.
mar 01 01:27:46: OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Jan 4 2012
mar 1 01:29:14: PKCS#11: Adding PKCS#11 provider 'C:\Windows\System32\eTPKCS11.dll'
mar 1 01:29:14: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
mar 1 01:29:14: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
mar 1 01:29:20: Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
mar 1 01:29:20: LZO compression initialized
mar 1 01:29:20: Attempting to establish TCP connection with xxx.xxx.xxx.xxx
mar 1 01:29:20: TCP connection established with xxx.xxx.xxx.xxx
mar 1 01:29:20: TCPv4_CLIENT link local: [undef]
mar 1 01:29:20: TCPv4_CLIENT link remote: xxx.xxx.xxx.xxx
mar 1 01:29:20: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
mar 1 01:29:26: [VPN_Gateway] Peer Connection Initiated with XXX.XXX.XXX.XXX
mar 1 01:29:29: TAP-WIN32 device [VPN_CERT] opened: \\.\Global\{DA8BC8F6-6C4E-4FD5-9267-E606F7092B07}.tap
mar 1 01:29:29: Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.0.8.6/255.255.255.252 on interface {DA8BC8F6-6C4E-4FD5-9267-E606F7092B07} [DHCP-serv: 10.0.8.5, lease-time: 31536000]
mar 1 01:29:29: Successful ARP Flush on interface [27] {DA8BC8F6-6C4E-4FD5-9267-E606F7092B07}
mar 1 01:29:34: Initialization Sequence Completed
mar 01 01:29:34: State changed to Connected


mar 1 01:33:04: Connection reset, restarting [-1]
mar 1 01:33:04: SIGUSR1[soft,connection-reset] received, process restarting
mar 01 01:33:04: State changed to Connecting





TIA

Eric

User avatar
Posts: 905
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon Mar 04, 2013 6:48 pm
Hi pippobaudo,

Adding an exception to your firewall for openvpn will hopefully solve this problem. You will need to add exceptions for the following files:

C:\Program Files\Viscosity\Resources\openvpn.exe
C:\Program Files\Viscosity\Resources\OpenVPN2.3\openvpn.exe

To add a firewall exception for the above if you are unsure:

Go to the Control Panel
Double click Windows Firewall
On the left, select "Allow a program through Windows Firewall"
Click the Change Settings button if it isn't already greyed out
Click "Allow another app..."
Click browse and locate one of the above files, select it and click OK, click Add.
The file will then be selected in the list, make sure both check boxes for Private and Public are ticked.
Repeat the above 4 steps for the other file.
Click OK to all other windows.

This should hopefully resolve the issues you are having. It may not though. It is definitely a better idea to have the firewall active on the adapter before you initiate a connection if you can.

Regards,

Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

pippobaudo

Posts: 6
Joined: Wed Nov 14, 2012 2:19 am

Post by pippobaudo » Sat Mar 09, 2013 3:21 am
thanks Eric
I made this configuration but without success.
Today I've got this new message: "read TCPv4_CLIENT: Permission denied (WSAEACCES) (code=10013)"

I'm trying to solve the problem, but seems difficult

Regards
pippobaudo

Eric

User avatar
Posts: 905
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon Mar 11, 2013 1:47 pm
Hi pippobaudo,

Are these messages appearing in your client or server log? Can you please provide a copy of the entire log so we can have a look through it for any clues. Also please check your server log to see if it displays any messages at the same time you receive errors on the client.

Regards,

Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

pippobaudo

Posts: 6
Joined: Wed Nov 14, 2012 2:19 am

Post by pippobaudo » Wed Mar 13, 2013 4:16 am
I've attached the client logs.
Few seconds after the "event" the server logged the following data:

Mar 12 16:27:04 openvpn[33465]: TCP/UDP: Closing socket
Mar 12 16:27:04 openvpn[33465]: vpnuser/xxx.xxx.xxx.xxx:pppp SIGUSR1[soft,connection-reset] received, client-instance restarting
Mar 12 16:27:04 openvpn[33465]: vpnuser/xxx.xxx.xxx.xxx:pppp Connection reset, restarting [-1]


TIA

pippobaudo
Attachments
ClientLogs.zip
(16.89 KiB) Downloaded 365 times

pippobaudo

Posts: 6
Joined: Wed Nov 14, 2012 2:19 am

Post by pippobaudo » Fri Mar 15, 2013 3:56 am
Hi

I made additional tests using different protocols: SCP, HTTP

I realised that the sigusr1 and the reconnection take place as soon as I start a file download.

Regards

Eric

User avatar
Posts: 905
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Tue Mar 19, 2013 5:25 pm
Hi pippobaudo,

The logs are showing the disconnect is happening because something is blocking traffic being sent/received by the client. This could be caused by any firewall, antivirus or antispyware software that is doing a bad job of blocking traffic. It could also be your modem or router's inbuilt firewall. It appears you have cut a large chunk of the initial connect out of the log you posted, which could also show any warnings you might need to fix (mismatches between the server and client for example).

I'm afraid there is nothing Viscosity is going to be able to do to solve this particular problem. I would highly recommend disabling every piece of security software you have and seeing if the connection remains stable, then slowly introducing the software back to see if you can replicate the problem.

Regards,

Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
7 posts Page 1 of 1