SparkLabs Forum.

Community Help.


Cannot complete connection on WIFI - HP 840 G3

I work for the IT department at a state university, and have been having trouble trying to support a user who is trying to work from home using the Viscosity VPN client. When I attempt the same procedure the user does, I see the same results. The user and myself have no problem using the VPN client at work (where it is still required, as our target network is not on the LAN), and I have tested the VPN at home when wired to Ethernet, with success. It is only when we are wireless that we cannot complete the connection phase.

When attempting to connect wirelessly, the log shows no faults or failures. What we observe is that when the VPN client flushes the ARP of the interface, the WIFI adapter drops the connection to the WAP, and the VPN disconnects. We have tried using a USB wifi dongle with no success, but the same dongle works on a Dell laptop that has no issues connecting wirelessly.

We initially assumed our home network needed some firewall rules to allow the VPN to work, until the discovery that it worked fine on the Ethernet on the same network.

Our NOC says the server-side VPN logs show nothing out of the ordinary, and that from their end, it looks like the user just disconnected normally, except for the disconnection being only seconds after successful connection.

Here is a log entry from my work laptop (same model as the user, but running Windows 10-1607) during an attempted connection phase:

Dec 20 9:03:53 PM: State changed to Connecting
Dec 20 9:03:53 PM: Viscosity Windows 1.6.7 (1468)
Dec 20 9:03:53 PM: Running on Microsoft Windows 10 Enterprise
Dec 20 9:03:53 PM: Bringing up interface...
Dec 20 9:03:54 PM: Checking reachability status of connection...
Dec 20 9:03:54 PM: Connection is reachable. Starting connection attempt.
Dec 20 9:03:54 PM: OpenVPN 2.3.13 Windows-MSVC [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Nov 4 2016
Dec 20 9:03:54 PM: library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09
Dec 20 9:03:55 PM: UDPv4 link local: [undef]
Dec 20 9:03:55 PM: UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Dec 20 9:03:55 PM: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Dec 20 9:03:58 PM: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Dec 20 9:03:58 PM: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Dec 20 9:03:58 PM: [openvpn1.net.maine.edu] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194
Dec 20 9:04:00 PM: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Dec 20 9:04:00 PM: open_tun, tt->ipv6=0
Dec 20 9:04:00 PM: TAP-WIN32 device [Viscosity VPN] opened: \\.\Global\{819AB0B6-174F-4973-86A2-E4B02126D3BF}.tap
Dec 20 9:04:00 PM: Notified TAP-Windows driver to set a DHCP IP/netmask of 10.96.3.70/255.255.255.252 on interface {819AB0B6-174F-4973-86A2-E4B02126D3BF} [DHCP-serv: 10.96.3.69, lease-time: 31536000]
Dec 20 9:04:00 PM: Successful ARP Flush on interface [13] {819AB0B6-174F-4973-86A2-E4B02126D3BF}
Dec 20 9:04:01 PM: State changed to Disconnecting
Dec 20 9:04:01 PM: State changed to Disconnected

I have searched through the forum here, but only find results related to disconnection also killing wifi, or wifi best-practices. Can someone help?
Hi,

Could you please edit the connection, go to the Advanced tab then add the following command on a new line:

verb 5

Then save the connection and reconnect. This should give a much more information in the log and hopefully point to what is going wrong.

If there is no new information in the log, please try booting into Safe Mode with all other software disabled and see if the issue still occurs.

Regards,
Eric
Apologies for the delay. We are in high gear updating labs on the break.
I have done the verbose change and emailed it back, but I will keep those logs out of the forum.

I will get a chance to test this some more later this week, it seems.

Thank you
3 posts Page 1 of 1

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy