SSL Client broken route entry

Hi,

I've had the same issue for a while as well.  Its totally random and only affects some users and not others.  

I manually upgraded the OpenVPN adapter and client software on a couple of XP and Vista clients and so far have not seen the issue reappear. 

But as everyone has stated, its almost impossible to reproduce so it may just be coincidence.

The version of OpenVPN i'm using is 2.1_rc15

OpenVPN Downloads

AndrewD

Has this been resolved?  Andre, is it possible that you have a hardware issue?  I mean solving the problem by changing the MTU on the Astaro interface or shifting it to half-duplex or to a fixed bit rate instead of 10/100/1000?

Cheers - Bob

no hw issue in the direct meaning - different clients and servers involved;
but - i'm not sure - it looks for me like related to the server-load: it happens more often on one of our main gateways with more users working through and also more often on working hours...
may be that's related to the MTU/connection settings too, but there was no chance to deal around with until now...
will keep you up2date - if this isn't orphaned with 7.4 :-)
rgds, a.

We have exact the same problem on some of our clients with xp installed. The traffic is working sometimes and sometimes not. The traffic light is still green but routes no traffic. We had no problems with these xp clients before so it feels like this has started after we upgraded the astaro, now version 7.305. Vista clients we aways have problems with but using the route.exe settings they usually are working. Maybe this will work with xp also, i will try it next time. 

Instructions:

SSL client connects but no traffic routes 
Windows Vista error 
 
After connecting with the ssl client the connection status shows green. 
However traffic flow doesn't appear to occur. This is due to the route 
commands not having administrative priveleges on windows systems such as 
Windows Vista or XP when run as a limited user account. 
 
Setting administrator rights to a program:
STEP ONE
=======================
In Wordpad, open the following file: c:\Program Files\Astaro\Astaro SSL VPN 
Client\config\fw.misti.com.username.opvn (this may show as 
fw.misti.com.username)
Then, go to the bottom of the file and add the following lines:
route-method exe
route-delay 2
STEP TWO
=======================
Next up is to change the Astaro VPN client to always run as an 
administrator. Go to this location with Windows Explorer:
c:\Program Files\Astaro\Astaro SSL VPN Client\bin\
Highlight the file openvpn-gui.exe and then right-click. Choose properties. 
Click the "Compatibility" tab and check the checkbox "Run this program as 
an administrator" and click ok.
STEP THREE
======================
We now need to remove the Astaro VPN Client from startup, otherwise it will 
be blocked by Windows Vista because of "Administrative Behavior".
- Click START ---> RUN and type msconfig and then click OPEN
- Click the STARTUP Tab and uncheck openvpn-gui
- When you restart your PC again, it will ask if you want to run msconfig 
again, just check the appropriate checkboxes so it will not do that in the 
future.
STEP FOUR
=======================
Click START ---> ALL PROGRAMS ---> ASTARO SSL VPN ---> ASTARO VPN Client
Right click the traffic light and choose connect.
After authenticating, you should be able to access network resources

Hello,

I tried both options, installing the openvpn client (last version 2.1_rc15) and to use the route.exe (user with admin rights).
Both didn't worked, still routes disappearing after establisching the connection, not every time, but often.

Maybe it's realy a problem with the hardware, something with MTU?

Lars

Next Try: I added the option 
  route-delay 20
with a number of 20 and greater, this worked for to laptop, but might fail for others....

Lars

Lars, unless I'm looking at an outdated man page, shouldn't that be "route-delay" and not "route_delay"?

What I have says:

--route-delay [n] [w]

Delay n seconds (default=0) after connection establishment, before adding routes. If n is 0, routes will be added immediately upon connection establishment. If --route-delay is omitted, routes will be added immediately after TUN/TAP device open and --up script execution, before any --user or --group privilege downgrade (or --chroot execution.) 

This option is designed to be useful in scenarios where DHCP is used to set tap adapter addresses. The delay will give the DHCP handshake time to complete before routes are added. 

