nothing gets block with this new version

[n0ticer]

since the deerfield version, until the 2nd to the latest build 1315 my policy is working.

now with 1321 even alexa.com (one of my oldest restricted sites can show thru). any advise guys?

[adrien]

Hi

We didn't change anything with policy in this version since 6.6.2.1315. Did you make any changes to policy?

Can you send us in your WinGate registry so we can check your policy?

Just send it to support@wingate.com

Regards

Adrien

[n0ticer]

thank you for the reply adrien...

i didnt change anything, my wingate server is headless (no keyboard/mouse, no monitor, running 24/7 and its 12yrs old :D)

i only deleted history.* file thing, then restart wingate. my policy is back to normal. it seems every upgrade or update, those files should be deleted first.

i'll post for other errors if any. ty

[ALainONE]

Hello!

This is also TRUE for me! I've recently updated my version to 6.6.3 B1321 and everyone now can access any website! The first time they try to open the site, the browser will show "Access Denied!" but when they try to enter the site on the address bar (a couple of tries), they get connected --- even if my history shows them with "Access Denied" on the Activity column.

I have not tried deleting my history.* files on the wingate directory... will let you know if I have the same results!

FYI:
Alain Garcia
Alain.Garcia@Strabag-Oman.com

[adrien]

Hi Alain

Deleting the history shouldn't make any difference.

we have found recently issues with Firefox authenticating against the Guest account using NTLM. If this is happening, you may need to either

a) disable the Guest account in Local Users and Groups; or
b) give the Guest account a password; or
c) in WinGate policy don't grant rights to the proxy to the Guest user.

How are your users configured to authenticate? Which user database are you using in WinGate?

Regards

Adrien

[ALainONE]

Hello, Adrien!

Yes, my users are using Firefox as their browser!

I'm using NTLM for authentication. The guest account is disabled by default in Windows Server 2003 (where my WinGate resides).

I will try to put a password on the NTLM guest account and check if this will fix it. I would also like to try NOT GIVE permission on the Guest Account on the policies - but i'm a bit confused... do I deny permission on the system policies or just at the www-proxy policies? And how do I deny it?

Also, one question comes to mind... we are using MS Outlook for our emails. Whenever a user send/recieve emails, it always turns out on the WinGate History as a Guest Account - will changing the guest account setting be a problem for this? Will my users still be able to send/recieve emails with no problems at all?

Thank you very much!

Alain Garcia
Alain.Garcia@Strabag-Oman.com

[adrien]

Hi Alain

WinGate allows you to separately control the Guest account as used by WinGate vs the OS Guest account.

WinGate doesn't require the Guest account in the OS to be enabled, but some services in WinGate need the Guest account to be enabled in WinGate. So it can be enabled in WinGate, but disabled in the OS.

To not grant rights to Guest, the easiest way is to create a group, put all users in it that are allowed access, and then grant access to that group in WinGate policy.

Whether that's in the WWW proxy policy or in system policy depends on whether the WWW proxy policy uses the system policy or not - since you have control over this. If your WWW proxy policy is set to ignore system policy, you would need to change the WWW proxy policy.

Adrien

[adrien]

Hi Alain

We just found today another issue introduced with the new proxy in 6.6.0 relating to policy. It's to do with the order in which WinGate does DNS lookups vs checking policy. It's a chicken and egg problem for people with dialup who want to set policy using ServerIP criteria.

people on dialup don't want WinGate to dial for a site that will be blocked. In order to look up server IP for policy, you must first be connected. So the old WinGate would actually check policy several times, before and after dialing and looking up the server IP.

With WinGate 6.6 we tried to reduce the number of times policy would be checked for the same request to improve performance, but this has resulted in a problem now where if you have policy that checks Server IP, it will grant access regardless of the actual server IP.

this could explain your policy issues. Do you have policy that checks server IP?

Regards

Adrien

[n0ticer]

yes deleting history files doesnt make any difference, maybe restarting wingate has fix it, i just didnt elaborate on that post. but before the restart & deletion of such history files, my policy is actually working only at NAT. i tried restricting alexa via ENS and WG blocks it... problem is majority of my restrictions is applied at www proxy service. anyway, now i got no prob with restrictions after that restart. what i am experiencing now in workstation, is im getting complete download (around 1 gig as an example) but after clicking OK as the browser prompts (stating it is 1 gb already) that the download is complete the downloaded files size is only around 240+ mb. never had this issue before that build.

[adrien]

Hi

I think we will need a packet capture to figure out what is going on there.

Are you able to turn on capturing in WinGate (with a filter for HTTP) and try a link you know fails and send the capture file into our support desk? If it's too big email it to me directly at adrien at qbik dot com.

Thanks

Adrien

[n0ticer]

im out of town right now... maybe in my return. anyway if there are no other person experiencing this issue i will try figuring out this myself first. i will try downloading with & without caching enabled soon to see results. thanks

[ALainONE]

Hi Alain

We just found today another issue introduced with the new proxy in 6.6.0 relating to policy. It's to do with the order in which WinGate does DNS lookups vs checking policy. It's a chicken and egg problem for people with dialup who want to set policy using ServerIP criteria.

people on dialup don't want WinGate to dial for a site that will be blocked. In order to look up server IP for policy, you must first be connected. So the old WinGate would actually check policy several times, before and after dialing and looking up the server IP.

With WinGate 6.6 we tried to reduce the number of times policy would be checked for the same request to improve performance, but this has resulted in a problem now where if you have policy that checks Server IP, it will grant access regardless of the actual server IP.

this could explain your policy issues. Do you have policy that checks server IP?

Regards

Adrien

Hello, Adrien!

Sorry for the very late reply. I was on leave...

Yes! I have policies that check against server ip - on Extendeded Networking, WWW Proxy Server and [especially] System Policies.

Anyways, I have reconfigured my rules and removed most of them on the System Policies. Blocking now works as before. But came face with a different problem with my outlook timing out and not able to send emails with attachments greater than 1MB (this is for a different post).

Also, found out that assumed users based on ip addresses could not access some of my server applications. Can this be also connected to the server ip policies?

Best regards,
Alain Garcia
Alain.Garcia@Strabag-Oman.com

[adrien]

Hi

how are those clients accessing your server applications? Is this using HTTP?

Regards

Adrien

[ALainONE]

Hello, Adrien!

No! Client PCs access server apps by means of mapped drives.

I deleted all my "assume users by ip address" policy and now everything is OK again. Instead of assuming by ip, i have configured it to assume by computer name.