Reverse Proxy

[TsvWalker]

Hello everyone,

I am trying to figure out how to make Wingate 7 a Reverse Proxy, I have (at the moment) 4 services (Microsoft Exchange, SharePoint, Dynamics and Terminal Server) and possible more in the future. Each service is running on it's own server, the servers are named similar to the following: S1.mydomain.com, S2.mydomain.com etc.

I would prefer to be able to use the sub domain to direct the traffic rather than using the URL because of the possibility of multiple services on a single server and possibility of the same service on multiple servers.

So what would be the best way to setup the reverse proxy?

[adrien]

Hi

are you doing reverse proxy for https, or just http? There's a problem with 7.2.10 for reverse proxying https which we've fixed here.

In general to set up reverse proxy you would

1. install a new WWW proxy in WinGate Management > Control Panel > Services
2. Bind it to external interface
3. create a web site (in the WWW proxy you added on the Web server tab). Set host headers to match the incoming sitename that clients will request
4. Choose "reverse proxy" as the action, and specify the internal server details.

If you want to do https, let me know, there's a registry workaround to the bug or you can try our latest build which explicitly supports SSL for reverse proxy.

Regards

Adrien de Croy

[TsvWalker]

Hello Adrien,

Most of the services will be able to run on with just HTTP, but for something like Exchange or Terminal Server I will require HTTPS.

Ashley

[adrien]

Hi

ok, did you try setting up the reverse proxy in a WWW proxy service?

If you need any help with that let me know. As for https, I need to do a small amount more testing with the build that fixes this and I'll let you know.

Regards

Adrien

[TsvWalker]

Hello Adrien,

I am surprised by how easy it is set it up (much easier then IIS), I'll wait it out for a the HTTPS reverse proxy.

Ashley

[adrien]

cool

one thing we also recommend sorry should have mentioned it before.

Since the www proxy is a proxy server, once you bind it to external, you're an open proxy unless you take some steps to lock it down.

One way to do it is to put a flow-chart policy on each of the events: ConnectRequest and ProxyRequest for the service you added. You can add policy from the events tab of the service itself, just double-click the event and click Add, select policy.

In the policy itself, drag in the correct event, and connect it to a result object set to reject. This will reject any attempt at that type of access. If instead you wanted to allow external users to use the proxy if they were authed, you could check if the user is amember of authenticated users, then allow, if not then result type is auth.

Same for ConnectEvent (use of the CONNECT method, which otherwise will be hammered by email spammers).

You may also want to unhook the filters from the general tab of the proxy.

The "Web Activity for WinGate" filter is the "Web Access Control" system. It's mainly designed for forward proxying, I think you may have issues if you leave this filter attached to the external proxy, since it will actually try to enforce the rules as well. HTTP cache probably won't do much unless you're worried about off-loading access from your internal servers, if those servers set expiry or Cache-Control with max-age headers, then WinGate can serve it to clients from its own cache without bugging the server.

With the flow-chart policy you can also do quite funky things with the reverse proxy requests. These appear in the "ServerRequest" event. Reason being that the request made by the client is treating WinGate as a server, and WinGate's just reverse proxying it.

Regards

Adrien

[pagey]

I am just giving this a trial run in our DMZ, I intend to use it to reverse proxy our HTTPS Exchange Webmail OWA/CAS server

when I create the new WWW Proxy service to function as my reverse proxy and bind it to the external interface do I change the default binding port from 80 to 443?

To test I have simply edited the hosts file of a test workstation in the DMZ and pointed the hostname webmail.ourdomain.com.au to the wingate servers external IP, but it doesn't seem to be doing anything with the request, just times out

Is this to do with a version specific bug you mention in this thread? I am running 7.2.10.3486

[adrien]

Hi

the problem is that although you can bind the proxy to 443 with SSL/TLS, it won't make an encrypted connection back through to your OWA server.

We fixed this in the lab, if you'd like me to send you a download link, let me know. We've some people running it with good results.

Regards

Adrien

[pagey]

A link to the patched build would be great thanks adrien, happy to come back and post my results+config after testing

[adrien]

Hi

I sent you a link.

Regards

Adrien

[pagey]

I must have missed a step somewhere

Clean windows install with two nics (one LAN, one in NAT DMZ), disabled windows firewall and opened all ports on perimeter firewall
Install Wingate 7.3.0.3493
Configure External NIC / Internal NIC in Wingate
Changed Default Access Rule to Deny and Disabled any other rules)
Added binding to Default WWW Proxy Server of external adapter
Remote controlled PC outside our network for testing and visited http://extIP (ext IP nat'd to Ext adapter of wingate box)
Received the expected Wingate has blocked GET message (due to my intentional access rule set to deny, just for testing connectivity)

Created New Service "WWW Proxy Server - Reverse HTTPS"
Basically cloned all settings except bindings to port 443 instead of 80 (added the events with policies etc, there were samples there that I just added the new service I created to and linked to the same point as the other service on the flowchart)
Browse https://extIP and it just sits there with a spinning wheel, I see the connection show-up in the activity monitor (even if the activity for wingate option is off, no host headers though just http:// )

