SSL Client broken route entry

possible: sure!
but i don't think so because of than it have to be reproducable - esp. the effect, that sometimes the route will not be set when tunnel comes up; if you restart the tunnel five times sometimes it works on the fourth and not more on the fifth - that makes no sense with a static fw config..
cheers, andre

We have the same problem, but I´ve seen that the routes are set correctly when establishing the tunnel, but deleted after some seconds (looked at netstat -nr directly after green light). Another way to test is to run a "ping -t" on an internal address while starting the tunnel. The pings are getting trough for about 5 to 10 seconds, then the routes are gone....

This is happening on some laptops, not on every laptop, but the installation is the same.

So, what was this about "forcing route.exe" 2 posts ago?

Lars

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.

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