This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL Remote Access

Sigh.

I had looked through all the recent posts that mentioned problems connecting via the SSL client, tried the solutions, to date nothing has solved the problem.

When I first enabled the SSL VPN a few years ago, everything worked fine.  Slick as a whistle.  Then I had people calling in stating that after they restarted their computer they were getting connected (light was green) but they couldn't access any network resources.  A re-install of the client ALYWAYS corrected this.  Annoying, but a "quick fix".

Well, now that has stopped working.

You can connect, get an IP address(gateway is blank - can this be correct?) but you cannot ping any network resource by IP address or name.  We don't run WINS, but that shouldn't affect the direct IP address issues.

Am using the default VPN Pool(SSL) range, it is allowed in the Network Services | DNS section, I have created a MASQ for that range (tried with the internal interface, then the external, then both).

I have checked the "Automatic Fiewall Rules" box.

I see the traffic from my origionating IP address.  I see myself listed it the remote users.

I have current support and have submitted a ticket, just hoping to get this solved over the weekend and figured I would give this a try.

Any help would be appreciated.

Thanks,

(In case the sig is wrong - Running 8.202 )

This thread was automatically locked due to age.

Parents

0 Scott_Klassen over 13 years ago

But, just to follow the instructions posted, I exited the client. ( Right-click / Exit ) I hope that is enough to stop it.
Use Task Manager and show processes from all users to make certain that anything related to OpenVPN is no longer running.

Everything on my system runs "As admin"
Not quite true with UAC.  When you log into windows, all of your permissions are written into a token.  With older versions of windows, you only had one token, so when you logged in using an administrative account everything ran as admin.  Starting with Vista, you get two tokens.  The default one, which holds standard non-admin permissions, then there's a separate admin permission token.  The elevated admin permission one is only used, on a program by program basis, when Run as Admin/UAC is used.

There's an easy way to test this.  After you start the VPN connection, from a windows command prompt on the client run "route print" (without quotes) and make certain that the VPN route is being written correctly.

If so, there's four other thing that we can look at:
1)  Uninstall, then re-install the VPN software
2)  In WebAdmin>>Remote Access>>SSL, make certain that Local Networks contains your Internal (Network) and that the Automatic Firewall Rules box is checked.
3)  Do you have a firewall enabled on the client system that may be blocking traffic?
4)  Are there any conflicts in addressing between the Astaro Internal LAN (network), the SSL VPN Pool, and the internal LAN of the network that the remote client is on?

@BAlfson:
maybe the new client already has the fix
No it doesn't.  The big problem with the OpenVPN dev folks is that they are all die-hard "wouldn't touch windows if my life depended on it" linux people.  This is why it has taken over four years for them to even consider implementing a fix.  All they really need to do is to stop trying to do their stuff using route.exe and to instead use the API.  The fix is scheduled for the 3.x version of the client, where they are are also bundling a ton of other changes (another big reason for the delay).  It's a shame that there isn't an alternative, but OpenVPN is the only game in town when it comes to an open-source SSL VPN implementation with a windows client.

The next major version of Astaro, 9.x, is set to have this fixed one way or another.  Whether this will be done by the new OpenVPN client or if Astaro is rolling their own custom client (like another UTM vendor tried with limited success), I'm not certain.

Update:  Astaro's VPN guru is creating his own custom client.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 Scott_Klassen over 13 years ago

But, just to follow the instructions posted, I exited the client. ( Right-click / Exit ) I hope that is enough to stop it.
Use Task Manager and show processes from all users to make certain that anything related to OpenVPN is no longer running.

Everything on my system runs "As admin"
Not quite true with UAC.  When you log into windows, all of your permissions are written into a token.  With older versions of windows, you only had one token, so when you logged in using an administrative account everything ran as admin.  Starting with Vista, you get two tokens.  The default one, which holds standard non-admin permissions, then there's a separate admin permission token.  The elevated admin permission one is only used, on a program by program basis, when Run as Admin/UAC is used.

There's an easy way to test this.  After you start the VPN connection, from a windows command prompt on the client run "route print" (without quotes) and make certain that the VPN route is being written correctly.

If so, there's four other thing that we can look at:
1)  Uninstall, then re-install the VPN software
2)  In WebAdmin>>Remote Access>>SSL, make certain that Local Networks contains your Internal (Network) and that the Automatic Firewall Rules box is checked.
3)  Do you have a firewall enabled on the client system that may be blocking traffic?
4)  Are there any conflicts in addressing between the Astaro Internal LAN (network), the SSL VPN Pool, and the internal LAN of the network that the remote client is on?

@BAlfson:
maybe the new client already has the fix
No it doesn't.  The big problem with the OpenVPN dev folks is that they are all die-hard "wouldn't touch windows if my life depended on it" linux people.  This is why it has taken over four years for them to even consider implementing a fix.  All they really need to do is to stop trying to do their stuff using route.exe and to instead use the API.  The fix is scheduled for the 3.x version of the client, where they are are also bundling a ton of other changes (another big reason for the delay).  It's a shame that there isn't an alternative, but OpenVPN is the only game in town when it comes to an open-source SSL VPN implementation with a windows client.

The next major version of Astaro, 9.x, is set to have this fixed one way or another.  Whether this will be done by the new OpenVPN client or if Astaro is rolling their own custom client (like another UTM vendor tried with limited success), I'm not certain.

Update:  Astaro's VPN guru is creating his own custom client.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data