The reason why I'm asking is I have configured a reverse proxy ruleset to access outlook webmail (https) with two internal servers as NEXT HOP-Proxy.
When I enable ROUND ROBIN it's behaving a little weird, it seems to me that the webgateway is switching the servers in the Next Hop Proxy List after each request and webmail access isn't working correctly.
When I enable the FAILOVER parameter the connection works fine.
Is it possible to tell the webgateway to treat SourceIP/ClientSession as sticky? To use is kinda like a load balancer?
Does anybody have experience with such a configuration?
I don´t think this is possible. Round Robin for next-hop works exactly as you explained: each request will go to a different proxy in a Round Robin fashion. Fail Over will always talk to the same node, unless it fails.
I do not see a way to tell MWG to act as a load balancer between MWG and the internal destination servers. If real load balancing is required, you may want to utilize a load balancing device, and point MWG to forward traffic to the IP of this device.
when using SSL in any way with mwg a connection should always be sticky. Otherwise SSL will never work without troubles. :-)
There are also HTTP Servers where you have to authenticate yourself. When changing the next hop proxy for such a connection the connection could also not be established.
1 of 1 people found this helpful
for HTTPS this is a little different I think. MWG sends a CONNECT request, which usually tunnels through the next-hop proxy (assuming it is not capable of SSL inspection). All HTTP Request are going through that tunneled connection, until it is finished.
I have not experienced problems with this so far. Even if MWG creates multiple CONNECT requests through more than one next-hop proxy, that usually should not make a different for the application on the remote end. You will most likely see problems when you are having a banking session for example, going through two different next-hops from MWG, and both next-hops end up at the banks webserver with two different public IP addresses. In this case it is up to the application to deny the CONNECT request from the second IP address after the first one connected, and hopefully a banking application would do so.
In a usual "forward proxy" environment both next-hops would usually use the same internet connection, and should be NATed when they leave the companies network. For the remote server it should not be possible to see that - before the requests hit the NAT device - different proxies were used.
The same should apply for HTTP requests using authentication. Once authentication is done (thinking of NTLM authentication), the first request within a persistent TCP connection is authenticated. If there are two different connections through two next-hop proxies, both connections are authenticated. If the request reaches the Web Server from different IP addresses, this may cause a problem, if they are hidden behind a NAT, I would not expect any issues to occur.
Please let me know if I am wrong with my assumptions.
Of course this completely changes when we talk about a reverse proxy deployment. In this scenario the next-hop proxies are actually web servers, which receive the clients requests directly. If a client is working on a server, such as Outlook Web Access, and half of its communication goes to Server A, and the other half to Server B, this certainly will cause problems.
In this scenario, we need to ensure that one Client is talking to one Server. This can only be done by using a specific server for each client - so round robin is not a good idea here. To keep the sessions persistent, I think a load balancer is helpful. Maybe there is a way to generate a "fake session persistency" with PDStorage and remembering the Source iP address for a couple of minutes.
sorry, but we notices several troubles when the source ip changes. It´s not the connection between client and mwg, the problem is the connection from mwg to the inside web server (next hop proxy).
For every request another next hop proxy is used. Therefore many secure appliacations are terminating the connection because the source ip was changed.
We also tested using mwg as a standalone installation, the same behaviour/issue/problem.
If mwg and webserver are located in the same subnet without any network ACL between the systems the problem also occurs.
Nachricht geändert durch Troja on 08.11.11 10:26:29 GMT
Pleas take a loot at my drawing. I think this is a simple installation at a customer. One MWG but two webservers in case of failover capabilities. Therefore the connection should always be sticky to one webserver.
@Harry: Is there a virtual IP possible for the webserver farm?
NextHopProxy.gif 7.3 K
In this scenario it's not possible to use a virtual IP nor a load balancer.
There is also a problem with website where authentication/login is required, not necessarily https, also http sessions.
Like in my scenario I get the login page serveral times, but I think that's the same problem Andre explained above.
How would --a "fake session persistency" with PDStorage and remembering the Source iP address for a couple of minutes -- work?
a fake persistency should pretty easy to set up. With PDStorage you can "remember" values for a specific amount of time. I am currently playing with some rules. What I do is using the User based PDStorage, which is valid only for the Source IP address (or User Name), and write an "ID" for this Client. The Client is now "sticky" for a defined timeframe, for example 12 hours.
Later in the Rule set I look for the ID and - depending on what the ID is set to - pick a different next-hop.
This is the basic idea. I am currently working on some rules that will assign a different proxy foe each request coming in, and remember the assigned proxy. E.g. Client 1 is told to use Proxy A for the next 12 hours, Client 2 is told to use Proxy B, Client 3 is again told to use Proxy A, and so on.
When I look into the picture above and the statement "One MWG but two webservers in case of failover capabilities." the question is, why can´t we use the "Fail-Over" capabilities of the next-hop proxy settings?
In this case all requests will go to Node 1. When Node 1 fails, all requests will go to Node 2.
Is a load sharing required?
I got some kind of session stickiness working. It seems to work pretty good in my test lab, but certainly I have not completely tested it under load or in a real environment. I will leave it up to you to take the idea and use it if you like.
The basic idea is the following. PDStorage allows to keep an information between transactions. Usually if a transaction is finished, all variables such as Username, Client IP etc. are gone, but with PDStorage we can keep it. PDStorage entries have a timeout, so the information is remembered for a specific time, and MWG will forget about this information after a while. There are two kinds of PDStorage:
The Global PDStorage holds a value that is completely independent from the Client, and is available to all requests. The User PDStorage has a relation to the Client, which follows this rule:
- If there is a Auth.UserName property set, User PDStorage works with the Username
- If there is no UserName, PDStorage binds to the IP Address
This is important to keep in mind.
So my idea is the following: I have three next-hop proxies in my test environment. I would like to share the load between two of them ("proxy1" and "proxy2"), and I would like to ensure that one Client keeps talking to the same next-hop proxy, to prevent what was shown in Thorstens drawing above. Additionally I would like to have fail-over capability, which means that if one of the next-hop proxies goes down, the other one will be used.
What I do is, I calculate a specific "ProxyID" for each request coming in. The "ProxyID" is remembered in the PDStorage for 15 minutes, This looks like this:
- A request is coming in, MWG checks if there is already a "ProxyID" in PDStorage
a) There is already a ProxyID
- MWG will use the ProxyID to determine which next-hop proxy to use
- The request will leave MWG
b) There is no ProxyID
- MWG will set ProxyID
- The ProxyID will be incremented by 1
- The ProxyID will be set to PDStorage
- The request will leave MWG
To have all clients equally balanced I use a very simple round-robin mechanism. I have a Global PDStorage Variable which iterates from 1 to 4. Whenever a ProxyID is specified for a client, it will be incremented by 1, so the first Client receives the ProxyID "1", the second Client receives ProxyID "2", the next one "3", the next one "4" and finally the next Client coming in gets "1" again, etc.
For ProxyID 1 and 3 I assign next-hop proxy list one, which is setup to point to "proxy1", wich "proxy2" as a failover.
For ProxyID 2 and 4 I assign next-hop proxy list two, which is setup to point to "proxy2", with "proxy1" as a failover.
If a Client is persistently talking to MWG, it will keep its ProxyID and will always talk to his associated next-hop proxy first. If a Client is not seen for 15 minutes, MWG forgets about the ProxyID, and a new ProxyID will be calculated when a new request comes in.
This is the basic idea and my first tests looked pretty good so far.
I will attach the rule set. It is as it is right now, most likely changes are required, I cannot guarantee it is perfectly working in the current version, it should just show what may be possible. Additionally it will not replace a full-featured load-balancer. It does not notice if there is one Client causing a lot of requests and others do not, so the load will not be balanced equally if we look at load or req/s as a metric. The number of Clients per next-hop should be pretty balanced though.
Have a look if you like. I recommend to put the calculation part of the rules to the very beginning. In a reverse Proxy environment it may not be possible to determine the next-hop proxy to use in the beginning of the policy, in this case you may have to move the "Set Next-Hop Proxy" Rule set to a different location.
Let me know what you think.
your ruleset is working fine. :-)