NAT is not working in specific situation

[Alen]

Last Saturday I finally installed and activated Wingate. But, as a result, I did not replace our old gateway, because I wasn't able to solve one small problem. And now we are still using the old system.

I made all settings as wanted: Guest was removed from the "Users" group, default rights where removed, after my users were granted necessary rights. I also made necessary assumptions, as I am using "No authentication with Assumed users" mode.
I setup only DNS and ENS system services for all of my users (plus RCS for Admins and security officers), other system services disabled; and WWW and FTP Proxies (plus LogFile server for Admins and security officers), other user services deleted.

After setting Wingate address and appropriate port as Proxy on a test client browser Internet worked fine! => Proxy service is working, client has necessary rights.
I also need for some sites and addresses (and only them) to be accessed via NAT, not proxy. What I did for it:
1. NAT was enabled, necessary rights granted, with white list (Advanced tab, separate filters with one criterion in each: like, say, "Server name" contains "www.test.com" and "Server ip" equals 100.100.100.100).
2. Traffic interception (Transparent proxy) disabled in the used user services, including web proxy.
3. On the client's browser "www.test.com" added to the list of exceptions - sites, which has to be accessed by not using proxy.

The result: site is not accessible!
I checked "nslookup http://www.test.com" - it resolves name ok (but wrote DNS server is unknown - is this ok?). So the problem is not DNS, it is NAT. But what could be the reason?
I checked bindings, recipients and granted rights, everything seems to be ok.

P.S. Just in case it is important: I also made some OS security tunings:
- disable NBT on all interfaces
- disable OS services bindings on all interfaces, except “F&P sharing for MS Networks” on LAN
- in security policy changed some settings, but I think only one could be important for the issue: "Access this computer from the network". I grant this privilege to Admins and SO users only.

Need your help.

P.P.S.S. As proxy is working and DNS is working too, the problem must be in NAT, and most probably in NAT access rights. But everything is ok there: required group has “Can access this service” right with “User may be assumed” option plus in the System policy the same group has “Users can access services” right also with “User may be assumed” option (Default rights = MUST also be granted). Plus for NAT the above mentioned filters are applied.
I did not try without any filters for NAT, was too tired. Right now I can not try it, users are working. I want to analise and understand all possible reasons, then I'll try again in dinner hours.

I want to mention again: web proxy is working for the test user, DNS resolves site name for the user, but the site is not opening...

[genie]

Hi,
Have you tried ENS/TR with no restrictions (just to make sure ENS is functional)?

[Alen]

Have you tried ENS/TR with no restrictions (just to make sure ENS is functional)?

No. But I'll try to try it ;-) today during dinner hours.

I'll try NAT with TR, if it works - NAT without TR and without restrictions (just to check restrictions correctness, nevertheless I am sure everything is fine there).
What else? I'll try to make ping of non-working site (not sure this will give us any info, but I can't think out anything else...)

[genie]

Pinging does not involve TR process - meaning that traffic is handled in the driver without being passed up to the engine - it is good it works, though, but, please, let us know if this non-TR test for HTTP goes through.

[Alen]

Pinging does not involve TR process - meaning that traffic is handled in the driver without being passed up to the engine - it is good it works, though, but, please, let us know if this non-TR test for HTTP goes through.

genie
You hurt me ;-).
Of course I know ping does not involve transparent redirection, because (if we talk about web proxy) TR intercepts traffic directed to 80-th port, which has nothing to do with ping.
I want to try ping from LAN cleint, as if it works => NAT is working (I don't think it will work though, it shouldn't, but why not check...).

[Alen]

Tests done:
1. NAT with TR enabled for web proxy - the site is accessible!
2. Ping to Internet address (url: google.com) is not going (what was expected), but one more time I saw DNS is resolving names.

What may be the reason?
As I understand, NAT (ENS) restrictions (particularly white list created in Advanced tab of ENS service policy) are working also when TR is enabled. And thus this means the problem is not in restritions either!?

What could be the reason?
Default gateway and DNS ip are specified on the client PC (and both are Wingate server LAN ip).

