WinGate and Slipstream accelerator

[Jens]

I have tried to install a web accelerator on client PCs residing on a network behind WG - so far without any luck. The accelerator in question is Slipstream (or OnSpeed as the UK subscription service is called). The accelerator is installed as a client program on the PCs which addresses the remote server helium.onspeed.com server port 7000 and local listening port 5400. The browser has to be set to use proxy Localhost and port number 5400 to work. The client PCs use WGIC and transparent proxy to enable accounting and virus checking etc.
Any suggestions how to make these functions to work together?

[Pascal]

What problems are you seeing?

[Jens]

Problem solved on the client machines, a reinstallation of the accelerator made it work again. However I noted a new issue with the accounting function in WG when the accelerator is used. With the accelerator running user accounts are not updated until the browser or the accelerator is closed. We need to bar users when their accounts goes negative (prepay system) but this becomes unreliable since the account may "never" be updated as long as the browser is kept open by the user.
Is there any way to have the accounts updated periodically e.g once a minute to eliminate this?

[Pascal]

Not at the moment, no - session traffic is updated when the session closes. What about a slight configuration change? Would it be possible to put the SlipStream accelerator on the WinGate PC - then your clients can just proxy normally through that - WinGate then proxies through that?

[Jens]

Hmm, pity.

I'm not sure how I would do that, the system is quite complex using two different satellite systems for outbound and inbound directions and there is already a TCP accelerator (Mentat) running on the Wingate server. However, if it could be done as you suggest then it would be very neat indeed.

In the web accelerator (Onspeed) client there is the following information:
Address of the remote server: helium.onspeed.com
Server port 5400
Local listening port 7000
User name: myusername
Passwword: ********

When the Onspeed client is installed locally, browsers are configured to use proxy Localhost port 5400 for the services that are to be ompressed.

If you can advise on how to configure WinGate to operate in the way you suggested I would be very grateful.

Jens

[Pascal]

One of two ways, depending on if you want to use the WWW Proxy Service or not.

First, if you want to use the WWW Proxy Service, go to the "Connections" tab of that service, then set it to cascade through a proxy "127.0.0.1" on port 7000.

Second, if you don't want to go through the WWW Proxy Service, you can do it either by setting up a TCP Mapping Service (From listening port 80 on your internal IP to map to localhost on port 7000). Go into GateKeeper, right click on the "Services" pane to create a new TCP Mapping Service. OR do the same thing with a TCP redirect in the ENS Port Security Actions. Go into GateKeeper, go into Extended Networking and switch to "Port Security". There you want to setup a redirect as above, except now it'll be going through the driver.

Personally, I'd go with the first option. The second ones might get a bit tricky.

[Jens]

Thanks Pascal,

I want to use the first option as I need the accounting facilities I get using the www.proxy.
I assume both the Onspeed accelerator and the browsers need different settings when the accelerator is used in this way and would appreciate advise on this setting too.

Jens

[Pascal]

Address of the remote server: helium.onspeed.com
Server port 5400
Local listening port 7000
User name: myusername
Passwword: ********

