i have a couple of WSA670s behind a big ip load balancer and this week, after a feature key update, i'm getting occasional problems with authentication when accessing https sites
i'm running in transparent mode but with the big ip configured as an explicit proxy in the user's browser
i using 7.7.0-608
when users attempt to access a https site the page isn't always served, sometimes is does, sometime it doesn't
if i check the the accesslog i see a TCP 407/DENIED
if i then go to open a new tab and another https site, ie google, i can get access and if i go back to the tab that didn't work and refresh it now works
the accesslogs shows the traffic as authenticated
i can't allow any unauthenticated traffic
can anyone give me any help or point me in the right direction?
thanks to anyone replying
How does the F5 load balancer determine which WSA to send traffic to?
When the request leaves the F5, what is the Source IP address?
What surrogate type are you using? (IP Address/Session Cookie/Persistent Cookie).
You may want to take a packet capture at the WSA while the issue is occuring to make sure that it is indeed authenticating to the WSA that wants to authenticate the user.
many thanks for your reply
the f5 is configured with a pool of proxy servers (ironports) and uses irules to forward internet traffic to one set of proxies and intranet traffic to another set of proxies
the source address of the traffic leaving the f5s is the expected f5 ip address but x-forwarding is configured and i can see the client address in my accecsslogs
we are using ip address as the surrogate
i can see the traffic hitting the correct wsa on the f5 through a source ip based persistence policy on the f5 and in the accesslogs of the wsa, if i tail on my other wsas there is no traffic from my source ip
all http traffic works fine, the problem only happens with occasional https traffic
i'm considering enabling the https proxy and just traffic without decrypting it but i'm not sure if this is relevant to my issue
I too am seeing TCP_DENIED/407 on SSL's... I have No Surrogate enabled due to we have alot of XenApp servers , maybe this is wrong.... mulhollandm do you have No Surrogate on your identity policies?
I see some potential problems with your setup.
If the request is leaving the F5 with its own IP address as the Source, and when your user authenticates, the WSA will associate that user with the F5's IP address. Authentication does not take the XFF header into consideration. If you have not run into problems with this, chances are that you are not using any surrogates (see the option to Apply Same Surrogate Type For Explicit Forward Requests).
If all you saw is a 407 when it does not work, this pretty much narrows it down to an authentication problem I suppose.
Can you post the actual Access Log entries when the issue occurs?
apologies for the delay, here's a sample log entry
both of these are from the same log
1383782289.013 149 10.63.132.227 TCP_DENIED/407 0 CONNECT tunnel://www.eventtouch.eu:443/
- NONE/- - OTHER-NONE-All_Authenticated_Users-NONE-NONE-NONE-NONE
-","-" > - "10.63.132.227"
1383782479.285 547 10.63.132.227 TCP_CLIENT_REFRESH_MISS/200 3814 CONNECT
tunnel://www.eventtouch.eu:443/ "**********\1028009@**********" DIRECT/www.eventtouch.eu
Based on the logs, it appears when it is not working, it needs authentication. When it is working, authentication was not needed.
Do you think it is possible that when you open a new tab, you are hitting a home page that authenticates the user correctly? Then when going back to the previous tab, you refresh, which no longer requires authentication since you did on the last tab?
thanks again for replyingto my posts, its greatly appreciated
you're right in that the new tab opens to an intranet home page that authenticates the user - this works most of the time but not all
is there a resolution to this
i can't have an authentication bypass for https as it against policy
i don't have the https proxy enabled - would this help?
Some sites just do not work with authentication and there is no way around it for now with your setup.
Right now, it sounds like that particular destination has trouble authenticating. Are you able to bypass that site from authentication?