So pure proxy and NAT+TR work fine, pure NAT doesn't!?
What else to check? (I also enabled Everyone can access from the network Wingate PC OS policy I changed previously, this doesn't help too, as was also expected).

[adrien]

Tests done:
1. NAT with TR enabled for web proxy - the site is accessible!
2. Ping to Internet address (url: google.com) is not going (what was expected), but one more time I saw DNS is resolving names.

What may be the reason?
As I understand, NAT (ENS) restrictions (particularly white list created in Advanced tab of ENS service policy) are working also when TR is enabled. And thus this means the problem is not in restritions either!?

I just checked the source code. When we intercept a connection, then report it to the engine, The ENS policies are not checked, so it will then only use the proxy policy.

We had one other report of problems with ENS policies that check server IP. There were some changes in this area in 6.6.4. If you change your ENS policy to not mandate a specific server IP does it grant access then? I may have introduced a bug in 6.6.4, we need to try and replicate.

What could be the reason?
Default gateway and DNS ip are specified on the client PC (and both are Wingate server LAN ip).

So pure proxy and NAT+TR work fine, pure NAT doesn't!?
What else to check? (I also enabled Everyone can access from the network Wingate PC OS policy I changed previously, this doesn't help too, as was also expected).

[Alen]

I just checked the source code. When we intercept a connection, then report it to the engine, The ENS policies are not checked, so it will then only use the proxy policy.
We had one other report of problems with ENS policies that check server IP. There were some changes in this area in 6.6.4. If you change your ENS policy to not mandate a specific server IP does it grant access then? I may have introduced a bug in 6.6.4, we need to try and replicate.

Well, I see now.
I don't remember if I tried without restrictions. I'll try today and report.

[Alen]

Finally tried without restrictions.
The result: NAT is working.
As soon as I add even one filter with one criterion in Advanced tab, particularly "Server name" contains "google", google.com becomes inaccessible (I remind you the target is to allow only a few sites and ips to be accessible via NAT)!
So, the problem is in filters!

And some more strange things: when I was adding filters, I mention the glitches with filter numbers. For example, after adding filter 3 I got again filter 3 when added next filter!
Besides, today during the test I create and delete many filters, and every time I added new filter after cleaning all filters I got the next number, e.g. filter 8, not filter 1, as it should be...


Adrien, I can't deploy Wingate until I solve the problem. Is any possibility to solve it fast or I have to wait till next update?

[Alen]

I just checked the source code. When we intercept a connection, then report it to the engine, The ENS policies are not checked, so it will then only use the proxy policy.

BTW, I think this is absolutely wrong. Users (me for example) expect Wingate is checking NAT policies, even if TR is used! I think NAT policies should be checked first, and then policies of the respective proxy. (But of course, the best is to add an option - checkbox: whether to check intercepted traffic by the "native" (NAT in this case) policies first before sending to intercepter-proxies).

[adrien]

Finally tried without restrictions.
The result: NAT is working.
As soon as I add even one filter with one criterion in Advanced tab, particularly "Server name" contains "google", google.com becomes inaccessible (I remind you the target is to allow only a few sites and ips to be accessible via NAT)!
So, the problem is in filters!

I wouldn't expect the "Server name" criterion to work for NAT against a site name, since the SYN packet only contains an IP address, and we'd have to rely on reverse DNS. In fact I don't think we do reverse DNS for NAT to try and figure out a server name. I checked the code, and it just converts the server IP to a string, so you'd have something like "210.55.214.35" rather than "smtp.qbik.com".

So if you were checking against contains google, then it would fail on all sites (even google, since it would be comparing the IP).

Did you test with a Server IP criterion?

And some more strange things: when I was adding filters, I mention the glitches with filter numbers. For example, after adding filter 3 I got again filter 3 when added next filter!
Besides, today during the test I create and delete many filters, and every time I added new filter after cleaning all filters I got the next number, e.g. filter 8, not filter 1, as it should be...

The filter name is not used for anything except display purposes, and we expect that you would normally rename it to something meaningful, so the ID it chooses shouldn't be critical. I think it uses a global static number which starts at 1 each time you open GateKeeper, and increments for any filter in any policy. Otherwise we'd need to go through all filters in a policy to try and figure out what default name to call the next one.

Adrien, I can't deploy Wingate until I solve the problem. Is any possibility to solve it fast or I have to wait till next update?

Can you try the Server IP Criterion and see if it works?

[adrien]

I just checked the source code. When we intercept a connection, then report it to the engine, The ENS policies are not checked, so it will then only use the proxy policy.

BTW, I think this is absolutely wrong. Users (me for example) expect Wingate is checking NAT policies, even if TR is used! I think NAT policies should be checked first, and then policies of the respective proxy. (But of course, the best is to add an option - checkbox: whether to check intercepted traffic by the "native" (NAT in this case) policies first before sending to intercepter-proxies).

I think this would create many problems, since it would be easy to break intercepts with ENS policy. Once the proxy has the connection, you can exert a lot more policy control over it than ENS policy can.

[Alen]

I wouldn't expect the "Server name" criterion to work for NAT against a site name, since the SYN packet only contains an IP address, and we'd have to rely on reverse DNS.
In fact I don't think we do reverse DNS for NAT to try and figure out a server name. I checked the code, and it just converts the server IP to a string, so you'd have something like "210.55.214.35" rather than "smtp.qbik.com".So if you were checking against contains google, then it would fail on all sites (even google, since it would be comparing the IP).

I see. Ok , I'll try by ip and let you know.

I think this would create many problems, since it would be easy to break intercepts with ENS policy. Once the proxy has the connection, you can exert a lot more policy control over it than ENS policy can.

Yes, you are write, I forget (again), in Wingate we can only add permissions, not restrictions to the existed rights (this is really unusual for me)...

[Alen]

I tried filters with server ip criterions.
Honestly I tried it with ping, not web surfing (was in a hurry), but I think it's not important. (I added an allowed ip and ping went, the same time ping to another pingable address, which was not in a white list - did not).
So it is working.


But one program is still not working: I monitor the ip it is trying to connect and add it in the NAT white list - it's not working.
Today I'll try to find out anything from the program developers.
Meanwhile, I went another way, just add clients ips, who are using that program, to NAT clients white list. But this is temporary solution.

I'll come back with some more info about the problematic app.

[Alen]

Today the app works with the same settings!? A miracle...

All my NAT specific issues are solved for now.


P.S.

When we intercept a connection, then report it to the engine, The ENS policies are not checked, so it will then only use the proxy policy.

I wouldn't expect the "Server name" criterion to work for NAT against a site name

May be these have quite logical explanations, when you already know it, but the facts themselves are not obvoius.
=> This MUST be added to the help!

Thank you for your help, Adrien.