Proble with Windows 7 64bits and OpenVPN
Posted: Tue May 07, 2013 6:15 pm
07 may
All,
I would like to share with you a problem that I have found, which we have been researching with a friend of mine for the past 48 hours and have yet to find a solution.
Where was the problem found?
Windows 7 Home Premium 64 bits (1PC).
Windows 7 Ultimate 64 bits (1PC).
Where WASN'T the problem found?
Windows 7 Ultimate 32 bits
Windows 7 Proffessional 32 bits
Windows XP 32 bits (todas las versiones).
Windows XP 64 bits (todas las versiones).
My experience
In my organization we use OpenVPN to interconnect remote servers to the headquarters, in order to do so, we use PFSense + OpenVPN to control and monitor GNU/Linux servers all over Argentina. In addition to the 24 GNU/Linux servers, there are at least 20 end users who access those servers, but with the VPN client installed on Windows XP. These servers run Web applications, which are queried via browsers, and also many end users run queries from PostgreSQL databases through PGAdmin (port 5432) and server administration is achieved through SSH (port 22).
It's working as expected.
The problem
A couple days ago I had the need to install an OpenVPN client on an end user PC with Windows 7 Home Premium 64 bits. I did the typical “openvpn-install-2.3.1-I005-x86_64” installation.
[*]The OpenVPN GUI is assigned administrator rights.
[*]The OpenVPN GUI is assigned compatibility with Vista SP2.
[*]The Open VPN is connected as usual.
[*]Conectivity is established to a Linux server via SSH as usual.
[*]Queries are made via PGAdmin to a Linux server as usual.
[*]Queries are made to the Web applications (Ports 80 and 8080) and the Web application does not respond. The website does not load the content.
[*]The VPN is disconnected.
[*]All the server and OpenVPN client configurations are checked succesfully.
[*]Conectivity is again established with the OpenVPN client successfully.
[*]I ping the server IP address which I am querying successfully.
[*]Queries are made via PGAdmin to a Linux Server successfully once again.
[*]Conectivity is established to a Linux server via SSH once again
[*]Queries are made to the Web applications (Ports 80 and 8080) and the Web application does not respond. The website does not load the content.
[*]After executing "ping - t" no replies are received.
[*]VPN is disconnected once again.
[*]I connect the VPN again and everything goes "back to normal". However, http://x.x.x.x or http://x.x.x.x:8080 queries are unresponsive because the connection is lost.
About the OpenVPN log and the Operating System
On the other hand, the VPN offers no assistance whatsoever. I've added different types of the "verb" parameters to observe the log's behaviours but there were no modifications. It seems as though the OpenVPN session has simply been disconnected, and after a while, when it detects no session has been established, the connection resets, although, as I stated previously, as soon as I try to make an http petition, the tunnel disconnects again.
System logs do not offer any insight regarding the issue. Windows soes not detect anything out of the ordinary.
The tests we have run
[*]We have checked that the routes were generated executing " route print "
[*]Static routes were configured to observe the behaviour. The results were negative.
[*]We have ensured there are no hidden interfaces which could be causing the traffic to exit the incorrect interface.
[*]Different setings were added to the virtual interface metrics with no success
[*]Tests were performed with the TAP driver, without uninstalling the VPN client, the TAP driver was uninstalled without any positive changes
[*]Different MTU values were tested on the TAP interface.
[*]The Firewall was inactive at all times and no antivirus or third party software interfered
[*]UAC was disabled unsuccesfully ( https://en.wikipedia.org/wiki/User_Account_Control )
[*]We have observed that when making http petitions, the tunnel is dropped, but the routes remain in the table
[*]Although I have tried these suggested parameters “add route-method exeroute-delay 2” I have not see any positive results.
Clients Tested
openvpn-install-2.3.1-I005-i686
openvpn-install-2.3.1-I005-x86_64
openvpn-2.2.2-install
Server Configuration ( /var/etc/openvpn inside PfSense)
Setting the clients.
Route Print
Since I'm very grateful for your comments and all they can suggest and contribute.
Greetings!
All,
I would like to share with you a problem that I have found, which we have been researching with a friend of mine for the past 48 hours and have yet to find a solution.
Where was the problem found?
Windows 7 Home Premium 64 bits (1PC).
Windows 7 Ultimate 64 bits (1PC).
Where WASN'T the problem found?
Windows 7 Ultimate 32 bits
Windows 7 Proffessional 32 bits
Windows XP 32 bits (todas las versiones).
Windows XP 64 bits (todas las versiones).
My experience
In my organization we use OpenVPN to interconnect remote servers to the headquarters, in order to do so, we use PFSense + OpenVPN to control and monitor GNU/Linux servers all over Argentina. In addition to the 24 GNU/Linux servers, there are at least 20 end users who access those servers, but with the VPN client installed on Windows XP. These servers run Web applications, which are queried via browsers, and also many end users run queries from PostgreSQL databases through PGAdmin (port 5432) and server administration is achieved through SSH (port 22).
It's working as expected.
The problem
A couple days ago I had the need to install an OpenVPN client on an end user PC with Windows 7 Home Premium 64 bits. I did the typical “openvpn-install-2.3.1-I005-x86_64” installation.
[*]The OpenVPN GUI is assigned administrator rights.
[*]The OpenVPN GUI is assigned compatibility with Vista SP2.
[*]The Open VPN is connected as usual.
[*]Conectivity is established to a Linux server via SSH as usual.
[*]Queries are made via PGAdmin to a Linux server as usual.
[*]Queries are made to the Web applications (Ports 80 and 8080) and the Web application does not respond. The website does not load the content.
[*]The VPN is disconnected.
[*]All the server and OpenVPN client configurations are checked succesfully.
[*]Conectivity is again established with the OpenVPN client successfully.
[*]I ping the server IP address which I am querying successfully.
[*]Queries are made via PGAdmin to a Linux Server successfully once again.
[*]Conectivity is established to a Linux server via SSH once again
[*]Queries are made to the Web applications (Ports 80 and 8080) and the Web application does not respond. The website does not load the content.
[*]After executing "ping - t" no replies are received.
[*]VPN is disconnected once again.
[*]I connect the VPN again and everything goes "back to normal". However, http://x.x.x.x or http://x.x.x.x:8080 queries are unresponsive because the connection is lost.
About the OpenVPN log and the Operating System
On the other hand, the VPN offers no assistance whatsoever. I've added different types of the "verb" parameters to observe the log's behaviours but there were no modifications. It seems as though the OpenVPN session has simply been disconnected, and after a while, when it detects no session has been established, the connection resets, although, as I stated previously, as soon as I try to make an http petition, the tunnel disconnects again.
System logs do not offer any insight regarding the issue. Windows soes not detect anything out of the ordinary.
The tests we have run
[*]We have checked that the routes were generated executing " route print "
[*]Static routes were configured to observe the behaviour. The results were negative.
[*]We have ensured there are no hidden interfaces which could be causing the traffic to exit the incorrect interface.
[*]Different setings were added to the virtual interface metrics with no success
[*]Tests were performed with the TAP driver, without uninstalling the VPN client, the TAP driver was uninstalled without any positive changes
[*]Different MTU values were tested on the TAP interface.
[*]The Firewall was inactive at all times and no antivirus or third party software interfered
[*]UAC was disabled unsuccesfully ( https://en.wikipedia.org/wiki/User_Account_Control )
[*]We have observed that when making http petitions, the tunnel is dropped, but the routes remain in the table
[*]Although I have tried these suggested parameters “add route-method exeroute-delay 2” I have not see any positive results.
Clients Tested
openvpn-install-2.3.1-I005-i686
openvpn-install-2.3.1-I005-x86_64
openvpn-2.2.2-install
Server Configuration ( /var/etc/openvpn inside PfSense)
Code: Select all
dev ovpns1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp-server
cipher BF-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local x.x.x.x
tls-server
server 192.168.15.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
tls-verify /var/etc/openvpn/server1.tls-verify.php
lport 443
management /var/etc/openvpn/server1.sock unix
max-clients 120
client-to-client
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo
client-config-dir /usr/local/www/ccdCode: Select all
dev tun
persist-tun
persist-key
proto tcp-client
cipher BF-CBC
tls-client
client
resolv-retry infinite
remote x.x.x.x 443
tls-remote OpenVPN
pkcs12 pfsense-TCP-443.p12
tls-auth pfsense-TCP-443-tls.key 1
comp-lzo
nobind
Code: Select all
===========================================================================
ILista de interfaces
18...00 ff 28 1c c5 11 ......TAP-Windows Adapter V9 #2
14...00 1a 73 84 6d 8f ......Adaptador de red 802.11g Broadcom
1...........................Software Loopback Interface 1
16...00 00 00 00 00 00 00 e0 Adaptador de tunelización Teredo de Microsoft
31...00 00 00 00 00 00 00 e0 Adaptador ISATAP de Microsoft #4
33...00 00 00 00 00 00 00 e0 Adaptador ISATAP de Microsoft #6
===========================================================================
IPv4 Tabla de enrutamiento
===========================================================================
Rutas activas:
Destino de red Máscara de red Puerta de enlace Interfaz Métrica
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.11 25
127.0.0.0 255.0.0.0 En vínculo 127.0.0.1 306
127.0.0.1 255.255.255.255 En vínculo 127.0.0.1 306
127.255.255.255 255.255.255.255 En vínculo 127.0.0.1 306
192.168.0.0 255.255.255.0 En vínculo 192.168.0.11 281
192.168.0.11 255.255.255.255 En vínculo 192.168.0.11 281
192.168.0.255 255.255.255.255 En vínculo 192.168.0.11 281
192.168.15.0 255.255.255.0 x.x.x.x 192.168.15.141 31
192.168.15.140 255.255.255.252 En vínculo 192.168.15.141 286
192.168.15.141 255.255.255.255 En vínculo 192.168.15.141 286
192.168.15.143 255.255.255.255 En vínculo 192.168.15.141 286
224.0.0.0 240.0.0.0 En vínculo 127.0.0.1 306
224.0.0.0 240.0.0.0 En vínculo 192.168.15.141 286
224.0.0.0 240.0.0.0 En vínculo 192.168.0.11 281
255.255.255.255 255.255.255.255 En vínculo 127.0.0.1 306
255.255.255.255 255.255.255.255 En vínculo 192.168.15.141 286
255.255.255.255 255.255.255.255 En vínculo 192.168.0.11 281
===========================================================================
Rutas persistentes:
Ninguno
IPv6 Tabla de enrutamiento
===========================================================================
Rutas activas:
Cuando destino de red métrica Puerta de enlace
16 58 ::/0 En vínculo
1 306 ::1/128 En vínculo
16 58 2001::/32 En vínculo
16 306 2001:0:9d38:6ab8:3c43:2ed8:3f57:fff4/128
En vínculo
18 286 fe80::/64 En vínculo
14 281 fe80::/64 En vínculo
16 306 fe80::/64 En vínculo
16 306 fe80::3c43:2ed8:3f57:fff4/128
En vínculo
18 286 fe80::c0e1:d176:97a1:a944/128
En vínculo
14 281 fe80::f541:2c90:68d2:dae7/128
En vínculo
1 306 ff00::/8 En vínculo
18 286 ff00::/8 En vínculo
14 281 ff00::/8 En vínculo
16 306 ff00::/8 En vínculo
===========================================================================
Rutas persistentes:
Ninguno
Greetings!
