NAT Time Restrictions

[Skippy]

Hello,

I’m currently evaluating WinGate (ver 6.2.2) and as I learn more and get things setup the way I want, I’m really liking WinGate. (I’m one of those looking for a Winproxy replacement.)

However, I’m having a problem setting up time restrictions for NAT with the way I have my authentication setup.

I have a user that is setup to “User must be authenticated” in the WWW Proxy server and that same user is setup to “User may be assumed” in Extended Networking. Then, when I setup time restrictions in Extended Networking for that user, the user is unable to connect through NAT whether or not it’s during the specified time.

With this same user, if I change the WWW Proxy server authentication to “User may be assumed”, then the time restrictions in Extended Networking function as they should.

Why would this happen this way and is there a way to get the time restrictions in Extended Networking to function properly and still require the user to authenticate in the WWW Proxy server, but be assumed in Extended Networking?

Thanks,
Glenn

[Skippy]

Does anybody have any ideas on this?

[adrien]

Hi

One of the less-than-intuitive aspects of WinGate 6.x and prior is the 3 levels of authentication. Or more correctly the 3 levels of certainty about who a user is.

at the bottom level, you have Guest. This means that WinGate has no idea who the user is, and the account that any action is performed in is the Guest account . Then you have "assumed", this means that WinGate assumes who the user is based on certain criteria, being any of

a) an explicit assumption has been configured (on the users tab)
b) a weak authentication mechanism has been used
c) the client IP has been recently authenticated (standard window is 30s).

The top level is "authenticated", which means that the user used a strong auth method to authenticate to WinGate.

The thing that gets people is the distinction between assumed and authenticated or especially strong vs weak authentication methods. In general any plaintext method is deemed weak (HTTP Basic, POP3 USER/PASS, SASL PLAIN, SASL LOGIN). In fact we are dropping this distinction for WinGate 7 because of the confusion it causes.

Another key issue is inheritance of credentials.

When a client application connects to Wingate from an IP, and authenticates, the credentials are then associated with the "machine" (the IP). Any subsequent connections from that machine (same IP) are deemed to be for the same user. This means that if one session authenticates, then normally no others need to - they are deemed authenticated because they inherited credentials from the first connection.

When all sessions from an IP are disconnected, the normal behaviour is to immediately drop the auth level back to assumed, and then after 30s, to remove the "machine" which then destroys the association completely.

These behaviours are overridable with registry keys, or in the case of Multi-user IPs (in which case credentials are not inherited).

So, to explain what you're seeing, I'd need to know how your user is authenticating to the WWW proxy.

Regards

Adrien

[Skippy]

adrien,

Thank you for your response.

So, to explain what you're seeing, I'd need to know how your user is authenticating to the WWW proxy.

The WWW Proxy is setup to authenticate using the Java Client.

And just for additional information:

I have the IP address of this user setup to be assumed as the user ID.

I have Extending Networking setup to allow users to be assumed to avoid the necessity to open a browser window and login before being able to use NAT.

Please let me know if you need to know anything else.

Thanks,
Glenn

[logan]

Hi Glenn,

Can you give us an example of how you are using the ENS policy to restrict times for for NAT?

If you are using the Time tab from a policy, one thing to note is that the exluded times are there to create exclusions within already included times. For example, you could use the time tab to make the policy effective between 9am and 5pm, but exclude lunchtime at 12pm to 1pm.

You cannot create an exclusion from nothing, so if you only create excluded times without any included times, the policy is effectively saying 'don't let the user connect at any time'.


How you have your policies setup with the user assumptions for NAT and java authentication for WWW Proxy is a perfectly valid scenario. In fact, I have set it up here and can confirm that it works as expected. That is why I'm being lead to believe the problem may be with the way you have used time restrictions in your NAT policy.

If you are still having troubles, I would be more than happy to take a look at your configuration file for you. You can either send it to my email address as an attachment or create a new support ticket in the online helpdesk and include it with that.

GateKeeper --> Options menu --> Advanced --> Save Registry

Best regards,

[Skippy]

Can you give us an example of how you are using the ENS policy to restrict times for for NAT?

logan,

I had actually made the mistake you mention with using the excluded times incorrectly, but I had figured that out.

One of the setups I tried that didn't work was something like:

Included times - Friday 4:30pm to 11:59pm, Saturday (all day), Sunday 12:00am to 7:30pm.

Excluded times - Nothing.

Let me know if you see any problems with this setup. If not, I will take you up on your offer and I'll send you my configuration file.

Thanks,
Glenn