One thing you might want to do is double check that using the accelerator on a gateway product does not contravene the EULA from OnSpeed. (I haven't checked, so don't know if it's okay or not)

Given that - what you want to do is get OnSpeed on the Server. Configure it as you would for the client machines. Then, setup the Cascaded Proxy on the WWW Proxy Service, to point to "localhost" and the port you have configured OnSpeed to listen on (I believe that will be 7000 as per your example)

In terms of the client machine browser. It sounds as if you are using direct proxy connections there? You have one of two options now. You can either point them at the internal IP of your WinGate Server (E.g. 192.168.0.1 - port 80) OR you can use NAT, and simply intercept the correct port (Port 80) from the WinGate Server.

[Jens]

Hi Pascal,

I discovered that the reason I didn't get your proposal to work was that I had mixed the local listening port and the server port numbers. Correcting for this it now seems to work like a charm.

Cheers
Jens

[Jens]

Ooooops, too quick.

It works BUT the compression benefit is now not included in the accounting since the data is decompressed before it hits the WG accounting mechanism so the users will be overcharged. Preferably the users should first hit the Onspeed (or Slipstream - same thing) accelerator which redirects to Wingate and then sends it on to the Onspeed proxy server. Is this possible?

Jens

[Pascal]

I think so. (Don't have onspeed setup here, so I might be wrong about it's operation) But I suspect that all you want to do is reverse the process a bit.

First things first though - how are your clients connecting to WinGate at the moment? If they are using NAT, you would want to keep the WWW Proxy Service running on port 80 (Generally).

So, keeping that in mind:

Address of the remote server: helium.onspeed.com
Server port 5400
Local listening port 7000
User name: myusername
Passwword: ********

1. Set the WWW Proxy Service to listen for connections on port 8080. (General page). Also ensure that if you are using intercepts (Sessions page) that they will listen on the correct ports.

2. Set the WWW Proxy Service to cascade to helium.onspeed.com on port 5400.

3. Now, set SlipStream to have it's remote server as 127.0.0.1 (localhost) on port 8080. It's local listening port becomes port 80.

That way, your clients will connect in to SlipStream on port 80 (Even if using NAT) and then be redirected by SlipStream to port 8080 on the local (WinGate) machine. WinGate will cascade that request out to the appropriate server.

Now - the big issue. This all depends on the type of connection that SlipStream makes. If it is not a standard HTTP connection, this won't work. In that case, we might need to alter your setup a bit.

How are you authenticating the users, btw?

[Jens]

Thanks for your proposal but although I did get the data to go through no compression took place.
Note that there was an error in the parameters I gave you earlier for the compression agent, the correct data are:

Address of the remote server: helium.onspeed.com
Server port 7000
Local listening port 5400
User name: myusername
Passwword: ********

The previous info I gave you had remote server port and local listener port swapped, so I took that into consideration when I configured WG and the Onspeed client.

Firstly to answer your questions:
The clients connect to WG using WGIC and use WG DHCP service. The client browser is not configured to use proxies, just default setup.
User authentication is using WG user database with Java authentication enabled. (For some reason the client PC in the test setup do not come up with the Java authentication window, just the normal auth window without Java although Java 1.4.2 is installed on the PC. The WG server on the other hand changed to Java authentication window when Java authentication was enabled).

Having read your mail I set the parameters as follows:

WWW Proxy
General: Serv Port 8080, Java client
Sessions: Intercept connections, port 8080
Connection: Through cascaded proxy, helium.onspeed.com, port 7000

Onspeed client
Remote server 127.0.0.1, server port 8080, Local list. port 80.

Client PC browser are not set to use proxies as the client PCs run WGIC.

The result was as stated above, connections could be established but no compression. I do notice however that we no longer use port 5400, could that cause any problems?

Jens

[Pascal]

<phew> This is a tough one. Have you tried asking SlipStream's tech support how to cascade it through another proxy? Is there anyway to see if the data is actually going out through it, rather than just from WinGate?

[Jens]

It certainly is a tricky one, I take it you did not see any flaws in the configuration. I have contacted Slipstream but the discussions has not progressed to the necessary depth yet.

However the accelerator/compressor is very efficient and really works wonders on slow or expensive channels. There is also the question of virus scanning e.g. Kaspersky AV would not work if only has access to the data in the compressed form. So the optimum solution I guess would be to have the Slipstream accelerator as a plugin component in WinGate, then I assume it would be possible for incoming data to be accounted, decompressed, virus scanned and finally forwarded to the client PC. In the outbound direction WG would virus scan, then compress and finally account before sending on to the Slipstream server.

May be worth while to consider inclusion of web compression as possible future enhancement of the WinGate functionality.

Any other good ideas are welcome.

Jens

[Pascal]

The only thing that concerned me was the presence of WGIC. And, unfortunately, we can't get a demo of "OnSpeed" - they don't give a trial period.

[Pascal]

What happens if, just as a test with your current setup, you disable WGIC on one of the clients and set it to use a direct proxy connection?

[Jens]

Should I then proxy to 192.168.0.1 port 80?

[Pascal]

That was the thought. WGIC Toggle can temporarily disable WGIC. But, I've been talking to Genie about this and he doesn't think WGIC should be a problem.

(Still worth a shot though ... )

[Pascal]

Might have a few clues here - but without having a SlipStream installation in front of me it's difficult to be sure if this is just a wild-goose chase, or if we're on the right track.

If you have the time/inclination to try a few alternative options:

1. Stop the WWW Proxy Service (Right click on the service).
2. Create a TCP Mapping service that listens on port 8080 with a destination of the SlipStream remote server + port combination.

Then, try it from the client again. If it doesn't work, you can simply delete the TCP Mapping Service and start the WWW Proxy Service again.