On Windows, --route-delay tries to be more intelligent by waiting w seconds (w=30 by default) for the TAP-Win32 adapter to come up before adding routes. 

I'll have to give this one a try to see if it alleviates the symptom on the clients where I'm seeing it. In the interim, I've rolled the problem ones back to the IPSec VPN client, though I know it's only a matter of time before one of them will be behind a NAT router which blocks the IPSec packets... 

OpenVPN 2.0.x man page is here. 2.1.x beta man page is here. (N.B.: as of 10:07am EST, openvpn.net seems to be inaccessible from my location, however, Google's cache of the above pages is located here and here, respectively.

Lars, unless I'm looking at an outdated man page, shouldn't that be "route-delay" and not "route_delay"?

What I have says:

--route-delay [n] [w]

Delay n seconds (default=0) after connection establishment, before adding routes. If n is 0, routes will be added immediately upon connection establishment. If --route-delay is omitted, routes will be added immediately after TUN/TAP device open and --up script execution, before any --user or --group privilege downgrade (or --chroot execution.) 

This option is designed to be useful in scenarios where DHCP is used to set tap adapter addresses. The delay will give the DHCP handshake time to complete before routes are added. 

On Windows, --route-delay tries to be more intelligent by waiting w seconds (w=30 by default) for the TAP-Win32 adapter to come up before adding routes. 

I'll have to give this one a try to see if it alleviates the symptom on the clients where I'm seeing it. In the interim, I've rolled the problem ones back to the IPSec VPN client, though I know it's only a matter of time before one of them will be behind a NAT router which blocks the IPSec packets... 

OpenVPN 2.0.x man page is here. 2.1.x beta man page is here. (N.B.: as of 10:07am EST, openvpn.net seems to be inaccessible from my location, however, Google's cache of the above pages is located here and here, respectively.

Lewis, our customers all use Windows clients and servers.  We've installed L2TP over IPSec for Remote Access for years.  I've never personally been blocked from accessing the VPN to my office and through to my desktop from any Astaro customer site even though they all NAT.  I've never had a problem from my office when accessing our customers' Windows servers via VPN.   I haven't heard any complaints about being blocked.

We don't do the IPSec Remote Access, but wouldn't the NAT-T selection on the 'Advanced' tab resolve the issue you mention?

Thanks for your thoughts - Bob

you're right, I changed my post (used the option in the config file).

Lars

OK, if adding more time to the "wait" works, then isn't that confirmation of the suspicion that the real problem is hardware?

Maybe, but what hardware? You mean the network devices? It´s happening over LAN and WLAN. We have the problems with the Fujitsu Siemens S7220 series.

Looking to the drivers page it´s a Marvel Yukon 88E8055 (LAN) and Intel WiFi Link 5300 AGN (WLAN).


Lars

I just figure that if only a small percentage of Astaro sites need the "wait" command, it seems like the problem must be hardware somewhere.  The Ethernet NIC in the server running Astaro, the cable connecting that Astaro NIC to the device in front of it, etc.  It could be outside one's control, so checking the MTU might make a difference.  But, I agree that it's not worth the time to track down the cause if there's no slowness in the connection.

Cheers - Bob

Considering that this worked prior to an upgrade to Astaro, was broken afterward, and continues to work on the same hardware under non-Windows OSes (Linux does not suffer, even in dual-boot configurations), this appears to be a Windows-specific software issue related to the timing of issuing the route command.

All of this points to something I've felt in my heart for quite some time: the Microsoft IP stack is broken. [;)]

I had the same issue. On my client it was AVG antivirus that installed somekind of traffic analyser. It did that on the Astaro Interface also. When i removed that the routing started to work again.

Does anybody know if this has been resolved in the upcoming 7.400?
We have this problem on a big number of installations, and it`s getting to a point where customers are considering other solutions than Astaro.

I know that for some, this problem doesn`t exist, and for others it is a small matter. But from our point of view, 80% of all installations on XP sp3, seem to have this problem either constantly or intermittently.
But for installations where the employee count exceeds 2000, a small "hack" simply won`t do the trick. It needs to be adressed.