Any help appreciated

Cheers - Pagey

[adrien]

HI

things to check

1. in the binding rule that specified binding to port 443, did you enable to use SSL, and choose a certificate?

The certificate needs a private key to be usable for encryption.

You need to convert your cert to PEM format as well and get it into WinGate. See http://forum.wingate.com/viewtopic.php?f=23&t=40885&p=37223#p37223

2. did you forward port 443 also to WinGate?

3. In the reverse proxy setting, did you configure the host header to match with SSL? You need to do this or it will only match for incoming http (port 80) requests

4. In the reverse proxy setting, did you configure it to connect to the internal server with SSL on port 443.

Regards

Adrien

[TsvWalker]

Hello Adrien,

I would also like to get the link to the version of Wingate that works with the SSL certs.

Ashley

[pagey]

Hi Adrien,

Thanks for your help, I was incorrectly assumed it would proxy the certificate from the originating server, I obviously didn't understand the technical implementation

I enabled SSL on the Proxy Bindings and now have it working with the build you linked me with a self signed certificate (with warnings obviously), i will obtain a real cert shortly, I am assuming a wildcard is recommended for multiple SSL host headers?

it is now reverse proxying https://remote.mydomain.com to my RDS server's web interface and https://webmail.mydomain.com to my exchange owa server, which is perfect, I am now looking into open relay prevention to make sure I have it configured correctly.

How do I handle the RDP (TCP3389) session that will start after launching from the web interface, is this something wingate can do, is this via extended networking? Sorry if this has been covered somewhere else, if it has been I haven't been able to find it

Also confirming the funcationaility I am using above (reverse https proxy) requires the enterprise licensing?

[pagey]

I got a bit further, I understand now you don't need to purchase an additional cert (I didn't understand this when reading the forum topic you linked above)
- You create a cert in Wingate with the encrypt option, specify a password
- You export a real cert from your server with the same password used above
- Use something like https://www.sslshopper.com/ssl-converter.html to convert the exported file to a PEM
- Replace the relevant .PEM file in C:\Program Files\WinGate\Certificates with the converted one from the step above

I also managed to get the RDP traffic working with Extended Networking - Port Security - Redirect

I guess there isn't much more I can do with the RDP traffic from a security point of view?

[adrien]

HI

what you'd normally do is re-use the same cert that was in use on the server you're reverse-proxying to, since otherwise that's where the clients would be connecting anyway so they would need to trust it already.

As for license, you can do global reverse proxy with any license, but multiple "sites" e.g. different config based on host header is an enterprise feature.

regards

Adrien

[pagey]

Am i correct that I will need two Proxy Services, one for each HTTPS service I am reverse proxying? That is ok, just uses an extra IP as I will bind one service to one IP on 443 and one to the other IP on 443

I have been trying to do both sites with one service, but it seems to use the SSL cert specified on the bindings page of the service, regardless of what is specified on the web servers tab for the relevant host headers. If I un-check the use SSL option on the bindings tab and select use client certificate on the Webserver tab for each it doesn't work either

I just want to make sure I am implementing correctly

[pagey]

Or would One service with two bindings be a better implementation?

[adrien]

Hi

Currently, if you want to use more than 1 cert, you need more than 1 IP. That's because with SSL, it makes the SSL negotiation before it sends any requests with host headers. It's too late to choose local cert for the binding after the request has been sent.

The cert you specify in the reverse proxy settings is for a client cert to use to connect to the upstream (internal) web server, so it's not the cert used to negotiate SSL with the external client.

There is an SSL/TLS extension where the client sometimes sends the servername it thinks it's connecting to in the SSL Client Hello packet. We are looking into options to support this, since it would then allow hosting multiple SSL sites with different certs on the same IP.

Alternatively you could use a wild-card cert, and just use it for all the sites you're reverse proxying for on the 1 external IP. As long as the wild-card name matches all the sites, you'll be OK. You can also possibly get a cert issued with all the site names you need in it in the "Alternative Subject Name" field. You'd need to check with your CA for this.

Adrien

[adrien]

can do multiple bindings if you prefer, since binding rules allow you to specify IP address to bind to.

[pagey]

I now have my two https:// interfaces reverse proxying with SSL's perfectly thanks for your help!

Now my only problem seems to be the Extended Networking->Port Security->Redirect I put in place for port 3389 is giving terrible performance rendering it unusable at this point, I am just checking to make sure it isn't anything else I have done, if I am still having trouble tomorrow I will make a separate post as I am probably going off topic here

[TsvWalker]

Hey Pagey,

If you could let us know how you go with your RDP (port redirect 3389) as that is also something I will also have to figure out some time in the not to distant future.

Ashley

[adrien]

Hi

Extended networking redirect should be very fast.

If it's slow, it makes me wonder if there's some other problem. If you check the option to "don't translate source iP", then the back end server you're redirecting to needs to use WinGate as a gateway back out for that connecting IP (normally this means setting default gateway back to WinGate, unless you know exactly which IPs will connect in using this).

Adrien