Remote Control Problem

[jeff]

Hi.

Since i migrate some machines to 2.5.2, it's impossible to 'remote' connect :
- from a 2.5.2 to a 2.2.x
- from a 2.2.x to a 2.5.2.

connect look ok, but immedialty disconnected.

I can not migrate every machine now. (they are far away, the wingate engine is shuted down during the installation and all the VPNs are disconnected => as manual validation are requiered during the installation of the new version, it's impossible to manage the remote machines using a wngate vpn )

I just migrate our servers only because of the release correction 6 (Fixed a problem with multiple concurrent SSL connections which could cause WinGate to become unresponsive.) => I'm still having the same problem connecting all the nodes (about 40) on a single server => Server crashes after about 25 client connect simultaneously. (as i said, I just migrate the server because i cannot migrate the clients. Is there a change on the client side for that correction to work properly ?)

Best regards

Jeff

[adrien]

Hi Jeff

We didn't change the VPN protocol so a 2.2.2 client should connect to a 2.5.2 server no problem and vice versa. In fact I still use WinGate 6.2.2 at home, and I connect to the VPN server at the office which is 6.5.2.

You have those 40 clients in a full mesh network correct?

We did some work in the ENS on a different routing algorithm to improve performance when the number of routes becomes large. It's not been rolled out yet (still in testing), but if you'd like to test a driver that implements that algorithm you are welcome to.

Regards

Adrien

[jeff]

Hi adrien.

yes, we have 40 clients in full mesh. (not really because this configuration doesn't work !! )
And this year, we'll add about 60 more !!
I'm ready to make some tests with the new ENS driver. Make me know when a Beta or Release Candidate version comes out.

As far as Wingate doesn't need so much ressources, I planned to install an VMWare ESX server with 2 or 3 Virtual "Wingate" Machines on a Dell Power Edge 1950 server.

I don't have any problem connecting to a VPN server, whatever the version of servers/clients => This work fine.

The problem is when using the remote control service (on service port 808 by default) => This doesn't work.

Gatekeeper 2.5.2 ==> engine 2.5.2 is OK
Gatekeeper 2.2.0 ==> engine 2.2.0 is OK
Gatekeeper 2.5.2 ==> engine 2.2.0 is NOK
Gatekeeper 2.2.0 ==> engine 2.5.2 is NOK

The first time I connect to the remote (after openning gatekeeper),it says "connected to xxx" , and 1 second after, it says "not connected". And nothing appears.
The second time I connect to the remote (gatekeeper is still openned) ,it says "connected", and nothing appears.

I made some more tests :
If I replace the gateKeeper.exe file :
on a 2.5.2 installation, using a 6.2.0.1121 gatekeeper.exe : impossible to connect locally (!!), but possible to connect any remote client with a 2.2.0 installation.

It looks like the gateKeeper.exe can't communicate properly with the Wingate Engine when the versions doesn't match.

I need to have both gateKeeper.exe (6.2.0.1121 and 6.5.2.1217) if I want to be able to communicate (to the remote control service) with any versions of remote engines.

best regards.

[adrien]

Hi Jeff

OK, I understand now, you are right, the GateKeeper and Engine must be same version in order to interoperate. This means if you are remotely controlling several WinGates from a central location, you'll need a version of GateKeeper for each different WinGate version.

As for a question you had earlier, no, you shouldn't need to upgrade the client Nodes to get the benefit of the fix for multiple concurrent SSL connections, that will only affect the VPN server anyway.

Do you have an updated lock analysis file you can send through? I've been looking through the earlier ones, and they look to be corrupted (wrong names for things) which implies some sort of heap / memory corruption. This (memory heap corruption) was a symptom of that SSL problem which should be fixed now.

One other thing that the server does when a client connects is try and verify connectivity to all known machines on the client Node's network. Seems like a bad idea looking at it now! It does this by trying a WINS lookup - like a DNS lookup on port 137 UDP to the remote machines.

Do these nodes have many attached computers that would be showing up in the network pane in GateKeeper?

Regards

Adrien

[jeff]

Hi Adrien,

I'll try to make a test to get a new "lock analysis file". (But it's not easy to make a test on an operational network, as far as I know that the server as a chance to crash.., so I need to be near the server in case I finally need to reboot it (most of the time).

I don't have any WINS / Netbios Machines on the network. (The wingate machine has Netbios disabled)
The WINS "enable periodic network enumeration" is turned off.
The only facility I need is the "IP routing". (The "support for the multiple subnetworks" option of the ENS driver is also disabled)

On each node, I have :
- 1x/32 (The Wingate WAN interface)
- 1x/24 (The local LAN Network).
On the local Network, I generaly have a single machine (Not a Microsoft Windows based machine)

- - - - -

I still have the same bug in the new gatekeeper.exe. As you understand, I use the gatekeeper to remote connect to a remote note.
I have a problem using the Scheduler Events.
When I enter a new action and I want to view it back (double clic on the action), every action below "reset all user accounts" is OK. But all other action under "Execute commandline" has the same problem :
when you enter the action, all is OK. The action is listed in the actions listbox. but when I make a double-click on it to change some parameters, it's the wrong action that appears. And the problem is that if I click on the OK button, the new (and unwanted action) replaces the original one.

If I enter a new action
=> do what = "ExecuteCommand Line"
=> CommandeLine = "c:\my_com.bat"

=> OK => The action commandLine Appears. If I close and click on the "Do Now" button => Its OK.

If I want to change (or check) the commandline, I make a double click on the "Execute CommandLine" line in the action listBox.

=> do What = "Reminder" instead of "Execute CommandLine"
=> Message (replace the commandLine) = "c:\my_com.bat"

If I click then on OK, the original action 'Execute CommandLine" is replaced with the "Remider".

- - -

Isn't there a way to make a gatekeeper.exe compatible with older version of engines (2.2 ...) ? (The difference looks to be regarding the DNS service ?)


Best Regards

[adrien]

Hi Jeff

"support for multiple subnetworks" means ip routing. But routing between local subnets only.

I just checked the code. depending on 2 other settings, disabling this will prevent VPN from working. You need at least one of

Firewall enabled (not Disable firewall); or
NAT enabled; or
Support for multiple subnetworks enabled

for VPN to work. I presume therefore you have the firewall enabled?

As for versions of GateKeeper, we don't maintain compatibility between different versions. It's not really feasible to do so. Normally nowadays people use remote desktop, and then just log into WinGate with the GateKeeper that's on that same machine. Is that an option?

[jeff]

Hi Adrien,

About the Gatekeeper compatibility, I found an issue. I made my own "GateKeeper.exe" to replace to original one.
When it's launched by the user using the tray Icon, it just asks the user wich version on gatekeeper he wants to use, and then it launches the appropiate "Gatekeeper". (I renamed the original gatekeepers into gatekeeper_2.2.0.exe and gatekeeper_2.5.2.exe)
As I also made a "centralized" management center to manage all my remote clients, I just add a "Wingate version" parameter to each remote "probes" configuration. I can now use up to 8 different gatekeepers.exe to acces directy to the remote wingate engine using a single mouse-click.
---
For shure the firewall is activated (!!!), and nothing else but the hole for data is activated (and hole for control on servers)!!
(The wingate machine is dedicated for VPN only). I just mentionned this option was disabled to indicate that my routing tables are quite simple and I don't need anything else than to be able to reach the IP's learned by the remote nodes (No Microsoft Networking, no particular features).
And If i'd need to add another LAN network, he may not need to talk to the other one.
--
I just found another problem using the new Gatekeeper with the new engine (...) It's impossible to manage users / groups and the access policies to the VPNs "to host"(During a remote session). Whatever I do, nothing is saved. I have to go to the local machine to make the changes.

Best regards.

[adrien]

Hi Jeff

I just found a problem in WinGate that could cause some of the symptoms you are seeing with many connections.

If you look in the VPN log files, do you see many entries saying

"VPN Error: Connection from 'a.b.c.d' failed. Pre negotiation of acception failed"

Adrien

[jeff]

Hi Adrien

Yesterday, I had a crash. In fact, the internet router of the server "freezed". All VPNs were broken (server was unreachable) until I reboot the router.
Then about 25 clients connected to the server all at the same time and ... the VPN server "freezed". (Usually, he doesn't, this work fine)
I just inspected the VPN logs of the server and of a client.

On the Server's log (2.5.2)
I can see all client connecting and server distributing routes
02/24/09 09:XX:XX VPN Connection: 'remoteNode_XX' has joined 'MyNodeName'
02/24/09 09:XX:XX VPN Tunnels: Tunnel to node remoteNode_XX(aa.bb.cc.dd:PORT) with ID 12345 active and updated
02/24/09 09:XX:XX VPN Tunnels: Tunnel requested by 'remoteNode_YY' to 'remoteNode_XX'
etc ...
And suddenly, I can see this line about 500 times/sec !!! (I noticed more than 220.000 times this line until I reboot the server, from 09:26:26 to 09:32:18)
02/24/09 09:XX:XX VPN Disconnection: VPN Server Connection (MyNodeName) closing because send to remote failed

On the Client's Log (2.5.2)
I can see this line about 15 times/sec for each remoteNode_XX (about 150 times/min for all remoteNodes and about 4500 times until the server reboot) :
02/24/09 09:XX:XX VPN Disconnection: 'remoteNode_XX' has Left 'myNodeName'

When I look carefully at the logs (client side), I see that each time a remote_nodeXX disconnects from the server, the local log file write the event many times (I noticed 280 times in 3 seconds !!).
02/24/09 09:XX:XX VPN Disconnection: 'remoteNode_XX' has Left 'myNodeName'

- - -

I didn't see any entries saying
"VPN Error: Connection from 'a.b.c.d' failed. Pre negotiation of acception failed"
... But I have many logs to inspect ...
Should that be on Server or Client side ?
When I first had that problem, the message was (on client) :
VPN Error: The VPN connection to 'MyNodeName' has failed. Unable to connect using SSL - error code 5

But it looks like since the new version you specially compiled (built 1142 and up), i don't have any more this "ssl - error code 5" message.

I also noticed this error oftenly (on client side, regarding client-to-client VPN):
VPN Tunnels: Tunnel to 'remoteNode_YY' requested on aa.bb.cc.dd:PORT
VPN Tunnels: Tunnel to node remoteNode_YY (aa.bb.cc.dd:PORT) with ID 1039 active and updated
and, some seconds after ...
VPN Tunnels: Error ffe0b410 creating tunnel to node remoteNode_YY(0.0.0.0:0) with ID 0
VPN Tunnels: Tunnel to 'remoteNode_YY' requested on aa.bb.cc.dd:PORT
VPN Tunnels: Tunnel to node remoteNode_YY(aa.bb.cc.dd:PORT) with ID 123 active and updated

I'll try to make a test next weekend connecting all 41 nodes on a single server. Then i'll get the logs and the LockAnalyserDumpFileEng on both server and client.

Best regards

[adrien]

OK thanks for that

that's excellent information, I should be able to fix that easily.

Regards

Adrien

[adrien]

actually we've been doing some more testing on VPN over the last week for this latest build based on the problems you reported before, and we fixed a couple of other issues as well.

Regards

Adrien

[jeff]

Hi Adrien,

If I have any more information regarding other logs, I'll report every 'strange behaviors'.

If you want me to test a new release, it's possible.
I have 4x Dell Power Edge 1950 with 2 x quad-core XEON processors, running Windows 2k3 and wingate VPN. They are dedicated to wingate VPN (hosting nodes). (No Active Directory, Web, ftp, ...)
2 are used for normal operations, and 2 are used as backup, on another site.
I can easilly switch to one of the backup servers (just updating a dynamic dns), and allow every client node to connect to it. (remember : the VPN servers doesn't host any services, or datacenter, so I can put them anywhere I want on Internet. They just reditributes routes to all clients nodes, datacenters are clients nodes)

As the network is worldwide, (allways someone working) impossible to do anything during regular week. So, tests can only be done during 'no-work' time : during weekends and late at night (in case of ...)

Resolving this problem would be a great improvement for me (well, for us) ...

Best regards

[adrien]

Hi Jeff

I've been also looking into the other 2 problems you reported relating to using GateKeeper to manage a remote VPN:

* Scheduler UI not working properly
* managing Users/Groups for hosted VPN access rights.

Both of these are working fine for me at the moment, so I can't reproduce this.

I'm close to having a build you can test. Just validating it here. It's currently serving our corp VPN.

I'll email you a download link when I'm happy with it. I've done quite a bit of work on the management of control connections. The code had evolved over many years and was a bit messy and had some holes in it.

Regards

Adrien

[jeff]

Hi Adrien

About the remote control "managing Users/Groups for hosted VPN access rights" problem, I made some more investigations, and I think I found what was wrong. I was connecting from a node with 2.2.x Engine with a 2.5.2 gatekeeper.exe. It seems this configuration is not enough to entirely be able to have full remote functionnality. Here are the results :
Gatekeeper 2.5.2 on a 2.5.2 installation ==> 2.5.2 peer : OK (all is good)
Gatekeeper 2.2.2 on a 2.2.x installation ==> 2.5.2 peer : NOK (no connexion to the peer)
Gatekeeper 2.5.2 on a 2.2.x installation ==> 2.5.2 peer : connection OK but some facilities not accessible (managing rights, ...)
==> using a gatekeeper.exe with the same version of the peer doesn't seems to be enough to completly access to the peer. (maybe some other files required, or the engine is definitly incompatible).
==> It looks that I haven't resolved my compatibility problem of remote control between different versions of Wingate !!
Wingate is OK.
Having a "super gatekeeper" that can recognize the peer version and be able to connect to any of them regardless of their version would be great !!


Regarding the Scheduler problem, I looked at the registry values "EventAction" for each action in the combobox.
0 = Do nothing
1 = Stop Service
2 - Start Service
3 - Stop All services
4 - Start all services
5 - Dial profile
6 - Hangup profile
7 - Rollover log files
8 - Rollover audit files
9 - Export user account
10 - Reset user account
11 - Reset all user account
14 - Execute commandline
15 - Purge history database
17 - Reminder
18 - System Reminder
19 - Enable user
20 - Disable User
21 - Backup Registry
23 - ConnectVPN
24 - Disconnect a VPN

==> It looks not all event are available to the VPN only version. because we can observe holes (12-13,16,22)
If openning the action windows and filling the "action" combo is only regarding to the action ID to set the combo's listindex, then the same problem as I describe happens :
When I double clic the commandLine event (id=14) it shows me in the action windows the 14'th list element => (reminder)
In the wingate complete version, all events are accessible, so event commandline (id=14) will matches with the 14'th list element.

Best regards.

[adrien]

ok thanks for that. I must need to check the VPN only version.

Regards

Adrien

[jeff]

Hi Adrien,

Yes I think the scheduler problem is a minor "bug", that can be resolved easily.(I'm not affraid of that, since you can reproduce it !)

Let me know when you have a new "RC - Release Candidate" version, I'll test it.
If you worked on a cleaned-up and updated code, no need for me to test the current version : I'll wait for the RC version.

Best regards.