WAF errors

Hi, Goldy,

I haven't checked the log file, but I also have a yellow dot - it's on a Real Server that's hosted remotely.  I have guessed that it was because the trip-time between the UTM and the web server was long enough to trigger a warning of some sort.  Hopefully, someone is familiar with these phenomena and will inform us.

Cheers - Bob

Hi Bob.
Thanks for responding.

Can you please check and see if its look similar in your logs?

Goldy, I don't see that error in the log over the last year.

Cheers - Bob

Hi everyone,

I am implementing a WAF with six real servers, everything works well but after a while the real server that take the request of one client shows yellow dot instead of green, so the WAF move the client to another available (without yellow dot) real server...that behavior cause session loss; I think the problem is what BAlfson says about the communication time between UTM and real servers. Any help to solve this problem will really appreciated.

Hi, uchihanorman, and welcome to the User BB!

Until I was aware of your issue, I hadn't realized that the yellow dot had an effect on the behavior of the WAF.  I assumed that it had to do with one of the conntrack timeouts, and a little experimentation showed that it does.  I thought it might be ip_conntrack_icmp_timeout, but its default is 600 and ping times to our external server were less than 80ms.

Then, I tried using Ulrich Weber's tip from 2011-10-18:

cc set packetfilter timeouts ip_conntrack_udp_timeout 90

and that immediately caused the dot to become green.

I then set it back to the default, 30, but the dot stayed green, and it stayed green even when I disabled and then re-enabled WAF.  To complete the experiment, I rebooted.  When WebAdmin came back up, the dot was yellow again.

So, I suspect that you can determine the max timeout you need from a ping to each of the servers and then set accordingly.  Since this is done with cc, the change will survive Up2Dates and reboots.

Cheers - Bob
PS You didn't mention it, but I assume you have selected "Sticky sessions" in "Site-Path Routing'.

Hi Bob.
Thanks.
unfortunately - didn't work for me. ):
I have already open a case in Astaro and they already escalated my ticket to  3rd line support team for further investigation.
I'll inform here when something will comes out.
Cheers.

Hi Bob,
Thanks for responding, and thanks too for the welcome [:)].

Unfortunately did not work for me either. Yes, "Sticky sessions" in "Site-Path Routing" is selected; I tried to solve the problem setting "ip_conntrack_udp_timeout" and nothing changed also I tried with the other value "ip_conntrack_icmp_timeout" in both cases the behavior didn't change.

I thought the error was the timeout, but now after setting the timeout values I not sure about that. Let me explain you better the error:

For testing we reduce the number of real servers to 3. The 3 real servers initially have the green dot, so, I access with a web browser to the web-application administered by the WAF, one real server attends my request, I log in and after a little interaction (clicks in a couple of links, some consulting, etc.) in a range of 30 seconds to 1 minute the real server's green dot becomes yellow and the WAF switches the server that originally attends me to other one with green dot and so on; obviously in the switch I lose the session because other server takes my request.

It is as the real server is not available for the WAF for some reason, but when I access individually to the real server is available. I wonder if it is a log or something like that where I can see the cause of the error?, I have consulted the WAF log in the web interface and there is nothing and the yellow dot only shows "in error".

Cheers - Norman
PS Sorry about my english, I'm not a full English speaker :S

Hi Norman. 
By any chance, the problematic server is a mail server?
I have four server in the WAF. 
It seems that only the Mail server couseing this errors. 
Also - not sure about it - but I have the feeling it has something to do with active sync.

Goldy, since I didn't see the same error in the logfiles, it appears that we don't have the same problem. 

Norman, is there anything in the log similar to what Goldy is seeing.  What are the ping times to the real servers from the UTM?  

Cheers - Bob

Sorry for any short responses.  Posted from my iPhone.

Hi, everyone and sorry for the late response.

Goldy, no, it's not a mail-server...it's a web-application server.

Bob, I don't see any error in the Web Application Server Log. These are the ping times between real servers and UTM (Statistics):

1-9507/9507 packets, 0% loss, min/avg/ewma/max = 0.132/0.497/0.307/15.435 ms
2-9507/9507 packets, 0% loss, min/avg/ewma/max = 0.128/0.654/0.360/19.319 ms
3-9507/9507 packets, 0% loss, min/avg/ewma/max = 0.129/0.470/0.252/19.977 ms

Cheers - Norman
Thanks for your help