Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 22 replies
  • Subscribers 1 subscriber
  • Views 13078 views
  • Users 0 members are here
Options
Suggested
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

TXGARobert@Home
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
    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.
Reply
  • 0
    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.
Children
  • 0 in reply to BAlfson
    "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"