SSL Remote Access

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).

If a masq rule "VPN Pool -> Internal' is necessary, that often indicates a misconfiguration - specifically that host definitions have been bound to the Internal interface instead of 'Interface: >'.

The DNS configuration for remote access clients is set in 'Remote Access >> Advanced'.

If the clients are running Vista or Win7, they must start the SSL client with 'Run as administrator'. In WinXP, the SSL Adapter must be first in the binding order on the PC.

Did any of that help?

Cheers - Bob

*** Sorry, the point was that no matter what interface I bind them to, it does not work.  Prior to today, when I started monkeying with things in a attempt to get it to work, the VPN network was MASQed to the outside interface.  And it worked. ****

The DNS configuration for remote access clients is set in 'Remote Access >> Advanced'.

If the clients are running Vista or Win7, they must start the SSL client with 'Run as administrator'. In WinXP, the SSL Adapter must be first in the binding order on the PC.

***  It is Windows 7 Home PRemium (64).  Must run as administrator?  I have never had to do this back when it did work, and it makes no difference now.  Still doesn't work.  If that were a requirement, why would they write the software so that it auto starts when someone logs on? **


Did any of that help?

***  Unfortunately, no.  ***


Cheers - Bob[/QUOTE]

Must run as administrator? I have never had to do this back when it did work, and it makes no difference now. Still doesn't work. If that were a requirement, why would they write the software so that it auto starts when someone logs on?

Because "they" didn't write the software for the SSL VPN Client, the folks at OpenVPN did and this is a known issue due to stricter permission requirements starting with Win Vista and the client not being coded to work with UAC properly.  

Unless you are logged in with an administrator account (or one in the local Network Configuration Operators Group) AND use Run As Administrator, the Client is not able to make needed changes to the routing table.

You need to remove the client from starting on boot as it won't work then because UAC elevation is skipped.  Then the process will be 1)  Start Client using right-click Run as Administrator.  2)  Allow at UAC prompt.  3)  Connect.

https://support.astaro.com/support/index.php/SSL_VPN_without_full_administrative_user_rights_under_Windows_7

The OpenVPN folks supposedly are almost done with a client that can actually play nicely/work with UAC and write routes without the additional steps.  They have had to recode almost the entire thing from scratch to make this happen.  I've heard late this year or early next.

You're right to have the VPN Pool masqed for traffic going out the External interface.  I should have explained that better.  When people have made the mistake of binding an internal server's Host definition to the Internal interface, the bandaid many find is to masq the VPN Pool to the internal network.

In a coming version of the OpenVPN client, the 'Run as administrator' requirement won't be there, but it definitely is now as, otherwise, the client doesn't have the authority to set routes in Win7 or Vista.  If route print shows the routes are set, then maybe the new client already has the fix.

Does the Firewall log show any blocks of the remote IP you were assigned?  If not, is there anything unusual in the Intrusion Prevention log?

Cheers - Bob
PS Thanks for that info, Scott.

"How to use Astaro SSL VPN Client under Windows 7 with non-administrative user rights and UAC"


My user account has administrative rights, I have disabled "UAC".  So, I guess that explains why it "used to work".

But, just to follow the instructions posted, I exited the client. ( Right-click / Exit )  I hope that is enough to stop it.

I then found the program under the start menu, right-clicked and told it to "Run as administrator ".

Same results.  Connects successfully, will not access any network resource via name nor IP address.

In the log I see an entry for every network in my enterprise:

Sat Oct 15 16:46:57 2011 C:\WINDOWS\system32\route.exe ADD 172.16.64.0 MASK 255.255.240.0 10.242.2.5
Sat Oct 15 16:46:57 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Sat Oct 15 16:46:57 2011 Route addition via IPAPI succeeded [adaptive]


Since the text " succeeded" is all through the log, I took that to mean that the route was created.  My bad.

Once upon a time, the current configuration worked.  Those days are gone.  Now I just need a little help trying to figure out what went wrong.  "Running as admin" is not the fix in this case.  Everything on my system runs "As admin".  And again, I did actually follow the instructions given and stop the client, then manually "Run as Admin"

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.

at how many computers you have installed the VPN software ?
at One or more?
if several, then all the same story?

" Does the Firewall log show any blocks of the remote IP you were assigned?" 

Does not show the IP address in the log at all.  I made a VPN Pool (SSL) Any-Any - Log packet as rule 1 and watched.  Nothing from that address or that rule.

" If not, is there anything unusual in the Intrusion Prevention log "

I turned Intrusion Prevention off.  No difference.

I did a route print and it shows the routes being added. (Attached)

I can ping the ip address (10.242.2.6 ) from the computer I am running the client on, but the route table shows the gateway as "On-Link"? What is shows as a gateway to my remote networks is 10.242.6.5 but this address is un-reachable.

I have tried to do a tracert from the firewall itself to the IP my client was assigned from the box and it is unreachable.

Any ideas?

If none of the four things I suggested in my last post pan out, you can given an alternate client a try.  There's three that I know of right now for OpenVPN, but they are all beta projects and may be very buggy.

https://community.sophos.com/products/unified-threat-management/astaroorg/f/58/t/54141

OpenVPN GUI - Browse /Snapshot Binaries at SourceForge.net

{Creativity} How many have I installed personally?  About 5 or 6.  That is all the computers that I own.  As to my school district, I would say that there are between 25 - 50 people out there trying to connect.

All say the same story.  Currently, connect but can't get anywhere.  Previously, would connect fine but have to re-install the client after a restart.  Windows XP/Vista/Win 7 combination.  Mine were all Vista / Win 7.

As to the UAC stopping the connection from creating the routes, yes, absolutely. IF you have the UAC set to default, then you have to "Run as admin". No question.  IF you have the UAC set to the bottom position (Never Notify), it makes no difference how you start it.  It will create the routes. ( See attached screen shots )  But again, just to be clear, I DID try "Run as Administrator" also.  No different from just turning UAC off.

As to what position all my users have their UAC set to,I have no idea.  Trying to get mine to work right now.  Mine is off, client is reporting "0" errors, I can't get anywhere.

Do I have something set wrong? Probably.  What?  No idea.  But UAC is not it.

In it's current configuration, this system used to let myself and my users remote in to the system using the SSL client.  It no longer does.  I turned UAC off when I took this system out of the box and its state has not changed it the 12 months or so I have had it.

I have clients with both XP and newer who are not able to connect.  None of the people whom I have asked have been able to connect "recently".

Until "recently" I was able to bring up the current traffic report on my box by clicking on eithter the Out or In on my network interfaces at the dashboard.  Since 8.2, this no longer works.  Astaro Support was on the box, verified that it was indeed non operative, and told me that it was a bug and was "Currently under review for a fix".  

Perhaps this is one of those things that just affects my system.  Dunno.  Sad thing is, I can't even trace it back to when it actually stopped working since I don't usually use it.  I prefef to just have the system drop me onto my desktop when I connect and have created a SNAT/DNAT to do this for me.    

I have tried the "UAC" fix. That does not appear to be the problem/solution here.