Many questions and a few comments after reading Wingate help

Use this forum to post questions relating to WinGate, feature requests, technical or configuration problems

Moderator: Qbik Staff

Many questions and a few comments after reading Wingate help

Postby Alen » Nov 13 09 12:43 am

I am preparing to deploy Wingate and after reading help and install guides have some questions and comments. Here is the first part, the second part will be later.

Thanks in advance (especialy to Logan ;-))


Questions:

1. Citate: “By default everyone is given access to the Internet (or the appropriate services in WinGate) until restricted by policies”.
Is this because of NAT enabled, Proxies enabled and binded to internal interfaces and Guest user account enabled by default?
Is disabling Guest prevent users from accessing Internet until specially setting up for it and/or granting access? Or in case client computer has necessary settings (DG + DNS ips for NAT and Proxy address for Proxy) he wil be able to connect to the Internet even after Guest is disabled? (Everything else by default)


2. I want to centralize Internet connections of my remote branches. Let’s suppose:
 I have normally working routing between head office (192.168.0.0 /24) via central router (192.168.0.1) and branch (192.168.n.0 /24) via branch router (192.168.n.1), n = 1,..,9
 I have Wingate server in the head office (with LAN ip = 192.168.200.10) connected to the central router’s WAN (192.168.200.1, where 192.168.200.0 is just an auxiliary subnetwork)
 and I register routes to the head office and branches LANs on Wingate (route add 192.168.0.0 mask 255.255.255.0 192.168.200.1) and thus I can ping Wingate from the head office and branch hosts.

The question: will Wingate be able to provide Internet for the all users by using Assumed (by hosts ips) users “authorization” method?
Is it a problem Wingate will be from the other ip subnetwork than head office and branches hosts (and all of them between each other)!?


3. In installation help it is written for NAT connection method in clients configuration section to set Wingate’s private ip as Preffered DNS server, but nothing is said (in the same place) about the necessity to enable Wingate’s DNS server and\or DNS resolver.
As I understand it will not work without DNS resolver\ server activated?!


4. It is recommended and usual that we have private ip on LAN interface and public – on WAN interface, but nothing is said about address of DMZ interface. What is recommended: private ip from another subnet than LAN interface ip or what? (I want to add 3-rd interface in Wingate server for DMZ and planning network infrastructure)


5. If using NAT + Transparent proxy for HTTP, is it possible to exclude some sites (on Wingate server) from going through proxy? This is needful in case some applications working via SSL can not correctly work via proxy.
And as I understand one Web Proxy (can) services requests received on two ports 80 and 443. Is this correct?


6. How can we restrict users access to Internet connected by pure NAT connection method? Only by port filtering on firewall and websites ban?


7. As I understand it is possible to use “pure” proxy connection method with Wingate. The same time there is no requirements for clients’ ips to be public ips. Does this mean that even when only web proxy is being used, Internet traffic is NATed anyway (but just for HTTP traffic in this case)? I am asking because AFAIK pure web proxy has to make changes only at 7-th, Application, layer, but here we have also source ip change, which is NAT function (and is made on 3-rd and 4-th layers).


8. Is it possible to use AD user database for authorizatuions, and somehow keep using PCs ip based restrictions too (like assumed users). I mean for the same users. E.g., domain user JSmith is allowed to have access to Internet, but only from his PC (192.168.0.11). How can this be done on Wingate?


9. Can NAT support server applications? In the help we have:
In most circumstances NAT will support listening servers. There are some requirements:
 The running the server must have a static IP.
 You must set up a port redirect on the Port Security configuration of ENS.
This will forward incoming connections to the server. This approach may not always work if multiple data
connections are set up between server and client. Mapped links are a superior method.

And why mapped links should work better? What is the difference between the two methods? Port forwarding is just resending to particular host of all traffic received on particular port. Isn’t mapped link the same? Or it is like bidirectional proxy? Anyway, why it is claimed to be better?


10. In Wingate we have Activity tab, where we can see currently active sessions, in History tab – sessions occurred since last logon of Internet users and we also have service logs + user audit files, where we can find all past activities per session and per user. Besides, we have system messages tab where we can found the latest 1000 system messages. A question: do we have a system log, where all past system messages are stored? Or we lose old messages? Or they are mostly spreaded in System services logs?
And the same question about intrusion attempts, current part of which can be seen on Firewall tab. What about logging this events in a file? I am sure it is done, but where?

P.S. I think it is better to add a small description of Wingate’s all abilities in monitoring and logging. Like this: “For monitoring of current sessions (user activities) see Activity tab, of system events – System messages tab, for intrusion attempts – Firewall tab. For archive of user activities or use of services look at xxx files (you had to activate necessary logging options previously), for archive of system events see yyy file, for archive of intrusion attempts look at zzz file”.


11. About Quarantine.
Citate:
“When WinGate’s data scanning plugins detect inappropriate data (e.g. a virus), it needs to be either thrown away or stored in a safe place. Quarantining is the safe storage option.
+ The files are stored in the WinGate\Quarantine directory.
+ If an Administrator releases a file through the GateKeeper interface, the file is flagged as 'released '. This
means that a user is allowed a file again.
The file is copied to the WinGate\Quarantine\Release\"Source"\"Context" directory. e.g. If a file called virus.exe is downloaded from ftp://bad.server.com/nasty/virus.exe through the FTP proxy, it will be released to WinGate\Quarantine\Release\FTPProxy\nasty\virus.exe

The administrator is responsible for returning the file to the user”.

- Does this mean, that if Admin wants to allow file, he should first “release” it and then cut from the WinGate\Quarantine\Release\"Source"\"Context" directory and transfer to the user manually?



12. What is the option “Enable ARP responder” for? Need a couple of usage examples.
I tried to understand and proposed the following examples: this option can be used for Wingate server to service several public ips. For example: 1) if we have web servers inside our LAN, but they are registered on DNS server with particular public ips and Wingate is the one who actualy receives requests to that registered ips and then makes port forwarding (or mapped link?) to them. 2) For dynamic NAT (many public ips to many local PCs).
Are these the case?
And how this option is connected to mapped links (if it is)?


13. Is it safe to preserve network interfaces Auto usage detection? Particularly in case of 2 interfaces: LAN with private ip and WAN with public ip? And in case of 3 interfaces: LAN with private ip, DMZ with private ip and WAN with public ip?
Does Wingate detect interface usage each time the server is started\restarted if we use autodetection? What if we set usage manually?
Did you have cases when because of glithes program errors users got wrongly detected interfaces usage (after regular server restart, for example)?
Obviously in case of wrong interface usage auto detection, we could get external interface binded to the services, which is extremely dangerous. So isn’t it better to set interface usage manually (but keep using autobinding with the binding policy “Any Internal Adapter”, which binds only Internal interfaces to services) once and sleep tight?


14. What will happen, if we choose to set interface usage manually and one day Wingate found a new interface (two cases: 1. the new interface is just an additional one; 2. it was installed instead of one of the existed: Internal or External)?! (In case the only criteria for Wingate is interface ip being public or private, let’s suppose all interfaces have public or all have private ips).


15. How to setup binding policies if we have 3 interfaces (LAN, DMZ, WAN)?
In binding policy setup window screenshot I can see only “Any Internal Adapter”, “Any External Adapter” and “Any adapter” settings for “autobinding” (we also can make bindings manually by choosing particular adapters for each service, but I found this inconvinient, plus in opposite with the interface usage autodetection, allowing autobinding “Internal Adapters” only is more secure than mannual bindings). So how to setup (auto)binding policy when we also have DMZ interface?
Do we get a new choice “Any DMZ Adapter”? Or DMZ interface is included in “Any External Adapter” as according to Wingate DMZ is: “A secure external (sic!) network”.
The question is just about what to do if we want to bind not only LAN interface to a service, but also DMZ and not WAN, or bind DMZ interface only?
Honestly, I don’t see such necessity for now, but just want to be ready for it.


16. Override Service port (option in Bindings tab of Wingate services)
As I understand this is for redefinition of service port. For example for local client applications to use port 8080 for http requests instead of standard port 80. So it will look like {LAN to Wingate http requests use port 8080} – {Wingate to Internet requests use port port 80}.
What is this giving to us?
If we speak about additional security, I can’t understand why and how we get it? I mean, if our proxy is servicing only requests from LAN, then Wingate will refuse requests received on WAN anyway, regardless of the correctness of service port. In case of WAN requests are allowed, the malefactor can easely define http proxy port with port scanner and make requests using the correct port. So where is advantages?
Or we are securing from local clients, who will not be able to connect to the Internet without knowing correct port?


17. Use SYN Cookies (against Syn flood atacks) (option in Bindings tab of Wingate services)
It is written about potential incompatibilities. Can you please explain and give me some examples. I think the option is quite useful and want to understand could it make problems for me.


18. Notify on access (option in Bindings tab of Wingate services)
As all proxy services have their own logs plus all current activities can be seen on Activity tab screen, there is no need to activate this option and overload Firewall tab screen. Am I right? And when this option can be really needful?


19. Citate: “The WGIC hooks into the OS of the client PC and redirects all Network traffic to the WinGate server”. All network traffic? Even LAN, including domain specific? Or this sentence (from WinGateInstall.chm) is incorrect and WGIC analyses traffic and sends to Wingate only Internet requests? (And how it knows they are Internet requests?)



Comments:

1. In many places of the help I see this:
"Since the introduction of using NAT and Transparent redirection abilities in WinGate, there are now very few occasions where you should need to use a proxy directly".
- I disagree. Using NAT allows any application to connect to the Internet using any desired port (if it was not specially disabled by firewall), but proxy method – only particular application which uses particular protocols (= ports)! And thus Proxy (in this context) is more secure.

2. You should add some setup details in the appropriate sections of help for the people who are going to use third: DMZ interface. And the same should be done for the users who have and want to use two Internet connections simultaneously, but with different metrics (desirably this has to be response latencies) for the two interfaces.
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 13 09 11:30 am

Hi - answers below

Alen wrote:1. Citate: “By default everyone is given access to the Internet (or the appropriate services in WinGate) until restricted by policies”.
Is this because of NAT enabled, Proxies enabled and binded to internal interfaces and Guest user account enabled by default?


This is because the default policies grant access to everyone for NAT, and all proxies. So regardless of how a user connects, there have been no restrictions applied by default. You will need to edit policy to apply restrictions. We strongly recommend against disabling the Guest account, as some internal functions require it to be enabled. If you're using the Windows user database, you can disable Guest in the OS, but have it enabled in WinGate. If you don't want guest access to say a proxy, set rules to require authentication, or use groups and/or policy to specify who can use the system.

Alen wrote:Is disabling Guest prevent users from accessing Internet until specially setting up for it and/or granting access? Or in case client computer has necessary settings (DG + DNS ips for NAT and Proxy address for Proxy) he wil be able to connect to the Internet even after Guest is disabled? (Everything else by default)


If you disable Guest, the access won't be granted to users which are using the Guest account for services. However this can have other undesired issues. You can prevent Guest account from using the WWW proxy (say) without having to disable the account. You need to make the policy not grant access to Guest.

Alen wrote:2. I want to centralize Internet connections of my remote branches. Let’s suppose:
 I have normally working routing between head office (192.168.0.0 /24) via central router (192.168.0.1) and branch (192.168.n.0 /24) via branch router (192.168.n.1), n = 1,..,9
 I have Wingate server in the head office (with LAN ip = 192.168.200.10) connected to the central router’s WAN (192.168.200.1, where 192.168.200.0 is just an auxiliary subnetwork)
 and I register routes to the head office and branches LANs on Wingate (route add 192.168.0.0 mask 255.255.255.0 192.168.200.1) and thus I can ping Wingate from the head office and branch hosts.

The question: will Wingate be able to provide Internet for the all users by using Assumed (by hosts ips) users “authorization” method?
Is it a problem Wingate will be from the other ip subnetwork than head office and branches hosts (and all of them between each other)!?


No problem. WinGate still gets the source IP of the connected client, so can do assumptions about the user from that. WinGate doesn't care if the users are on other subnets - if you can ping, then it should work (that means routes are working).

Alen wrote:3. In installation help it is written for NAT connection method in clients configuration section to set Wingate’s private ip as Preffered DNS server, but nothing is said (in the same place) about the necessity to enable Wingate’s DNS server and\or DNS resolver.
As I understand it will not work without DNS resolver\ server activated?!


This isn't strictly correct. If using NAT, then the clients must have access to a DNS server. However, it doesn't need to be WinGate's DNS server, if you have another DNS server available. WinGate's DNS resolver on the other hand is used by WinGate to resolve DNS, and actually can't be turned off anyway. It doesn't depend on the WinGate DNS server though.

On smaller networks it is common to use WinGate's DNS server, but on larger networks and Active Directories, special consideration needs to be given to how all the DNS servers and clients co-operate. for instance if your WinGate machine is on an Active Directory, you must leave the AD DNS servers IP address in your network adapter settings (in the OS). This is contrary to advice in the help file.

Another thing to watch out for in active directory environments is DNS request looping. By default WinGate's DNS resolver will use any DNS server known to the host OS. If the WinGate machine is on an AD, and the AD DNS server is configured to forward requests back out through WinGate, you then have a DNS loop. Client machines on the AD will still need to use the AD DNS server, but WinGate must be prevented from using it (not the WinGate machine, just WinGate's DNS resolver). This can be done by adding the AD DNS server IP address to the DNS servers list in WinGate advanced options applet (in the WinGate start menu).

Alen wrote:4. It is recommended and usual that we have private ip on LAN interface and public – on WAN interface, but nothing is said about address of DMZ interface. What is recommended: private ip from another subnet than LAN interface ip or what? (I want to add 3-rd interface in Wingate server for DMZ and planning network infrastructure)


WinGate doesn't perform network address translation between external interfaces and DMZ interfaces. What this means is that DMZ interfaces use public addresses, since these must be reachable from the internet. WinGate does do NAT between internal interfaces and DMZ interfaces. You don't necessarily need to waste a public IP address on the DMZ adapter itself, since you can use ARP spoofing to get that adapter to respond to ARP requests for the other external WinGate interface, then set the default gateway for your DMZ computers to the IP address of the external WinGate adapter.

Alen wrote:5. If using NAT + Transparent proxy for HTTP, is it possible to exclude some sites (on Wingate server) from going through proxy? This is needful in case some applications working via SSL can not correctly work via proxy.
And as I understand one Web Proxy (can) services requests received on two ports 80 and 443. Is this correct?


When you enable transparent proxy, it sets a rule based only on destination port. So WinGate can't differentiate between different destinations, all destinations will be intercepted if they are going to port 80 (say).

Don't under any circumstances intercept port 443, that will stop https from working (WinGate 7 is different here).

If the client is configured to use a proxy (recommended), then all connections the client makes, to any port will go through the proxy. We find things work better if the client is configured to use a proxy. You can use AD group policy to force clients to use a proxy. In fact we added a policy option in WinGate 6.6.4 to allow blocking intercepted access (thereby forcing clients to configure their browsers to use a proxy).

Alen wrote:6. How can we restrict users access to Internet connected by pure NAT connection method? Only by port filtering on firewall and websites ban?


You can also use the policies in the Extended Networking section. This allows you more control. Be aware however, that the connection is reported to WinGate after the first packet has been sent through. WinGate then evaluates the policy and decides if the connection can be allowed to live. If policy blocks the connection, the connection is terminated. This means there can be the odd packet sneak through.

Alen wrote:7. As I understand it is possible to use “pure” proxy connection method with Wingate. The same time there is no requirements for clients’ ips to be public ips. Does this mean that even when only web proxy is being used, Internet traffic is NATed anyway (but just for HTTP traffic in this case)? I am asking because AFAIK pure web proxy has to make changes only at 7-th, Application, layer, but here we have also source ip change, which is NAT function (and is made on 3-rd and 4-th layers).


If a client uses proxy for HTTP, they make a connection to the WWW proxy. Then WinGate makes a connection to the end server. So it doesn't matter what the client IP address is, as long as it can connect to WinGate, and WinGate allows it. NAT is not used in this case (except for other traffic that doesn't go through the WWW proxy). For example you can use proxy for HTTP (browsers), and NAT for other applications (e.g. email, IM, or whatever)

Alen wrote:8. Is it possible to use AD user database for authorizatuions, and somehow keep using PCs ip based restrictions too (like assumed users). I mean for the same users. E.g., domain user JSmith is allowed to have access to Internet, but only from his PC (192.168.0.11). How can this be done on Wingate?


You need to decide whether the users will authenticate, or be assumed. You can set up policy so that an authenticated user can only access from a certain IP, by setting their IP in the locations tab for the policy that applies only to that user. You would need to set up a policy for each user for this though, or at least for each user that you wish to control in this way.

Alen wrote:9. Can NAT support server applications? In the help we have:
In most circumstances NAT will support listening servers. There are some requirements:
 The running the server must have a static IP.
 You must set up a port redirect on the Port Security configuration of ENS.
This will forward incoming connections to the server. This approach may not always work if multiple data
connections are set up between server and client. Mapped links are a superior method.

And why mapped links should work better?


Actually I don't think that is necessarily correct. Mapped links give you some things, like better logging, some more control. But you get better performance with a port redirect.

Alen wrote:What is the difference between the two methods? Port forwarding is just resending to particular host of all traffic received on particular port. Isn’t mapped link the same? Or it is like bidirectional proxy? Anyway, why it is claimed to be better?


Port redirection results in the connection being handled at the packet level in our packet driver (ENS). Mapped link means the connection comes up to the WinGate engine, another connection is then made, and data is relayed back and forth by the WinGate engine on the 2 connections.

port redirect is faster (since packets don't need to go up and down the network stack on the WinGate computer).
port redirect allows the internal server to know the external client IP (if the internal server is configured to route back out through WinGate).
TCP mapping allows some things, like SSL connections inbound, better logging (protocol sniffing), different destination per client etc. But is slower.

So, no one is better or worse, they are just different for different requirements. We find most people just use port redirects.

Alen wrote:10. In Wingate we have Activity tab, where we can see currently active sessions, in History tab – sessions occurred since last logon of Internet users and we also have service logs + user audit files, where we can find all past activities per session and per user. Besides, we have system messages tab where we can found the latest 1000 system messages. A question: do we have a system log, where all past system messages are stored? Or we lose old messages? Or they are mostly spreaded in System services logs?
And the same question about intrusion attempts, current part of which can be seen on Firewall tab. What about logging this events in a file? I am sure it is done, but where?


These are logged I believe in the WinGate\Logs\System log files. Firewall hits are base64 coded packet data.

Alen wrote:P.S. I think it is better to add a small description of Wingate’s all abilities in monitoring and logging. Like this: “For monitoring of current sessions (user activities) see Activity tab, of system events – System messages tab, for intrusion attempts – Firewall tab. For archive of user activities or use of services look at xxx files (you had to activate necessary logging options previously), for archive of system events see yyy file, for archive of intrusion attempts look at zzz file”.


This is all changing in WinGate 7. There's no more system messages tab (replaced with notification system).

Alen wrote:11. About Quarantine.
Citate:
“When WinGate’s data scanning plugins detect inappropriate data (e.g. a virus), it needs to be either thrown away or stored in a safe place. Quarantining is the safe storage option.
+ The files are stored in the WinGate\Quarantine directory.
+ If an Administrator releases a file through the GateKeeper interface, the file is flagged as 'released '. This
means that a user is allowed a file again.
The file is copied to the WinGate\Quarantine\Release\"Source"\"Context" directory. e.g. If a file called virus.exe is downloaded from ftp://bad.server.com/nasty/virus.exe through the FTP proxy, it will be released to WinGate\Quarantine\Release\FTPProxy\nasty\virus.exe

The administrator is responsible for returning the file to the user”.

- Does this mean, that if Admin wants to allow file, he should first “release” it and then cut from the WinGate\Quarantine\Release\"Source"\"Context" directory and transfer to the user manually?


It depends on what put it in the quarantine. If the file was an email, then releasing it from the quarantine tab will cause the file to go back into the SMTP message delivery queue, and that's all that needs to be done for the recipient to get the file.

For things quarantined by FTP, POP3 or HTTP proxies, yes, they need to be released first, then manually transferred by the administrator to the user. This is because when the file is stored in quarantine, it is modified with some quarantine information. This needs to be removed (by releasing it) before the file can be used by the end user.

Alen wrote:12. What is the option “Enable ARP responder” for? Need a couple of usage examples.

I tried to understand and proposed the following examples: this option can be used for Wingate server to service several public ips. For example: 1) if we have web servers inside our LAN, but they are registered on DNS server with particular public ips and Wingate is the one who actualy receives requests to that registered ips and then makes port forwarding (or mapped link?) to them. 2) For dynamic NAT (many public ips to many local PCs).
Are these the case?
And how this option is connected to mapped links (if it is)?


That was introduced to support DMZ, or connection to upstream devices that you can't configure the route table on. You need to know a little about what ARP is and how it is used to understand this feature. What the feature does is cause WinGate to respond to ARP requests with its own ethernet address when it receives an ARP query looking for any IP address that matches the IPs you specify.

When a computer or router has a packet to deliver and the route table on that computer/router specifies that the destination address is local, it tries to establish the ethernet address of the destination by doing an ARP lookup. If this succeeds, it sends the packet to the ethernet address it resolved by this method. This is how routing works, and accessing machines on local subnets (also how you find the ethernet address of your router). So the ARP responder allows you to override this so that the client computer will send the packet to WinGate's ethernet address, then WinGate can forward it to wherever required.

Alen wrote:13. Is it safe to preserve network interfaces Auto usage detection? Particularly in case of 2 interfaces: LAN with private ip and WAN with public ip? And in case of 3 interfaces: LAN with private ip, DMZ with private ip and WAN with public ip?
Does Wingate detect interface usage each time the server is started\restarted if we use autodetection? What if we set usage manually?
Did you have cases when because of glithes program errors users got wrongly detected interfaces usage (after regular server restart, for example)?
Obviously in case of wrong interface usage auto detection, we could get external interface binded to the services, which is extremely dangerous. So isn’t it better to set interface usage manually (but keep using autobinding with the binding policy “Any Internal Adapter”, which binds only Internal interfaces to services) once and sleep tight?


You will need to manually set usage for the DMZ adapter, since it has a public IP, WinGate will assume it is external. Otherwise if the adapter has a public IP it will be deemed external. Whether it's safe to always get WinGate to assume that may depend on other things. Is it possible for the external adapter to ever think it has a private IP? E.g. DHCP failure if it uses DHCP to get its IP , or something like that? If you're concerned, just set the usage manually.

Alen wrote:14. What will happen, if we choose to set interface usage manually and one day Wingate found a new interface (two cases: 1. the new interface is just an additional one; 2. it was installed instead of one of the existed: Internal or External)?! (In case the only criteria for Wingate is interface ip being public or private, let’s suppose all interfaces have public or all have private ips).


The adapters have a unique ID, so if you add a new adapter, WinGate will assume what usage it has based on its IP address. If you replace an adapter, that's the same thing, since it will have a different ID.

Alen wrote:15. How to setup binding policies if we have 3 interfaces (LAN, DMZ, WAN)?
In binding policy setup window screenshot I can see only “Any Internal Adapter”, “Any External Adapter” and “Any adapter” settings for “autobinding” (we also can make bindings manually by choosing particular adapters for each service, but I found this inconvinient, plus in opposite with the interface usage autodetection, allowing autobinding “Internal Adapters” only is more secure than mannual bindings). So how to setup (auto)binding policy when we also have DMZ interface?
Do we get a new choice “Any DMZ Adapter”? Or DMZ interface is included in “Any External Adapter” as according to Wingate DMZ is: “A secure external (sic!) network”.
The question is just about what to do if we want to bind not only LAN interface to a service, but also DMZ and not WAN, or bind DMZ interface only?
Honestly, I don’t see such necessity for now, but just want to be ready for it.


I'll need to think about that one. I don't think it will auto bind to that class of adapter, but since you must manually specify an adapter be a DMZ one (it will never be assumed), then you would simply manually add a binding rule for that adapter. I guess if you have lots of services bound it could be a pain. In general, the concept of DMZ was mainly intended not to go through the proxy, but just the packet driver. In this way it is deemed a secured (e.g. it's firewalled by WinGate) external network.

Alen wrote:16. Override Service port (option in Bindings tab of Wingate services)
As I understand this is for redefinition of service port. For example for local client applications to use port 8080 for http requests instead of standard port 80. So it will look like {LAN to Wingate http requests use port 8080} – {Wingate to Internet requests use port port 80}.
What is this giving to us?
If we speak about additional security, I can’t understand why and how we get it? I mean, if our proxy is servicing only requests from LAN, then Wingate will refuse requests received on WAN anyway, regardless of the correctness of service port. In case of WAN requests are allowed, the malefactor can easely define http proxy port with port scanner and make requests using the correct port. So where is advantages?
Or we are securing from local clients, who will not be able to connect to the Internet without knowing correct port?


Override service port is only in a binding rule definition, not bindings tab. This is where you want the binding rule to create a binding which listens on a port other than the default service port. E.g you may have some binding rules on a WWW proxy (default port 80) set to not override service port. These rules will bind on port 80. If you also want the service to be available on another port say 8080, you would need to add another binding rule and override the service port and set the overridden port to 8080.

Alen wrote:17. Use SYN Cookies (against Syn flood atacks) (option in Bindings tab of Wingate services)
It is written about potential incompatibilities. Can you please explain and give me some examples. I think the option is quite useful and want to understand could it make problems for me.


Actually I wasn't aware of any incompatibilites.

Alen wrote:18. Notify on access (option in Bindings tab of Wingate services)
As all proxy services have their own logs plus all current activities can be seen on Activity tab screen, there is no need to activate this option and overload Firewall tab screen. Am I right? And when this option can be really needful?


You can turn off logging in the proxy. So this would allow you to see when a connection was made to this service when looking in the firewall tab.

Alen wrote:19. Citate: “The WGIC hooks into the OS of the client PC and redirects all Network traffic to the WinGate server”. All network traffic? Even LAN, including domain specific? Or this sentence (from WinGateInstall.chm) is incorrect and WGIC analyses traffic and sends to Wingate only Internet requests? (And how it knows they are Internet requests?)


The help file is incorrect. The WGIC is a Winsock 2 layered service provider (LSP). This is loaded by windows sockets only, when an application that uses sockets loads. So any application/networking that doesn't go through windows sockets (e.g. SMB / windows networking traffic file sharing and printing etc) will not go through the LSP.

We check the destination address against the route table at the server to determine if the traffic is local or remote.

Alen wrote:Comments:
1. In many places of the help I see this:
"Since the introduction of using NAT and Transparent redirection abilities in WinGate, there are now very few occasions where you should need to use a proxy directly".
- I disagree. Using NAT allows any application to connect to the Internet using any desired port (if it was not specially disabled by firewall), but proxy method – only particular application which uses particular protocols (= ports)! And thus Proxy (in this context) is more secure.


I agree with you. We don't recommend people use NAT instead of proxies. Especially for HTTP, things work better if the client is explicitly configured to use a proxy. Things like caching and authentication have trouble when intercepted.


Alen wrote:2. You should add some setup details in the appropriate sections of help for the people who are going to use third: DMZ interface. And the same should be done for the users who have and want to use two Internet connections simultaneously, but with different metrics (desirably this has to be response latencies) for the two interfaces.


Fair comment. Hope my answers are of some help.

Regards

Adrien
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby genie » Nov 13 09 5:30 pm

I would like to post my 2c on SYN cookies - since we effectively send our own version of SYN packet, we omit or re-set options, transmitted in the original SYN packet, such as timestamps and such. That might lead to the certain differences mainly in the performance characteristics of the TCP session.
genie
Qbik Staff
 
Posts: 1788
Joined: Sep 30 03 10:29 am

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 13 09 9:26 pm

adrien
Thank you very much for spending so much time.
I am reading now your answers, some are absolutely clear, some give birth to new questions. Here are some of them:

1.
As the user rights questions are critical for me and I have much to say after further reading I decided to create a separate theme.


3.
3.2 I understand this, I am familiar with AD requirements for DNS service and I read carefully appropriate section in Wingate help (about setting forwarder + loop prevention measures). It is described quite clear.
But let’s clarify with this part: “WinGate's DNS resolver on the other hand is used by WinGate to resolve DNS, and actually can't be turned off anyway. It doesn't depend on the WinGate DNS server though”.
Two questions:
- Is Wingate DNS Resolver enough for NAT connection method to work?
- As I can understand, DNS Resolver just forwards requests to providers DNS server!? So it depends on providers DNS server ip address to be set on WAN interface of Wingate server (sic!) plus be functional. Is this correct? If not how Resolver resolves requests?


4.
You don't necessarily need to waste a public IP address on the DMZ adapter itself, since you can use ARP spoofing to get that adapter to respond to ARP requests for the other external WinGate interface, then set the default gateway for your DMZ computers to the IP address of the external WinGate adapter.

4.2 Very interesting and new for me. Please give more details. We set on DMZ PCs (e.g. web server with public ip) as default gateway ip address of Wingates WAN interface, not DMZ. And using ARP spoofing make DMZ interface to service requests from DMZ Pcs (which obviously means to forward the requests to WAN interface. This is similar to bridge, but it is working on network layer!?)
How to organize this “ARP spoofing”? Is it done from inside Wingate?

4.3 I think using DMZ is the best variant for us (because I will not have to allow ouside requests to come into my LAN), but I wonder, can’t I place my web server with private ip inside my LAN and make it work by NAT + port forwarding or mapped link as another solution?
In this case we don’t need DMZ interface and additional public ips. I will also appreciate if you mention negatives of this variant.

P.S. After reading your answer about port redirect vs mapped link I have more specific question: which one to use if we want to place our web server inside LAN, behind NAT, and service requests like http, https and may be some other, received on predefined ports?


5.
What to do if we want to use NAT + Transparent proxy, but know that some of our apps have problems when working via pure Proxy.
(rephrased)

5.2 Your answer is clear, but I still do not see solution for my problem. I know, that some of our apllications, which are using Web browser and SSL do not work, when we set them to work via provider’s proxy. For now they are working via pure NAT (Wingate is not installed yet, I am using ICS+ICF).
As I am going to activate Transparent Proxy for all user services I am going to use (they are: web, ftp, pop) I am worried the applications won’t work. So the best decision could be just exclude appropriate sites from sites serviced via proxy, like it is done locally in web browser. Now I see, this is not possible with Transparent Proxy.
But what to do? (I did not go deep into the problem, may be the problem was incorrect proxy settings, for example my admins could just set port 80 for HTTPS traffic which could be incorrect in case of provider’s proxy settings. I’ll check it soon, but anyway the problem could be actual for many people).


7.
As I understand it is possible to use “pure” proxy connection method with Wingate. The same time there is no requirements for clients’ ips to be public ips. Does this mean that even when only web proxy is being used, Internet traffic is NATed anyway (but just for HTTP traffic in this case)? I am asking because AFAIK pure web proxy has to make changes only at 7-th, Application, layer, but here we have also source ip change, which is NAT function (and is made on 3-rd and 4-th layers).

Your answer was a little different with my question. But I see now my mistake. There is just no need to make NAT, because clients are not trying to connect to web servers by themselves, instead they purposely ask proxy server with special “proxy request” to provide necessary data. And the proxy make request from his ip address (some times preserving some data from higher levels – that’s why on some sites which detect your ip, you can see your private ip address, while being connected via proxy).

To be continued.
Last edited by Alen on Nov 15 09 4:28 am, edited 2 times in total.
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 13 09 9:27 pm

genie wrote:I would like to post my 2c on SYN cookies - since we effectively send our own version of SYN packet, we omit or re-set options, transmitted in the original SYN packet, such as timestamps and such. That might lead to the certain differences mainly in the performance characteristics of the TCP session.

Thank you (I did'nt fully understand what you say ;-), but thanks for the info.)
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 14 09 12:53 am

Let's continue with "questions on answers":

10.
Firewall hits are base64 coded packet data.

10.2 Sorry, but how should we open firewall log (the base64 coded data file)? And where can we find it?

P.S. Don’t you think firewall log place and usage is critically important for this type of programs and it should be clearly documented in manual?!


12. What is the option “Enable ARP responder” for?
12.2 Dear Adrien, I know network basics and I know what ARP is and how it works. I just can’t see how it is used in this option. I mean, I understand in fact Wingate “intercepts” ip traffic, not destined to it. But destined to whom, for what we catch it and what’s next?
Can you explain it on an example and in details please?


14.
The adapters have a unique ID, so if you add a new adapter, WinGate will assume what usage it has based on its IP address. If you replace an adapter, that's the same thing, since it will have a different ID.

14.2 So, can I count that if I assign interface usage manually, then even if Wingate redetect interfaces and their usage each time after restart, Wingate will found that adapters' IDs do not change and leave usage setting as they were?
What if adapters usage were set manually, but after restart Wingate found that the appropriate adapter ip was changed? Or Wingate does not make any interface usage checks\autodetection if it was set manually?


15.
15.2 So, DMZ interface will never be autobinded to any service together with WAN, when “Any external adapter” binding policy is used!? And for DMZ interface to be ever binded to any service it should be done by manually binding the adapter to the required service. Is this correct?

16. Override Service port
What is this giving to us?
Override service port is only in a binding rule definition, not bindings tab. This is where you want the binding rule to create a binding which listens on a port other than the default service port. E.g you may have some binding rules on a WWW proxy (default port 80) set to not override service port. These rules will bind on port 80. If you also want the service to be available on another port say 8080, you would need to add another binding rule and override the service port and set the overridden port to 8080.

Still did not get it.
Do you mean we can have one web proxy wich will service the default 80-th port, plus we can add an additional binding of port 8080 and thus the same proxy will service requests received on both 80-th and 8080-th ports?
Why should we need it? Can you provide me with some examples of real scenarios?
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 15 09 6:52 am

Alen wrote:- Is Wingate DNS Resolver enough for NAT connection method to work?


NAT works by re-writing IP addresses in IP packets that are forwarded at the packet layer by our NDIS driver. Outbound packets have their source IP rewritten. So there is no DNS lookup to do, and therefore NAT doesn't require the WinGate DNS resolver. The DNS resolver in WinGate is only usable by the engine (WinGate.exe), and is used whenever there is a DNS lookup that WinGate needs to perform (e.g. for a proxy connection).

Alen wrote:- As I can understand, DNS Resolver just forwards requests to providers DNS server!? So it depends on providers DNS server ip address to be set on WAN interface of Wingate server (sic!) plus be functional. Is this correct? If not how Resolver resolves requests?


WinGate enumerates DNS servers known to the host OS. These can come from (usually) adapter settings (whether assigned manually or by DHCP), or also from dialup PPP connections where a DNS server is negotiated, or entered manually into the DNS resolver settings in GateKeeper. WinGate then uses these DNS servers (those that have not been excluded with WinGate Advanced Options) to make requests.

So any DNS server you enter into a network adapter properties can be used by WinGate.

Alen wrote:4.2 Very interesting and new for me. Please give more details. We set on DMZ PCs (e.g. web server with public ip) as default gateway ip address of Wingates WAN interface, not DMZ. And using ARP spoofing make DMZ interface to service requests from DMZ Pcs (which obviously means to forward the requests to WAN interface. This is similar to bridge, but it is working on network layer!?)
How to organize this “ARP spoofing”? Is it done from inside Wingate?


The task of responding to the ARP requests is performed in WinGate's driver, you set it up in GateKeeper in the advanced tab of an adapter properties dialog (you need an enterprise or trial license). This allows client machines attached to that network interface to issue ARP requests and get a response from WinGate for the IP ranges you specify. Those clients then forward the packets to the ethernet address of that adapter, which means that WinGate can forward the packets.


Alen wrote:4.3 I think using DMZ is the best variant for us (because I will not have to allow ouside requests to come into my LAN), but I wonder, can’t I place my web server with private ip inside my LAN and make it work by NAT + port forwarding or mapped link as another solution?
In this case we don’t need DMZ interface and additional public ips. I will also appreciate if you mention negatives of this variant.

P.S. After reading your answer about port redirect vs mapped link I have more specific question: which one to use if we want to place our web server inside LAN, behind NAT, and service requests like http, https and may be some other, received on predefined ports?


Yes, you can just map a port and have a webserver on your internal network. For something like a web server, this works well, and avoids the issue of setting up a DMZ. The main thing a DMZ gives you, is (since the connections don't use address translation) support for protocols that don't perform well through NAT. In general if you want the server to be able to learn the IP of the connected client, use a port mapping rather than a TCP mapping proxy. If you want more advanced policy (such as time of day, or source IP based rules) use a TCP mapping proxy.

Alen wrote:As I am going to activate Transparent Proxy for all user services I am going to use (they are: web, ftp, pop) I am worried the applications won’t work. So the best decision could be just exclude appropriate sites from sites serviced via proxy, like it is done locally in web browser. Now I see, this is not possible with Transparent Proxy.
But what to do? (I did not go deep into the problem, may be the problem was incorrect proxy settings, for example my admins could just set port 80 for HTTPS traffic which could be incorrect in case of provider’s proxy settings. I’ll check it soon, but anyway the problem could be actual for many people).


WinGate will only intercept connections on the ports specified. So if these other apps are performing say non-HTTP protocols over port 80, there will be a problem. I have serious doubts any software author would do that though, since interception of connections is commonplace.

HTTPS support through an HTTP proxy does in fact use a method in HTTP called CONNECT. What this means is that for HTTPS support through WinGate, the proxy settings for the client should be the same as for HTTP. E.g. same port number.

These applications that don't work, are they external apps, or websites / java applets? Connections made by java applets use the connectivity provided by the browser, which then in turn uses a proxy if the browser is configured to use one.

Alen wrote:There is just no need to make NAT, because clients are not trying to connect to web servers by themselves, instead they purposely ask proxy server with special “proxy request” to provide necessary data. And the proxy make request from his ip address (some times preserving some data from higher levels – that’s why on some sites which detect your ip, you can see your private ip address, while being connected via proxy).


Correct.

Alen wrote:10.2 Sorry, but how should we open firewall log (the base64 coded data file)? And where can we find it?

P.S. Don’t you think firewall log place and usage is critically important for this type of programs and it should be clearly documented in manual?!


WinGate\Logs\System\System.log

The entries are like
Code: Select all
11/15/09 00:00:23 fe314dI31iMAiQQ1AQAAABEADEHxnhkAES9DpNoAAEUAAMuzwgAAdxFzNX3t9eHSN9YjAAAAAAAAAAAAAAAAAAAAAAAAAAAAiQQ1ALd27EjRhAAAAAABAAAAACBDS0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUEA


These aren't designed to be read unfortunately. however if you base64 decode them, they are the start of the actual packet, plus some extra data at the start with information about whether the packet was a block or allow etc.

Alen wrote:12.2 Dear Adrien, I know network basics and I know what ARP is and how it works. I just can’t see how it is used in this option. I mean, I understand in fact Wingate “intercepts” ip traffic, not destined to it. But destined to whom, for what we catch it and what’s next?
Can you explain it on an example and in details please?


ethernet devices have a filter on them, and unless they are put into promiscuous mode, will only indicate packets received it the destination ethernet address of the packet matches the device. WinGate does not put any ethernet adapters into promiscuous mode. So, the only way WinGate will receive a packet is if that packet has a destination ethernet address of an adapter on the WinGate machine.

So, the scenario is that you want WinGate to forward packets. WinGate uses ARP spoofing to convince the client machine to set the destination ethernet address to WinGate's one, so that WinGate will get the packet and can forward it. There's quite a lot written about ARP spoofing which could help here.

Alen wrote:14.2 So, can I count that if I assign interface usage manually, then even if Wingate redetect interfaces and their usage each time after restart, Wingate will found that adapters' IDs do not change and leave usage setting as they were?
What if adapters usage were set manually, but after restart Wingate found that the appropriate adapter ip was changed? Or Wingate does not make any interface usage checks\autodetection if it was set manually?


WinGate only makes an assumption if it is set to automatic. Once you manually specify a usage, WinGate won't change it. It's remembered in the registry associated with the unique ID of the adapter, which doesn't change.

Alen wrote:15.2 So, DMZ interface will never be autobinded to any service together with WAN, when “Any external adapter” binding policy is used!? And for DMZ interface to be ever binded to any service it should be done by manually binding the adapter to the required service. Is this correct?


I think so - I'd need to check... or if you have an adapter set up like that, you should be able to see as well.

Alen wrote:Do you mean we can have one web proxy wich will service the default 80-th port, plus we can add an additional binding of port 8080 and thus the same proxy will service requests received on both 80-th and 8080-th ports?


correct. So all the other settings are shared (e.g policy, logging etc). Compare this with creating another WWW proxy on the different port, which would give you the ability to have separate policy.

Alen wrote:Why should we need it? Can you provide me with some examples of real scenarios?


You can set up the SMTP server to listen on port 25 (with TLS), and also on port 465 with SSL. Not so useful with the WWW proxy.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 17 09 1:08 am

3.
3.2
Alen wrote:
- Is Wingate DNS Resolver enough for NAT connection method to work?

adrien wrote:
NAT works by re-writing IP addresses in IP packets that are forwarded at the packet layer by our NDIS driver. Outbound packets have their source IP rewritten. So there is no DNS lookup to do, and therefore NAT doesn't require the WinGate DNS resolver. The DNS resolver in WinGate is only usable by the engine (WinGate.exe), and is used whenever there is a DNS lookup that WinGate needs to perform (e.g. for a proxy connection).

Sorry, wrong question (of course I know how NAT works).
I should ask you: Is Wingate DNS Resolver enough for Internet connections to work?
And the answer is: "Yes".

Concerning the second part, as I understand (just your answer, but refrased):
For DNS Resolver (no Wingate DNS service) to work WinGate need working external DNS servers addresses and it can use the following DNS servers (except excluded with WinGate Advanced Options, used to prevent DNS lookup loops in AD environment):
- found on Wingate server external interfaces TCP/IP settings (including assigned by DHCP)
- from dialup PPP connections (where a DNS server is negotiated after connection is made)
- manually entered into the DNS resolver settings in GateKeeper.

Not sure, but it seems to me, the last variant is the most secure (as Wingate server itself will not be able to resolve external names, only Wingate application).

BTW, one more question: if we deploy Wingate in AD environment and set Wingate address in DNS Forwarders of AD DNS server, is it required for Wingate DNS service to work? Or it's enough to have DNS Resolver (looking at outside DNS)?


4. DMZ, port forwarding and mapped links questions (together with using ARP spoofing) are still unclear for me. Later I'll try to reread and understand your answers. If not I'll try to ask you more questions.


5.
5.2
Alen wrote:
As I am going to activate Transparent Proxy for all user services I am going to use (they are: web, ftp, pop) I am worried the applications won’t work. So the best decision could be just exclude appropriate sites from sites serviced via proxy, like it is done locally in web browser. Now I see, this is not possible with Transparent Proxy.
But what to do? (I did not go deep into the problem, may be the problem was incorrect proxy settings, for example my admins could just set port 80 for HTTPS traffic which could be incorrect in case of provider’s proxy settings. I’ll check it soon, but anyway the problem could be actual for many people).

adrien wrote:
WinGate will only intercept connections on the ports specified. So if these other apps are performing say non-HTTP protocols over port 80, there will be a problem. I have serious doubts any software author would do that though, since interception of connections is commonplace.

HTTPS support through an HTTP proxy does in fact use a method in HTTP called CONNECT. What this means is that for HTTPS support through WinGate, the proxy settings for the client should be the same as for HTTP. E.g. same port number.

These applications that don't work, are they external apps, or websites / java applets? Connections made by java applets use the connectivity provided by the browser, which then in turn uses a proxy if the browser is configured to use one.

I have 3 issues:
- working with sites using specially granted to us certificates (SSL)
- working with special applications - black box for us (I am not sure they work via HTTP)
- Skype.
The second and third issues are clear, the only way is using NAT (or port forwarding, which is less convenient and can be used only for single user. May be mapped links could also be used?).
The first issue is very strange, AFAIK it should work via proxy, but in fact it is not (we tried it via our provider's proxy).

Anyway, after long thinking, I have new thoughts about solution for users who has problems with some sites or applications, which do not work via Proxy. I can go this way:
- allow them to use web proxy service like all others, but add in their browsers exclusions for the sites, which do not work via proxy (this will allow not only better control, but also for KAV and PureSight to check their traffic)
- allow them to use NAT “service” but use white list rule: to allow only them to access only “problematic” sites and addresses via NAT.

But I have 2 new problems:
1) I should not activate Tranparent proxy. - This is not a serious problem since I allow only a few trusted addresses to be accessed via NAT.
2) As NAT is just a part of ENS service, which also contain Bandwidth control subsystem, which I must use, I don't know what to do!? I mean to apply BC restrictions on all users I have to allow all of them to access ENS service, haven't I?
If yes, then what to do? Grant to rest of my users the right "Can access this service" with an empty white list (or banned *.*.*.* address)?
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 17 09 3:52 am

Multiple rereading partially helped, I think (DMZ issue):

adrien wrote:
You don't necessarily need to waste a public IP address on the DMZ adapter itself, since you can use ARP spoofing to get that adapter to respond to ARP requests for the other external WinGate interface, then set the default gateway for your DMZ computers to the IP address of the external WinGate adapter.

Well, as I understand, on DMZ interface I set any (private or illegal public?) ip, anything.
Then in Wingate advanced network properties for DMZ interface I activate "Enable ARP Responder" option and write there Wingate WAN ip.
On the other hand, on DMZ PCs I set Wingate WAN ip as default gateway.

Is this correct?
And what ip should I use on DMZ interface (I dont leave it on autoobtain, never know what will be tomorrow)?

Now I have one real example of "Enable ARP Responder", finally. Can you provide me with others?
I could not understand and imagine an examples of the option usage, because I was thinking about ARP spoofing by WAN interface of Wingate of other PCs ips...
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 17 09 8:02 am

Alen wrote:I should ask you: Is Wingate DNS Resolver enough for Internet connections to work?
And the answer is: "Yes".


I think I misunderstood you before. So hopefully the following information will help.

For a client on the LAN to use NAT, they must have access to DNS resolution, since they try to connect directly to the end servers and therefore must be able to resolve the IPs. If they are on an AD, they normally will use the AD DNS server (required for the domain to work). The AD DNS server then will normally forward to some other DNS server that can resolve internet names. Often this server is WinGate. If it is WinGate, then WinGate needs to be running the WinGate DNS server, it's not enough just to have the DNS resolver. The DNS resolver is used by the DNS server in WinGate to obtain the answers to the queries received by the DNS server. The DNS resolver is also used by WinGate internal services when resolution is required.

An alternative to forwarding to WinGate's DNS server is

a) you can forward to an internet-based DNS server (e.g. your ISP) via NAT through WinGate
b) you can use a UDP mapping proxy to forward requests to a specific DNS server. You'd only do this if for some reason you didn't want to use the WinGate DNS server or resolver (e.g. you only wanted NAT).

Alen wrote:I have 3 issues:
- working with sites using specially granted to us certificates (SSL)
- working with special applications - black box for us (I am not sure they work via HTTP)
- Skype.
The second and third issues are clear, the only way is using NAT (or port forwarding, which is less convenient and can be used only for single user. May be mapped links could also be used?).
The first issue is very strange, AFAIK it should work via proxy, but in fact it is not (we tried it via our provider's proxy).


I've not had trouble using client certificates through WinGate as a HTTP proxy before. the browser should just use the CONNECT method to establish a TCP tunnel to the end server, then the SSL negotiation takes place over that connection as if the client were directly connected to the server.

As for black box apps, you can always use wireshark or Commview or similar to verify what protocol they are using (or that it's not HTTP) and what ports they use. That might help figure out what is going on. We use skype here via WinGate as well, and I'm not aware of any problems with it.

Alen wrote:Anyway, after long thinking, I have new thoughts about solution for users who has problems with some sites or applications, which do not work via Proxy. I can go this way:
- allow them to use web proxy service like all others, but add in their browsers exclusions for the sites, which do not work via proxy (this will allow not only better control, but also for KAV and PureSight to check their traffic)
- allow them to use NAT “service” but use white list rule: to allow only them to access only “problematic” sites and addresses via NAT.

But I have 2 new problems:
1) I should not activate Tranparent proxy. - This is not a serious problem since I allow only a few trusted addresses to be accessed via NAT.
2) As NAT is just a part of ENS service, which also contain Bandwidth control subsystem, which I must use, I don't know what to do!? I mean to apply BC restrictions on all users I have to allow all of them to access ENS service, haven't I?
If yes, then what to do? Grant to rest of my users the right "Can access this service" with an empty white list (or banned *.*.*.* address)?


Bandwidth control is independent of access control in terms of ENS policy. Bandwidth rules are used to select which connections will be governed by which bandwidth restrictions. So it should be possible to set bandwidth rules as if there were no ENS rules and vice versa. The ENS policy applies only for NAT traffic, which we define as being traffic through WinGate that has its address translated. The bandwidth control however can control other sorts of traffic, such as

* traffic directly to / from the WinGate server
* traffic routed between local subnets

So for instance it's common to apply bandwidth control to the traffic sent by WinGate to the client computers (since it is easier to control sending than receiving).
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 17 09 8:08 am

Alen wrote:Multiple rereading partially helped, I think (DMZ issue):

adrien wrote:
You don't necessarily need to waste a public IP address on the DMZ adapter itself, since you can use ARP spoofing to get that adapter to respond to ARP requests for the other external WinGate interface, then set the default gateway for your DMZ computers to the IP address of the external WinGate adapter.

Well, as I understand, on DMZ interface I set any (private or illegal public?) ip, anything.
Then in Wingate advanced network properties for DMZ interface I activate "Enable ARP Responder" option and write there Wingate WAN ip.
On the other hand, on DMZ PCs I set Wingate WAN ip as default gateway.

Is this correct?
And what ip should I use on DMZ interface (I dont leave it on autoobtain, never know what will be tomorrow)?


In the past I've used bogus addresses like 1.2.3.4 on the DMZ interface.

Yes, you're correct, then you set the ARP responder for the DMZ interface to respond to the WAN IP (with mask 255.255.255.255).

You will also need to manually add a route to the route table on the WinGate machine so that it knows that your private subnet is out the DMZ adapter. This will probably mean setting the subnet mask on your WAN adapter to 255.255.255.255 (or depends how many of your public IPs you want outside the DMZ).

Alen wrote:Now I have one real example of "Enable ARP Responder", finally. Can you provide me with others?
I could not understand and imagine an examples of the option usage, because I was thinking about ARP spoofing by WAN interface of Wingate of other PCs ips...


We used to have a radio link, and the device was closed to us (we could not edit its configuration). It presumed all our IPs were local to its adapter, so it would do an ARP lookup for all our local IPs. We wanted to put a firewall in between the link and our external subnet, so we used ARP spoofing to reply to the radio equipment for all our public IPs (since we could not set a route for our subnet on the device itself). That way all our public IP addresses resolved to the same ethernet address (of our WinGate), which then got the packets and could route them to our DMZ.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 17 09 7:54 pm

The AD DNS server then will normally forward to some other DNS server that can resolve internet names. Often this server is WinGate. If it is WinGate, then WinGate needs to be running the WinGate DNS server, it's not enough just to have the DNS resolver.

This is what I was interested in.

Now the same question for non AD environment, let's count we have a workgroup (or NT4 based domain, where DNS is not necessary) and want to use Proxy, WGIC and NAT connection methods of Wingate (Note: the reason you could not clearly understand my questions is everytime I was supposing we want to use Wingate as Internet DNS requests resolver for clients. I know this is not mandatory, but I was constantly meaning that Wingate has to be used for DNS requests resolution).
Do we need Wingate DNS service to be enabled or it's enough to have properly registered ip of any working Internet DNS server (e.g. provider's one) in this case (of non AD environment)?
As I understand from your previous answers, the answer here is: "DNS Resolver is enough in that case".

You also did not answer on my comment about setting DNS ip directly in DNS Resolver settings, not in Wingate WAN interface TCP/IP settings.


I've not had trouble using client certificates through WinGate as a HTTP proxy before. the browser should just use the CONNECT method to establish a TCP tunnel to the end server, then the SSL negotiation takes place over that connection as if the client were directly connected to the server.

As for black box apps, you can always use wireshark or Commview or similar to verify what protocol they are using (or that it's not HTTP) and what ports they use. That might help figure out what is going on. We use skype here via WinGate as well, and I'm not aware of any problems with it.

Ok, it's clear.
Let's suppose I find out outgoing port(s) used by the black box app, plus this is what I found about Skype:
The Minimum requirement is that Skype needs unrestricted outgoing TCP access to all destination ports above 1024 or to port 80 (the former is better, however). If you don't allow either of those, Skype will not work reliably at all. Voice quality and some other aspects of Skype functionality will be greatly improved if you also open up outgoing UDP traffic to all ports above 1024, and allow UDP replies to come back in.
Very restrictive corporate firewalls: Skype currently works with most standard firewalls and gateway configurations. However, some very strict corporate firewalls which only allow TCP connections on a restricted number of ports may not allow Skype to connect at the moment. We are working on resolving this issue and hope that Skype will be able to function on the majority of firewalls with no configuration required. If your firewall does not allow you to use Skype, please inform your system administrator so that they can allow the appropriate access necessary for Skype to run.

The problem is that other Skype users out there are listening on random ports. Therefore in order to connect to them, you need all outgoing TCP ports open. Actually, you do not need to communicate with *all* of them, because Skype automatically routes calls and other communications through intermediate Skype nodes if direct communication fails. However, you at least need to be able to connect to a significant percentage of those intermediate nodes; therefore you need to open up at least a large chunk of outgoing TCP destination ports; a range of 30 000 to 40 000 might work well enough. Port 33033 should be in the range you open, since this is needed for communication with Skype login server.

It is also important to understand that this concerns to *outgoing* TCP. For incoming connections, there is no requirements on Skype side -- even if all incoming TCP connections are blocked, Skype will still work, albeit the voice quality you get may not be the best possible.

If port 80 is opened and Skype still not working, then may be port 80 goes through transparent HTTP proxy in your firewall. I.e. only HTTP traffic is allowed on port 80. Some firewalls impose such restrictions, and then Skype does not work because Skype is not HTTP. If outgoing port 80 is completely open, then Skype should work without any configuration.

Now, what should I do to make them work properly?
Just open the required ports in firewall? But this can be useful only if NAT connection method is used. Plus I was going to use white list for pure NAT traffic, not sure this is real with Skyp usage...

Again, after thinking some time and taking into account the fact KAV and PureSight work only at the proxy level, it seems to me the best solution for the issue would be:
- to set all users to use web (and other required) proxy service, but add where needed in their browsers exclusions for the sites, which do not work via proxy,
- allow users who need to work with the problematic sites or proprietary apps to use NAT “service”, but with white list rule: to allow to access only “problematic” sites and addresses via NAT,
- do not activate transparent proxy for any service, as only a few sites and addresses will be accessible via NAT.

These schema will work only in case Skype really can and will work via Wingate HTTP Proxy.
Please give me some comments and advices. May be a better solution exists.



Bandwidth control is independent of access control in terms of ENS policy. ... So it should be possible to set bandwidth rules as if there were no ENS rules and vice versa. The ENS policy applies only for NAT traffic, which we define as being traffic through WinGate that has its address translated.

O-h, good, I was worrying my mission becomes impossible (with Wingate).
Well then, BC is not connected to ENS (NAT) service policy. Very well if so. But you mention another awful thing:...
Strange I cann't find it. Just reassure me BC can regulate all traffic, regardless of the connection method used (NAT, WGIC or Proxy)!?


The bandwidth control however can control other sorts of traffic, such as
* traffic directly to / from the WinGate server
* traffic routed between local subnets

So for instance it's common to apply bandwidth control to the traffic sent by WinGate to the client computers (since it is easier to control sending than receiving).

Logan helped me with my needs connected with BC. I'll resume everything concerning it and post here for final verdict later.
Last edited by Alen on Nov 18 09 4:23 am, edited 1 time in total.
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 17 09 8:04 pm

Alen wrote:
Well, as I understand, on DMZ interface I set any (private or illegal public?) ip, anything.
Then in Wingate advanced network properties for DMZ interface I activate "Enable ARP Responder" option and write there Wingate WAN ip.
On the other hand, on DMZ PCs I set Wingate WAN ip as default gateway.

Is this correct?
And what ip should I use on DMZ interface (I dont leave it on autoobtain, never know what will be tomorrow)?

adrien wrote:
In the past I've used bogus addresses like 1.2.3.4 on the DMZ interface.

Yes, you're correct, then you set the ARP responder for the DMZ interface to respond to the WAN IP (with mask 255.255.255.255).

You will also need to manually add a route to the route table on the WinGate machine so that it knows that your private subnet is out the DMZ adapter. This will probably mean setting the subnet mask on your WAN adapter to 255.255.255.255 (or depends how many of your public IPs you want outside the DMZ).

Still not totally clear, sorry. I don't understand the underlined part. What route should I add to route table to provide Wingate "knows that your private subnet is out the DMZ adapter"?
And how and why is this connected to the subnet mask of Wingate WAN interface and thus how many of my public IPs I want outside the DMZ?

What I understand:
1) I have my LAN interface with 192.168.20.10 /24, WAN interface with (say) 100.101.102.103 /29 and DMZ interface with 1.2.3.4 /32 (?) addresses.
2) In Wingate advanced network properties for DMZ interface I activate "Enable ARP Responder" option and write there Wingate WAN ip with 255.255.255.255 mask, i.e 100.101.102.103 /32.
3) On Wingate machine I register static route using route add? (from where to where and via which gateway?)
4) On DMZ PCs I set Wingate WAN ip as default gateway.
end


Additional question:
1. should we set Wingate WAN ip as gateway on DMZ interface anyway (regardless of ARP spoofing usage)?
2. doesn't this make problems (because as known Windows itself often becomes crazy when more than one default gateway is set, especially after some of them becoming unreachable and coming back)?
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 18 09 11:38 am

Alen wrote:
The AD DNS server then will normally forward to some other DNS server that can resolve internet names. Often this server is WinGate. If it is WinGate, then WinGate needs to be running the WinGate DNS server, it's not enough just to have the DNS resolver.

This is what I was interested in.

Now the same question for non AD environment, let's count we have a workgroup (or NT4 based domain, where DNS is not necessary) and want to use Proxy, WGIC and NAT connection methods of Wingate (Note: the reason you could not clearly understand my questions is everytime I was supposing we want to use Wingate as Internet DNS requests resolver for clients. I know this is not mandatory, but I was constantly meaning that Wingate has to be used for DNS requests resolution).
Do we need Wingate DNS service to be enabled or it's enough to have properly registered ip of any working Internet DNS server (e.g. provider's one) in this case (of non AD environment)?
As I understand from your previous answers, the answer here is: "DNS Resolver is enough in that case".


For NAT and also for WGIC, the client needs to be able to resolve IPs. They can do this any way they like, they don't need to use WinGate as a DNS server if you have another DNS server that can resolve internet names.

Alen wrote:You also did not answer on my comment about setting DNS ip directly in DNS Resolver settings, not in Wingate WAN interface TCP/IP settings.


Sure, you can prevent other services / programs on that computer from accessing DNS if you do that, and WinGate will happily use the settings you specify in the DNS resolver settings in WinGate. You might find all sorts of system services really want DNS though, and will complain or cause problems if they don't have it. I haven't tried it so I can't say for sure.

Alen wrote:
I've not had trouble using client certificates through WinGate as a HTTP proxy before. the browser should just use the CONNECT method to establish a TCP tunnel to the end server, then the SSL negotiation takes place over that connection as if the client were directly connected to the server.

As for black box apps, you can always use wireshark or Commview or similar to verify what protocol they are using (or that it's not HTTP) and what ports they use. That might help figure out what is going on. We use skype here via WinGate as well, and I'm not aware of any problems with it.

Ok, it's clear.
Let's suppose I find out outgoing port(s) used by the black box app, plus this is what I found about Skype:
The Minimum requirement is that Skype needs unrestricted outgoing TCP access to all destination ports above 1024 or to port 80 (the former is better, however). If you don't allow either of those, Skype will not work reliably at all. Voice quality and some other aspects of Skype functionality will be greatly improved if you also open up outgoing UDP traffic to all ports above 1024, and allow UDP replies to come back in.
Very restrictive corporate firewalls: Skype currently works with most standard firewalls and gateway configurations. However, some very strict corporate firewalls which only allow TCP connections on a restricted number of ports may not allow Skype to connect at the moment. We are working on resolving this issue and hope that Skype will be able to function on the majority of firewalls with no configuration required. If your firewall does not allow you to use Skype, please inform your system administrator so that they can allow the appropriate access necessary for Skype to run.

The problem is that other Skype users out there are listening on random ports. Therefore in order to connect to them, you need all outgoing TCP ports open. Actually, you do not need to communicate with *all* of them, because Skype automatically routes calls and other communications through intermediate Skype nodes if direct communication fails. However, you at least need to be able to connect to a significant percentage of those intermediate nodes; therefore you need to open up at least a large chunk of outgoing TCP destination ports; a range of 30 000 to 40 000 might work well enough. Port 33033 should be in the range you open, since this is needed for communication with Skype login server.

It is also important to understand that this concerns to *outgoing* TCP. For incoming connections, there is no requirements on Skype side -- even if all incoming TCP connections are blocked, Skype will still work, albeit the voice quality you get may not be the best possible.

If port 80 is opened and Skype still not working, then may be port 80 goes through transparent HTTP proxy in your firewall. I.e. only HTTP traffic is allowed on port 80. Some firewalls impose such restrictions, and then Skype does not work because Skype is not HTTP. If outgoing port 80 is completely open, then Skype should work without any configuration.

Now, what should I do to make them work properly?
Just open the required ports in firewall? But this can be useful only if NAT connection method is used. Plus I was going to use white list for pure NAT traffic, not sure this is real with Skyp usage...


According to http://skypetips.internetvisitation.org/web_pages/faq.html, Skype uses the proxy settings set for your browser. I presume this means it uses the HTTP proxy to connect out using the CONNECT method, or it uses SOCKS.

Have you tested this?

Alen wrote:Again, after thinking some time and taking into account the fact KAV and PureSight work only at the proxy level, it seems to me the best solution for the issue would be:
- to set all users to use web (and other required) proxy service, but add where needed in their browsers exclusions for the sites, which do not work via proxy,
- allow users who need to work with the problematic sites or proprietary apps to use NAT “service”, but with white list rule: to allow to access only “problematic” sites and addresses via NAT,
- do not activate transparent proxy for any service, as only a few sites and addresses will be accessible via NAT.

These schema will work only in case Skype really can and will work via Wingate HTTP Proxy.
Please give me some comments and advices. May be a better solution exists.



If you use a proxy auto-detect script I think you can specify on a site-by-site / protocol basis whether

a) to use a proxy or not
b) what sort of proxy (e.g HTTP proxy, or SOCKS).

You might find the SOCKS server in WinGate can help with some of these problem sites.

Alen wrote:
Bandwidth control is independent of access control in terms of ENS policy. ... So it should be possible to set bandwidth rules as if there were no ENS rules and vice versa. The ENS policy applies only for NAT traffic, which we define as being traffic through WinGate that has its address translated.

O-h, good, I was worrying my mission becomes impossible (with Wingate).
Well then, BC is not connected to ENS (NAT) service policy. Very well if so. But you mention another awful thing:...
Strange I cann't find it. Just reassure me BC can regulate all traffic, regardless of the connection method used (NAT, WGIC or Proxy)!?


Yes, You can specify a rule which will match anything. The only thing it can't regulate is traffic it doesn't see (localhost / loopback traffic, which doesn't go down to NDIS).

Alen wrote:
The bandwidth control however can control other sorts of traffic, such as
* traffic directly to / from the WinGate server
* traffic routed between local subnets

So for instance it's common to apply bandwidth control to the traffic sent by WinGate to the client computers (since it is easier to control sending than receiving).

Logan helped me with my needs connected with BC. I'll resume everything concerning it and post here for final verdict later.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 18 09 11:51 am

Alen wrote:
Alen wrote:
Well, as I understand, on DMZ interface I set any (private or illegal public?) ip, anything.
Then in Wingate advanced network properties for DMZ interface I activate "Enable ARP Responder" option and write there Wingate WAN ip.
On the other hand, on DMZ PCs I set Wingate WAN ip as default gateway.

Is this correct?
And what ip should I use on DMZ interface (I dont leave it on autoobtain, never know what will be tomorrow)?

adrien wrote:
In the past I've used bogus addresses like 1.2.3.4 on the DMZ interface.

Yes, you're correct, then you set the ARP responder for the DMZ interface to respond to the WAN IP (with mask 255.255.255.255).

You will also need to manually add a route to the route table on the WinGate machine so that it knows that your private subnet is out the DMZ adapter. This will probably mean setting the subnet mask on your WAN adapter to 255.255.255.255 (or depends how many of your public IPs you want outside the DMZ).

Still not totally clear, sorry. I don't understand the underlined part. What route should I add to route table to provide Wingate "knows that your private subnet is out the DMZ adapter"?
And how and why is this connected to the subnet mask of Wingate WAN interface and thus how many of my public IPs I want outside the DMZ?


What you need to take into account is what Windows does to the route table when you assign an IP and mask to an adapter.

Say you have been assigned a block of 15 IPs by your ISP in the range 210.1.1.0/28

Say you assign your WAN IP to 210.1.1.1 and set its mask to 255.255.255.240

The OS will then assume that all your IPs are accessed through your WAN adapter, and will create a route in your system route table to that effect.

If you then set your DMZ adapter IP to 1.2.3.4 mask 255.255.255.0, then the OS will create a route where 1.2.3.* is accessed through your DMZ interface.

If however your actual public IPs are going to be in the DMZ, then the system route table has it wrong, and you need to correct it. e.g.

route add 210.1.1.0 MASK 255.255.255.240 1.2.3.4

That tells the OS that those IPs are out the 1.2.3.4 adapter (which they are). This will create a route conflict though, since the network mask on the WAN adapter is telling the OS those IPS are local to it. So you set the network mask to 255.255.255.255. Now, in it's infinite (ly stupid) wisdom, MS decided to prohibit you from doing this in the UI, but you can do it in the registry.

What about the IP on the WAN-side of your default router though? How does your WinGate connect to the internet? Is that in the same subnet as you've been assigned? If so, you'd need to allow for access to that in your routes. For instance, our fibre router has IPs in a different subnet to the one's we've been assigned, so we just need to make sure the route table knows how to access that IP out the WAN adapter.

Notes re DMZ
1. WinGate does not do address translation, therefore computers on the DMZ must use public IPs to be accessible from the internet.
2. WinGate uses the system route table, so this must be correct to allow routing to the DMZ to work.

Alen wrote:What I understand:
1) I have my LAN interface with 192.168.20.10 /24, WAN interface with (say) 100.101.102.103 /29 and DMZ interface with 1.2.3.4 /32 (?) addresses.
2) In Wingate advanced network properties for DMZ interface I activate "Enable ARP Responder" option and write there Wingate WAN ip with 255.255.255.255 mask, i.e 100.101.102.103 /32.
3) On Wingate machine I register static route using route add? (from where to where and via which gateway?)
4) On DMZ PCs I set Wingate WAN ip as default gateway.
end


you can specify the adapter IP as the "gateway" in the route add command, and that tells the system it's a local subnet to that adapter.

Alen wrote:Additional question:
1. should we set Wingate WAN ip as gateway on DMZ interface anyway (regardless of ARP spoofing usage)?
2. doesn't this make problems (because as known Windows itself often becomes crazy when more than one default gateway is set, especially after some of them becoming unreachable and coming back)?


1. No, that's not required.
2. yes, which is why answer to 1 is no.

Adrien
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 18 09 10:06 pm

For NAT and also for WGIC, the client needs to be able to resolve IPs. They can do this any way they like, they don't need to use WinGate as a DNS server if you have another DNS server that can resolve internet names.

I know and understand this. You still don't see my question.
I am asking: if we want to use Wingate for clients DNS requests resolution (and we have not AD environment), then is it necessary to enable and use Wingate DNS service or just DNS Resolver is enough?
I am starting to think, that DNS Resolver is just a setting for Wingate DNS service and doesn't play any self-dependent role. I thought it can play the role of "Transparent DNS requests relay" when Wingate DNS service is disabled and this way Wingate will still is able to resolve DNS names for clients. So can it or not?
If its just one of the settings for Wingate DNS service, then why it is not set up into DNS service properties window?..


According to http://skypetips.internetvisitation.org ... s/faq.html, Skype uses the proxy settings set for your browser. I presume this means it uses the HTTP proxy to connect out using the CONNECT method, or it uses SOCKS.

Have you tested this?

Not yet, I can test everything only out of business hours and I am preparing to do it this Satturday (if I get answers on all of my actual questions). I believe it will work, so Skype would not be a problem. "Black box" apps could be a problem, but in case of my schema deployment it should also work, I believe.

Alen wrote:
Again, after thinking some time and taking into account the fact KAV and PureSight work only at the proxy level, it seems to me the best solution for the issue would be:
- to set all users to use web (and other required) proxy service, but add where needed in their browsers exclusions for the sites, which do not work via proxy,
- allow users who need to work with the problematic sites or proprietary apps to use NAT “service”, but with white list rule: to allow to access only “problematic” sites and addresses via NAT,
- do not activate transparent proxy for any service, as only a few sites and addresses will be accessible via NAT.

These schema will work only in case Skype really can and will work via Wingate HTTP Proxy.
Please give me some comments and advices. May be a better solution exists.

adrien wrote:
If you use a proxy auto-detect script I think you can specify on a site-by-site / protocol basis whether
a) to use a proxy or not
b) what sort of proxy (e.g HTTP proxy, or SOCKS).

You might find the SOCKS server in WinGate can help with some of these problem sites.

Ok, I'll think about script (but there are only a few "problematic" users, so my guys can freely do everything manually).
Unfortunately, I am not familiar with SOCKS proxy usage, besides those apps have not proxy setting option (so the only way is NAT + SOCKS with transparent proxy enabled, but for me it is easier to go by above mentioned way).
You did not say anything about the solution I posted. Do you think it's ok and will provide everything to work?


Say you assign your WAN IP to 210.1.1.1 and set its mask to 255.255.255.240
The OS will then assume that all your IPs are accessed through your WAN adapter, and will create a route in your system route table to that effect.

Yes, it's obvious as OS will think that those hosts are directly connected (via L2 devices), as they all are in one ip subnet.

If however your actual public IPs are going to be in the DMZ, then the system route table has it wrong, and you need to correct it. e.g.
route add 210.1.1.0 MASK 255.255.255.240 1.2.3.4

Yes, this is clear.

That tells the OS that those IPs are out the 1.2.3.4 adapter (which they are).

This "out" makes me misunderstand you previously. As I understand now "out" here means "connected to"!? (Don't forget, English is not my native language :-)).

This will create a route conflict though, since the network mask on the WAN adapter is telling the OS those IPS are local to it. So you set the network mask to 255.255.255.255.
Now, in it's infinite (ly stupid) wisdom, MS decided to prohibit you from doing this in the UI, but you can do it in the registry.

You mean route add 210.1.1.0 MASK 255.255.255.240 1.2.3.4 will not work even if we set WAN ip subnet mask to 255.255.255.255 and isolate the interface into separate subnet?
Is this because 210.1.1.0 and 1.2.3.4 are from different subnets?

So what is the solution? "Enable ARP respond"?
Does it make necessary changes in the registry or just passes the problem around?


What about the IP on the WAN-side of your default router though? How does your WinGate connect to the internet?

My network schema looks this way:
- all my branches and head office are interconnected via central core router, which is also connected (via one of its WAN interfaces) with Wingate (via its LAN interface)
- Wingate has a public ip on its WAN but is connected to a local router with public ip on its LAN (this was decided by our provider. WAN interface of the router has private ip and traffic is routed inside providers private network and only then then goes out. But the blued part, I believe, does not matter.)
As you can see, by default all PCs will have access (route) to internet, which I must restrict on the Wingate. And must do it maximum neatly and "sharply".

Is that in the same subnet as you've been assigned?

Yes, the next hop after Wingate (its gateway) is in the same subnet.
(Later I'll modify the schema and add a Cisco router between Wingate and the router I mentioned, because I want to rent 2 different lines and use them simultaneously for higher bandwidth plus resilience. I know I could do this by means of Wingate, but I was beware of installing 4 NICs in a Windows based PC...).

If so, you'd need to allow for access to that in your routes. For instance, our fibre router has IPs in a different subnet to the one's we've been assigned, so we just need to make sure the route table knows how to access that IP out the WAN adapter.

Why, if they are in the same subnet? May be you meant: "if not so, then you'd..."?


Alen wrote:
What I understand:
1) I have my LAN interface with 192.168.20.10 /24, WAN interface with (say) 100.101.102.103 /29 and DMZ interface with 1.2.3.4 /32 addresses.
2) In Wingate advanced network properties for DMZ interface I activate "Enable ARP Responder" option and write there Wingate WAN ip with 255.255.255.255 mask, i.e 100.101.102.103 /32.
3) On Wingate machine I register static route using route add? (from where to where and via which gateway?)
4) On DMZ PCs I set Wingate WAN ip as default gateway.
end

adrien wrote:
you can specify the adapter IP as the "gateway" in the route add command, and that tells the system it's a local subnet to that adapter.

Adrien, dear, can you give more detailed answer here, please?!
You wrote the adapter - which one?
Can you just post my above mentioned actions sequence modified with corrections and additions if needed.


Alen wrote:
Additional question:
1. should we set Wingate WAN ip as gateway on DMZ interface anyway (regardless of ARP spoofing usage)?
2. doesn't this make problems (because as known Windows itself often becomes crazy when more than one default gateway is set, especially after some of them becoming unreachable and coming back)?

1. No, that's not required.
2. yes, which is why answer to 1 is no.

I did not understand. What means it is not required? It can be done, but not necessary? Why? Wingate enables OS Routing option? Explain me the answer, please.
After rereading the point 2. I understand that if we do not use ARP spoofing on DMZ interface then WIngate WAN ip must not be set as gateway on DMZ interface?

But why I decided it must be done in case we use ARP spoofing!? I reread everything concerning DMZ issue and could not find you ever wrote such thing!? Damn!
Once more: regardless of ARP spoffing usage we should not set Wingate WAN ip as gateway for DMZ interface. Is this correct?
Obviously yes, but I'll wait for your answer.
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 19 09 1:31 am

Alen wrote:I am asking: if we want to use Wingate for clients DNS requests resolution (and we have not AD environment), then is it necessary to enable and use Wingate DNS service or just DNS Resolver is enough?
I am starting to think, that DNS Resolver is just a setting for Wingate DNS service and doesn't play any self-dependent role. I thought it can play the role of "Transparent DNS requests relay" when Wingate DNS service is disabled and this way Wingate will still is able to resolve DNS names for clients. So can it or not?
If its just one of the settings for Wingate DNS service, then why it is not set up into DNS service properties window?..


The WinGate DNS resolver (think of it like the OS DNS client) is only accessible to WinGate.exe. WinGate's DNS resolver is used by WinGate.exe whenever

a) WinGate needs to make a connection to somewhere and it only knows the servername
- E.g. a web proxy session.
- E.g. mail delivery
b) when it does checking on incoming mail
c) when a machine connects it uses DNS (PTR lookup) to try and look up the computer name.
d) when a DNS request is received by the WinGate DNS server.
e) probably some other not very interesting cases.

That's why it can't be turned off.

So, if you want your client machines to be able to resolve DNS, without using any other DNS server, you will need to enable the DNS service in WinGate, AND the WinGate DNS resolver must be able to resolve DNS.

It's not any sort of transparent relay.

Alen wrote:
According to http://skypetips.internetvisitation.org ... s/faq.html, Skype uses the proxy settings set for your browser. I presume this means it uses the HTTP proxy to connect out using the CONNECT method, or it uses SOCKS.

Have you tested this?

Not yet, I can test everything only out of business hours and I am preparing to do it this Satturday (if I get answers on all of my actual questions). I believe it will work, so Skype would not be a problem. "Black box" apps could be a problem, but in case of my schema deployment it should also work, I believe.

Again, after thinking some time and taking into account the fact KAV and PureSight work only at the proxy level, it seems to me the best solution for the issue would be:
- to set all users to use web (and other required) proxy service, but add where needed in their browsers exclusions for the sites, which do not work via proxy,
- allow users who need to work with the problematic sites or proprietary apps to use NAT “service”, but with white list rule: to allow to access only “problematic” sites and addresses via NAT,
- do not activate transparent proxy for any service, as only a few sites and addresses will be accessible via NAT.

These schema will work only in case Skype really can and will work via Wingate HTTP Proxy.
Please give me some comments and advices. May be a better solution exists.


At this stage I think the best thing is to test it.

Alen wrote:
adrien wrote:
If you use a proxy auto-detect script I think you can specify on a site-by-site / protocol basis whether
a) to use a proxy or not
b) what sort of proxy (e.g HTTP proxy, or SOCKS).

You might find the SOCKS server in WinGate can help with some of these problem sites.

Ok, I'll think about script (but there are only a few "problematic" users, so my guys can freely do everything manually).
Unfortunately, I am not familiar with SOCKS proxy usage, besides those apps have not proxy setting option (so the only way is NAT + SOCKS with transparent proxy enabled, but for me it is easier to go by above mentioned way).


There are also socksifying clients, and/or the WinGate Client, which you could install on the client machine which would pipe connections through either the SOCKS server or WinGate's proprietary Winsock Redirector Service.

In the end though if these black box apps will use port 80 for non-HTTP traffic, there will be problems intercepting connections in the WWW proxy, since it will intercept connections through SOCKS and the WRP service as well.

Alen wrote:You did not say anything about the solution I posted. Do you think it's ok and will provide everything to work?


I think it looked ok. I was just trying to give alternatives.

Alen wrote:
Say you assign your WAN IP to 210.1.1.1 and set its mask to 255.255.255.240
The OS will then assume that all your IPs are accessed through your WAN adapter, and will create a route in your system route table to that effect.

Yes, it's obvious as OS will think that those hosts are directly connected (via L2 devices), as they all are in one ip subnet.

If however your actual public IPs are going to be in the DMZ, then the system route table has it wrong, and you need to correct it. e.g.
route add 210.1.1.0 MASK 255.255.255.240 1.2.3.4

Yes, this is clear.

That tells the OS that those IPs are out the 1.2.3.4 adapter (which they are).

This "out" makes me misunderstand you previously. As I understand now "out" here means "connected to"!? (Don't forget, English is not my native language :-)).



basically yes - connected to. Routing in general (except for source routing systems) only considers the destination IP. So the system has a packet to send somewhere, and it needs to know which interface to send it out of. So it consults the route table, and that returns the interface, and route type (so whether the destination IP is considered local to that interface, or needs to be forwarded to another router, or broadcast). It then sends it out that interface.

So that's why I used the word "out".

Alen wrote:
This will create a route conflict though, since the network mask on the WAN adapter is telling the OS those IPS are local to it. So you set the network mask to 255.255.255.255.
Now, in it's infinite (ly stupid) wisdom, MS decided to prohibit you from doing this in the UI, but you can do it in the registry.

You mean route add 210.1.1.0 MASK 255.255.255.240 1.2.3.4 will not work even if we set WAN ip subnet mask to 255.255.255.255 and isolate the interface into separate subnet?
Is this because 210.1.1.0 and 1.2.3.4 are from different subnets?

So what is the solution? "Enable ARP respond"?
Does it make necessary changes in the registry or just passes the problem around?


ARP respond is just a way of getting around routing. The initial goal was to avoid using up another public IP on the DMZ adapter. If you have spare IPs, you could instead subnet your range of IPs. ARP spoofing/responder allows WinGate to trick machines connected to that adapter into sending the packet.

In your case, if you have another public IP on the WinGate-side of your main router, you could use that IP instead as the default gateway in the DMZ machines, and spoof that address on the DMZ adapter.

Alen wrote:
What about the IP on the WAN-side of your default router though? How does your WinGate connect to the internet?

My network schema looks this way:
- all my branches and head office are interconnected via central core router, which is also connected (via one of its WAN interfaces) with Wingate (via its LAN interface)
- Wingate has a public ip on its WAN but is connected to a local router with public ip on its LAN (this was decided by our provider. WAN interface of the router has private ip and traffic is routed inside providers private network and only then then goes out. But the blued part, I believe, does not matter.)
As you can see, by default all PCs will have access (route) to internet, which I must restrict on the Wingate. And must do it maximum neatly and "sharply".

Is that in the same subnet as you've been assigned?

Yes, the next hop after Wingate (its gateway) is in the same subnet.
(Later I'll modify the schema and add a Cisco router between Wingate and the router I mentioned, because I want to rent 2 different lines and use them simultaneously for higher bandwidth plus resilience. I know I could do this by means of Wingate, but I was beware of installing 4 NICs in a Windows based PC...).

If so, you'd need to allow for access to that in your routes. For instance, our fibre router has IPs in a different subnet to the one's we've been assigned, so we just need to make sure the route table knows how to access that IP out the WAN adapter.

Why, if they are in the same subnet? May be you meant: "if not so, then you'd..."?


It's getting quite hard to get a clear picture of your network here. Maybe better to submit a support ticket?

If in doubt, the things to remember when setting up routing, ARP spoofing or whatever are:

1. Route tables are consulted by computers when they have a packet they wish to deliver somewhere (either out to a computer, or up to some process on that same computer).
2. If a computer can't find a matching route, instead of sending the packet they will either
a) if it's an outbound packet from some process on the machine, they will report an error "destination unreachable" and drop the packet
b) if it's an inbound (received) packet destined for some other computer (e.g. the computer is routing) it will drop the packet and send an ICMP dest unreachable packet back.
3. The default route matches all destinations, so 2 will only occur if there is no default gateway configured.
4. If the matching route is through another gateway, the gateway ethernet address must be resolved by ARP. Once the gateway ethernet address is resolved, the computer writes it into the destination ethernet address header and sends it out the adapter.
5. If the matching route tells you the destination is connected to the adapter, then the destination address must be resolved by ARP.
6. If the ARP lookup fails, it will drop the packet and report the error same as if there is no route.

So, if you want to figure out how it all works, you need to put yourself in the shoes of each machine in this picture.

Say you are a DMZ machine, and you need to send a packet to the internet. You need a matching route to the dest IP (which means you need a default route/gateway), and you need to be able to obtain the ethernet (MAC) address of that gateway that will forward the packet (WinGate). You can configure WinGate with the ARP responder to give any machine its ethernet address, even if it doesn't own the address.

Say you are the WinGate machine. You need to be able to send packets to DMZ machines, and Internet machines.




Alen wrote:

Alen wrote:
What I understand:
1) I have my LAN interface with 192.168.20.10 /24, WAN interface with (say) 100.101.102.103 /29 and DMZ interface with 1.2.3.4 /32 addresses.
2) In Wingate advanced network properties for DMZ interface I activate "Enable ARP Responder" option and write there Wingate WAN ip with 255.255.255.255 mask, i.e 100.101.102.103 /32.
3) On Wingate machine I register static route using route add? (from where to where and via which gateway?)
4) On DMZ PCs I set Wingate WAN ip as default gateway.
end

adrien wrote:
you can specify the adapter IP as the "gateway" in the route add command, and that tells the system it's a local subnet to that adapter.

Adrien, dear, can you give more detailed answer here, please?!
You wrote the adapter - which one?
Can you just post my above mentioned actions sequence modified with corrections and additions if needed.


I was speaking generally. meaning that one can use "route add" to not only create routes to destinations through another router, but also routes which are local to an adapter. This affects how the route table forwards the packet (whether they do an ARP lookup for the gateway, or for the destination).

So in the case I was giving, "the" adapter referred to the adapter associated with the local IP (on the same machine) you specify as the gateway.

Alen wrote:
Alen wrote:
Additional question:
1. should we set Wingate WAN ip as gateway on DMZ interface anyway (regardless of ARP spoofing usage)?
2. doesn't this make problems (because as known Windows itself often becomes crazy when more than one default gateway is set, especially after some of them becoming unreachable and coming back)?

1. No, that's not required.
2. yes, which is why answer to 1 is no.

I did not understand. What means it is not required? It can be done, but not necessary? Why? Wingate enables OS Routing option? Explain me the answer, please.
After rereading the point 2. I understand that if we do not use ARP spoofing on DMZ interface then WIngate WAN ip must not be set as gateway on DMZ interface?

But why I decided it must be done in case we use ARP spoofing!? I reread everything concerning DMZ issue and could not find you ever wrote such thing!? Damn!
Once more: regardless of ARP spoffing usage we should not set Wingate WAN ip as gateway for DMZ interface. Is this correct?
Obviously yes, but I'll wait for your answer.


WinGate uses the system route table and performs routing itself, regardless of whether the OS is configured to route. You can control this separately in WinGate's ENS settings.

But it's a bad idea to set a default gateway setting on an adapter if that gateway does not provide a path to the internet. It causes problems.

It's also a bad idea to set the default gateway setting of any adapter to the IP of any other adapter on that same machine.

Unless there is a router connected to an adapter (i.e. on the same physical LAN segment) which provides a path to the internet, there should be no default gateway set on that adapter.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 19 09 1:50 am

The WinGate DNS resolver (think of it like the OS DNS client) is only accessible to WinGate.exe.

+
So, if you want your client machines to be able to resolve DNS, without using any other DNS server, you will need to enable the DNS service in WinGate, AND the WinGate DNS resolver must be able to resolve DNS.

That's it. Finally another long playing question is closed! :-)
Now I think I should ask you:
"If my clients use NAT and WGIC and I want to set Wingate LAN ip as DNS server on the clients (or on Forwarders tab on AD DC), is it necessary to enable Wingate DNS server or DNS Resolver will be able to resolve clients requests by relaying them to the "real" DNS servers it get from OS /has specified on its own settings?".
The answer:
"No, only DNS Resolver is not enough in that case, because it is used by Wingate itself (for internal purposes), it can't serve clients by itself and you have to enable and use Wingate DNS service"!
Oh-h. Done.


There are also socksifying clients, and/or the WinGate Client, which you could install on the client machine which would pipe connections through either the SOCKS server or WinGate's proprietary Winsock Redirector Service.

In the end though if these black box apps will use port 80 for non-HTTP traffic, there will be problems intercepting connections in the WWW proxy, since it will intercept connections through SOCKS and the WRP service as well.

Ok, I'll try it (WGIC) if my variant doesn't work.

I think it looked ok. I was just trying to give alternatives.

Thanks, it gives me hope.

Routing concerning questions - answers need to be read not one time. I need some time to read it to be able to understand (and ask new questions ;-)).

Thank you for your help.
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 19 09 3:26 am

As your next reply I'll see only tomorrow, let me post the rest of my gathered questions:

1. Does WGIC usage together with “Internet connection allowed” applications list control, help against worms and trojans activities as they will not get access to Internet to transfer stolen data or participate in DDOS attacks?

2. Citate: “With WinGate Enterprise licence, WGIC user Internet access and operations can be controlled from a central configuration menu in GateKeeper”.
What does this mean?
Is it possible to define applications list which should have Internet access and do this differently for different users and do it from one place - Wingate server?

3. Is it recommended to activate dead gateways detection if we have only one WAN interface with default gateway on it?

4. Let’s suppose we have 2 internet connections, both via modem devices connected to two separate NICs on Wingate, I mean just have two External interfaces.
Two scenarios:
1. The first line is cheap, the second is not. How to make Wingate to always use the first one when it works, the second when the first is down (and back to the first when it comes up)? Please instruct in details (generally I can suppose that one should setup gateways option in each Proxy service used + increase metric value for the second line.
But gateway option is found only on user services settings. What if NAT is used? What about Wingate e-mail server traffic?
And what means metric for Wingate? Hops, reply on request latency, bandwidth or what? And could it be choosen at will?)
2. Both lines are cheap and the question is just to get load balancing and speed increase.

5. Does Wingate registry hive contain users and groups data?
Is it enough for full backup of everything just to backup Wingate settings (from inside Wingate or by exporting registry hive)?

6. As I suppose I can easily migrate from Wingate on XP Pro machine to Wingate on W2k3 (both 32 bit) just by deactivating-activating the program and exporting-importing registry settings of Wingate. Is this correct?

7. As I remember Windows XP Pro had limitations for max 10 half-open network connections (and also for shared resources simultaneous access, which is not important for Internet access). Are there any other known limitations connected to network functionality?

What means half-opened TCP connections (I don’t need the exact technical description, just how it can influence on Internet access via XP based server. E.g. if one has downloading in process this is not half opened connection, but I had mentioned that even downloads freeze for some time when many users were accessing Internet. May be this is result of another XP limitations?..).

And has SP3 for XP bring anything new in this context?
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 19 09 4:58 am

adrien wrote:
Say you assign your WAN IP to 210.1.1.1 and set its mask to 255.255.255.240
The OS will then assume that all your IPs are accessed through your WAN adapter, and will create a route in your system route table to that effect. If however your actual public IPs are going to be in the DMZ, then the system route table has it wrong, and you need to correct it. e.g. route add 210.1.1.0 MASK 255.255.255.240 1.2.3.4
That tells the OS that those IPs are out the 1.2.3.4 adapter (which they are).

This will create a route conflict though, since the network mask on the WAN adapter is telling the OS those IPS are local to it. So you set the network mask to 255.255.255.255.
Now, in it's infinite (ly stupid) wisdom, MS decided to prohibit you from doing this in the UI, but you can do it in the registry.

Alen wrote:
You mean route add 210.1.1.0 MASK 255.255.255.240 1.2.3.4 will not work even if we set WAN ip subnet mask to 255.255.255.255 and isolate the interface into separate subnet?
Is this because 210.1.1.0 and 1.2.3.4 are from different subnets?

You did not answer the questions. Please answer and say what is the solition in this case.

ARP respond is just a way of getting around routing. The initial goal was to avoid using up another public IP on the DMZ adapter. If you have spare IPs, you could instead subnet your range of IPs. ARP spoofing/responder allows WinGate to trick machines connected to that adapter into sending the packet.

In your case, if you have another public IP on the WinGate-side of your main router, you could use that IP instead as the default gateway in the DMZ machines, and spoof that address on the DMZ adapter.

Ok, the latter is quite clear: instead of spoofing Wingate WAN ip on its DMZ interface we spoof the former's default gateway - transit router ip (and we can do it, because it is on the same subnet with WAN. But I suspect the mask of WAN should be changed!? e.g. from 255.255.255.255 to something which includes the transit routers ip, but not include DMZ PCs ips!?). Right?

It's getting quite hard to get a clear picture of your network here.

Look at the attached picture. It's quite simple schema.

If in doubt, the things to remember when setting up routing, ARP spoofing or whatever are:

1. Route tables are consulted by computers when they have a packet they wish to deliver somewhere (either out to a computer, or up to some process on that same computer).
2. If a computer can't find a matching route, instead of sending the packet they will either
a) if it's an outbound packet from some process on the machine, they will report an error "destination unreachable" and drop the packet
b) if it's an inbound (received) packet destined for some other computer (e.g. the computer is routing) it will drop the packet and send an ICMP dest unreachable packet back.
3. The default route matches all destinations, so 2 will only occur if there is no default gateway configured.
4. If the matching route is through another gateway, the gateway ethernet address must be resolved by ARP. Once the gateway ethernet address is resolved, the computer writes it into the destination ethernet address header and sends it out the adapter.
5. If the matching route tells you the destination is connected to the adapter, then the destination address must be resolved by ARP.
6. If the ARP lookup fails, it will drop the packet and report the error same as if there is no route.

So, if you want to figure out how it all works, you need to put yourself in the shoes of each machine in this picture.

Thank you, but I know all of this...

Say you are a DMZ machine, and you need to send a packet to the internet. You need a matching route to the dest IP (which means you need a default route/gateway), and you need to be able to obtain the ethernet (MAC) address of that gateway that will forward the packet (WinGate). You can configure WinGate with the ARP responder to give any machine its ethernet address, even if it doesn't own the address.

And this you already explained me and I learned the lesson well.

it's a bad idea to set a default gateway setting on an adapter if that gateway does not provide a path to the internet. It causes problems.

It's also a bad idea to set the default gateway setting of any adapter to the IP of any other adapter on that same machine.

Unless there is a router connected to an adapter (i.e. on the same physical LAN segment) which provides a path to the internet, there should be no default gateway set on that adapter.

Important, reasonable, well known and understandable. Thank you.

All this I know. Trust me. (But you explain network basics just briliantly. I am serious.).
I was asking... I think I forget what I was asking about ;-(. Let me reread this big sheet.

Ok, I was asking the following:
If I have LAN (corporate network more precisely, which includes also branches LANs, see the schema), DMZone with some servers into it (web server and mail server) and Internet connection. I have Wingate with 3 NICs called: LAN, DMZ, WAN. And I want to organize all this to function the best way.
Internet connection.GIF
Internet connection.GIF (6.58 KiB) Viewed 377427 times

Ok. We decide to do the following to make everything work (according what you explain me and what I could understand):
1) set /29 mask on WAN interface, plus /32 on DMZ interface fake addresse.
2) In Wingate advanced network properties for DMZ interface activate "Enable ARP Responder" option and write there Wingate WAN ip (or Internet router LAN ip) with 255.255.255.255 mask, i.e 100.101.102.10 /32 (100.101.102.9 /32).
3) On Wingate machine register static route using route add!? As I understand we need route to go to DMZone via DMZ interface, not WAN (here you say OS will not allow us to add such route. Or it will?)
4) On DMZ PCs I set Wingate WAN ip (or Internet router LAN ip) as default gateway.

What is right/wrong?
What to do with the route to DMZone? (Suddenly I saw the elephant - I realize, that ARP Spoofing solves this, we do not need this route if we activate ARP Responder. Wingate takes it on itself, OS does nothing in here!?)
What else should be done to make the network work?

And what if public ip addresses of Wingate, Internet router and DMZone are such ips, which is not possible to distribute the way we did (Wingate WAN and Internet router LAN in separated subnetwork, which does not include hosts from DMZ)?! Just curious.
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 19 09 10:17 pm

Alen wrote:As your next reply I'll see only tomorrow, let me post the rest of my gathered questions:

1. Does WGIC usage together with “Internet connection allowed” applications list control, help against worms and trojans activities as they will not get access to Internet to transfer stolen data or participate in DDOS attacks?


That's the intention. When any application loads windows sockets on a computer on which the WGIC is installed, then our LSP (layered service provider - the WGIC) is loaded. It connects to the WRP service in WinGate, where it can be asked to authenticate, and for the application name. If the application name is not allowed to run (based on config policy in the WRP service), then the client is told to terminate. The LSP then exits the application after posting a message to the user saying the application is not allowed to run.

Alen wrote:2. Citate: “With WinGate Enterprise licence, WGIC user Internet access and operations can be controlled from a central configuration menu in GateKeeper”.
What does this mean?
Is it possible to define applications list which should have Internet access and do this differently for different users and do it from one place - Wingate server?


yes as per above.

Alen wrote:3. Is it recommended to activate dead gateways detection if we have only one WAN interface with default gateway on it?


no, since you can't do anything with the knowledge it's better to turn it off. It's usually used if there are multiple gateways so it can select another one.

Alen wrote:4. Let’s suppose we have 2 internet connections, both via modem devices connected to two separate NICs on Wingate, I mean just have two External interfaces.
Two scenarios:
1. The first line is cheap, the second is not. How to make Wingate to always use the first one when it works, the second when the first is down (and back to the first when it comes up)? Please instruct in details (generally I can suppose that one should setup gateways option in each Proxy service used + increase metric value for the second line.
But gateway option is found only on user services settings. What if NAT is used? What about Wingate e-mail server traffic?
And what means metric for Wingate? Hops, reply on request latency, bandwidth or what? And could it be choosen at will?)


WinGate NAT / ENS uses the system route table. It may modify it if you override metric on an adapter in WinGate. WinGate ENS always has the last word in routing, since it is below the OS router. So, if you override an adapter metric in WinGate, you can get the routes associated with that adapter to be promoted or demoted.

Services on the other hand use whichever gateway you specify. The reason why this is only available in services is a long story. We do plan to make this functionality available to NAT as well, but in a more flexible way.

What this means is that services can fail over to another connection, but NAT doesn't, since it still has the routes to the other gateway.

Alen wrote:2. Both lines are cheap and the question is just to get load balancing and speed increase.


in this case just choose to rotate connections (in the gateways tab of the service). This doesn't work perfectly though, since the connections from a single client can hit a web server with different source IPs.

Alen wrote:5. Does Wingate registry hive contain users and groups data?
Is it enough for full backup of everything just to backup Wingate settings (from inside Wingate or by exporting registry hive)?


yes, all the data is in there.

Alen wrote:6. As I suppose I can easily migrate from Wingate on XP Pro machine to Wingate on W2k3 (both 32 bit) just by deactivating-activating the program and exporting-importing registry settings of Wingate. Is this correct?


yes. Remember that when importing registry settings, they are merged with anything that is already there, therefore you need to delete the WinGate registry before you import.

Alen wrote:7. As I remember Windows XP Pro had limitations for max 10 half-open network connections (and also for shared resources simultaneous access, which is not important for Internet access). Are there any other known limitations connected to network functionality?


not that I know of. That 10 half-open limit can be a bit of a problem, in which case there is a patched tcpip.sys that can be applied which removes the limit.

Alen wrote:What means half-opened TCP connections (I don’t need the exact technical description, just how it can influence on Internet access via XP based server. E.g. if one has downloading in process this is not half opened connection, but I had mentioned that even downloads freeze for some time when many users were accessing Internet. May be this is result of another XP limitations?..).

And has SP3 for XP bring anything new in this context?


half-open means that the SYN packet has been sent, but no SYN-ACK has been received from the peer. So the connection has been initiated, but not completed.

SP3 doesn't change what they introduced in SP2.

Each time the limit is reached, the OS posts a message to the system event log from tcp/ip. You can look in there to see if this is happening. When it happens it can have quite an impact, since it then starts choking back new connections. Thanks to Microsoft for saving us from ourselves! I think they did it so they could promote sales of their server OSes, which don't have this limitation.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 19 09 10:39 pm

Alen wrote:
adrien wrote:
Say you assign your WAN IP to 210.1.1.1 and set its mask to 255.255.255.240
The OS will then assume that all your IPs are accessed through your WAN adapter, and will create a route in your system route table to that effect. If however your actual public IPs are going to be in the DMZ, then the system route table has it wrong, and you need to correct it. e.g. route add 210.1.1.0 MASK 255.255.255.240 1.2.3.4
That tells the OS that those IPs are out the 1.2.3.4 adapter (which they are).

This will create a route conflict though, since the network mask on the WAN adapter is telling the OS those IPS are local to it. So you set the network mask to 255.255.255.255.
Now, in it's infinite (ly stupid) wisdom, MS decided to prohibit you from doing this in the UI, but you can do it in the registry.

Alen wrote:
You mean route add 210.1.1.0 MASK 255.255.255.240 1.2.3.4 will not work even if we set WAN ip subnet mask to 255.255.255.255 and isolate the interface into separate subnet?
Is this because 210.1.1.0 and 1.2.3.4 are from different subnets?

You did not answer the questions. Please answer and say what is the solition in this case.


that route add will work. I only said setting the mask to 255.255.255.255 on an adapter in the UI will fail, and you'll need to use the registry to set the network mask to that. But you'll actually not want to use 255.255.255.255 in your case, since you need to allow room for your router's address as well.

Alen wrote:
ARP respond is just a way of getting around routing. The initial goal was to avoid using up another public IP on the DMZ adapter. If you have spare IPs, you could instead subnet your range of IPs. ARP spoofing/responder allows WinGate to trick machines connected to that adapter into sending the packet.

In your case, if you have another public IP on the WinGate-side of your main router, you could use that IP instead as the default gateway in the DMZ machines, and spoof that address on the DMZ adapter.

Ok, the latter is quite clear: instead of spoofing Wingate WAN ip on its DMZ interface we spoof the former's default gateway - transit router ip (and we can do it, because it is on the same subnet with WAN. But I suspect the mask of WAN should be changed!? e.g. from 255.255.255.255 to something which includes the transit routers ip, but not include DMZ PCs ips!?). Right?

It's getting quite hard to get a clear picture of your network here.

Look at the attached picture. It's quite simple schema.

If in doubt, the things to remember when setting up routing, ARP spoofing or whatever are:

1. Route tables are consulted by computers when they have a packet they wish to deliver somewhere (either out to a computer, or up to some process on that same computer).
2. If a computer can't find a matching route, instead of sending the packet they will either
a) if it's an outbound packet from some process on the machine, they will report an error "destination unreachable" and drop the packet
b) if it's an inbound (received) packet destined for some other computer (e.g. the computer is routing) it will drop the packet and send an ICMP dest unreachable packet back.
3. The default route matches all destinations, so 2 will only occur if there is no default gateway configured.
4. If the matching route is through another gateway, the gateway ethernet address must be resolved by ARP. Once the gateway ethernet address is resolved, the computer writes it into the destination ethernet address header and sends it out the adapter.
5. If the matching route tells you the destination is connected to the adapter, then the destination address must be resolved by ARP.
6. If the ARP lookup fails, it will drop the packet and report the error same as if there is no route.

So, if you want to figure out how it all works, you need to put yourself in the shoes of each machine in this picture.

Thank you, but I know all of this...

Say you are a DMZ machine, and you need to send a packet to the internet. You need a matching route to the dest IP (which means you need a default route/gateway), and you need to be able to obtain the ethernet (MAC) address of that gateway that will forward the packet (WinGate). You can configure WinGate with the ARP responder to give any machine its ethernet address, even if it doesn't own the address.

And this you already explained me and I learned the lesson well.

it's a bad idea to set a default gateway setting on an adapter if that gateway does not provide a path to the internet. It causes problems.

It's also a bad idea to set the default gateway setting of any adapter to the IP of any other adapter on that same machine.

Unless there is a router connected to an adapter (i.e. on the same physical LAN segment) which provides a path to the internet, there should be no default gateway set on that adapter.

Important, reasonable, well known and understandable. Thank you.

All this I know. Trust me. (But you explain network basics just briliantly. I am serious.).
I was asking... I think I forget what I was asking about ;-(. Let me reread this big sheet.

Ok, I was asking the following:
If I have LAN (corporate network more precisely, which includes also branches LANs, see the schema), DMZone with some servers into it (web server and mail server) and Internet connection. I have Wingate with 3 NICs called: LAN, DMZ, WAN. And I want to organize all this to function the best way.
Internet connection.GIF

Ok. We decide to do the following to make everything work (according what you explain me and what I could understand):
1) set /29 mask on WAN interface, plus /32 on DMZ interface fake addresse.
2) In Wingate advanced network properties for DMZ interface activate "Enable ARP Responder" option and write there Wingate WAN ip (or Internet router LAN ip) with 255.255.255.255 mask, i.e 100.101.102.10 /32 (100.101.102.9 /32).
3) On Wingate machine register static route using route add!? As I understand we need route to go to DMZone via DMZ interface, not WAN (here you say OS will not allow us to add such route. Or it will?)
4) On DMZ PCs I set Wingate WAN ip (or Internet router LAN ip) as default gateway.

What is right/wrong?
What to do with the route to DMZone? (Suddenly I saw the elephant - I realize, that ARP Spoofing solves this, we do not need this route if we activate ARP Responder. Wingate takes it on itself, OS does nothing in here!?)
What else should be done to make the network work?

And what if public ip addresses of Wingate, Internet router and DMZone are such ips, which is not possible to distribute the way we did (Wingate WAN and Internet router LAN in separated subnetwork, which does not include hosts from DMZ)?! Just curious.


OK, what I would probably do is this. This way then doesn't matter if you can't properly subnet your addresses between WAN and DMZ.

I am assuming your address allocation is /29 (6 addresses?)

1. On Internet router.
a) set mask to /29 not /30. then the internet router will do ARP for all your public IPs (it will treat them as local). This plus 2b below avoids having to set an extra route on the internet router for your DMZ.

2. On WinGate machine WAN adapter
a) set network mask to 255.255.255.255 (probably need to do this in registry)
b) set ARP responder to 100.101.102.12 / 29. This range includes WinGate WAN adapter IP, but It does not matter if we arp spoof ourself (that's then not actually spoofing, just that WinGate will answer for the OS). This will cause the router to send all packets for 100.101.102.12 / 29 to WinGate's WAN ethernet address.
c) route add -p 100.101.102.8 MASK 255.255.255.248 1.2.3.4 (tells WinGate OS that public IPs are out DMZ interface)
d) route add -p 100.101.102.9 MASK 255.255.255.255 100.101.102.10 (tells WinGate OS that Internet router is out WAN interface not DMZ interface)

3. On WinGate machine DMZ adapter
a) set ARP responder to 100.101.102.9 / 32 (this will fool DMZ machines to send packets for their default route to WinGate).

4. On DMZ machines
a) set default gateway to 100.101.102.9

5. On WinGate machine LAN adapter
a) make sure there is no default gateway set.
b) make sure there are routes for the company networks via Core router. E.g. route add -p 192.168.0.0 MASK 255.255.255.0 192.168.200.10 etc.


I'm not 100% certain about the mask of 255.255.255.255 for the WAN adapter - whether or not windows will accept this. If not, you'll have to set it to 255.255.255.252, which wastes another IP address (since you create a new broadcast address). I'm pretty sure I've done the /32 mask before ok, but not sure about all OSes. Later ones tend to think they are smarter than we are.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 20 09 2:49 am

Great work, thank you very much.

Let's go further.

- Is it necessary to have GDP enabled to be able to login into Gatekeeper locally\remotely (in case Gatekeeper user knows Wingate ip)?
Addition: partly checked: I am able to login locally. What about remotely?

- WGIC finds Wingate by means of GDP and broadcast message. => If routers which connect LAN to Wingate filter (drop) broadcasts WGIC will not work!?

- What is mapped link and how does it work? I need a simple explanation.
For example, port forwarding (mapping) is when we say to a requests receiver server to retransmit (redirect) requests received on particular port to another particular machine and resend them in their original state, as they were received initially (just redirection, no processing).

- Why people change service ports for “internal” proxies? What does it give?

- In some proxies properties (Server requests tab) we have the Server requests option and its default value is “Reject requests”. Is this about internal requests – requests made by LAN users or it’s about requests from the Internet?

- In server requests we have an option: “Pipe request through to predetermined server”. What does here piping mean? Is it usual port mapping or mapped link?

- When we choose to log “Request details” in "service logs" -> "session events" section, does it also register the time request was done? (Want to decide do I need to log “Session creation” or logging "Request detail" is enough)

- Citate:
“Notes: When using WRP and the WinGate Internet Client, or a socks client and server, ALL client computers will immediately become multi-homed”.

What does this mean? AFAIK, multihomed is called a PC which has 2 or more network interfaces\connections looking at different networks.
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 20 09 3:45 am

OK, what I would probably do is this. This way then doesn't matter if you can't properly subnet your addresses between WAN and DMZ.

I am assuming your address allocation is /29 (6 addresses?) - I will, for now I have 4-2=2 ips, but when I'll want to setup servers, I'll rent 8-2=6 ips (may be more, but don't worry I am able to understand what should be changed). So you understand correctly.

1. On Internet router.
a) set mask to /29 not /30. then the internet router will do ARP for all your public IPs (it will treat them as local). This plus 2b below avoids having to set an extra route on the internet router for your DMZ.

2. On WinGate machine WAN adapter
a) set network mask to 255.255.255.255 (probably need to do this in registry)
b) set ARP responder to 100.101.102.12 / 29. This range includes WinGate WAN adapter IP, but It does not matter if we arp spoof ourself (that's then not actually spoofing, just that WinGate will answer for the OS). This will cause the router to send all packets for 100.101.102.12 / 29 to WinGate's WAN ethernet address.
c) route add -p 100.101.102.8 MASK 255.255.255.248 1.2.3.4 (tells WinGate OS that public IPs are out DMZ interface)
d) route add -p 100.101.102.9 MASK 255.255.255.255 100.101.102.10 (tells WinGate OS that Internet router is out WAN interface not DMZ interface)

3. On WinGate machine DMZ adapter
a) set ARP responder to 100.101.102.9 / 32 (this will fool DMZ machines to send packets for their default route to WinGate).

4. On DMZ machines
a) set default gateway to 100.101.102.9

5. On WinGate machine LAN adapter
a) make sure there is no default gateway set.
b) make sure there are routes for the company networks via Core router. E.g. route add -p 192.168.0.0 MASK 255.255.255.0 192.168.200.10 etc.


I understand everything except "100.101.102.12 / 29". Do you mean 100.101.102.8 / 29?
And it also includes router ip (but as I understand this is not a problem, because only router LAN and Wingate WAN are in the segment)!?

And as I understand 2.d + 3. we make WIngate DMZ to say: "yes I am 100.101.102.9" (Internet router), receive the packet, then check route table and found that packets for 100.101.102.9 it must forward via its WAN interface. Correct?

And routes from 2.c) and 2.d) will work properly as (AFAIK) more "narrow" route has higher priority!

I'm not 100% certain about the mask of 255.255.255.255 for the WAN adapter - whether or not windows will accept this. If not, you'll have to set it to 255.255.255.252, which wastes another IP address (since you create a new broadcast address). I'm pretty sure I've done the /32 mask before ok, but not sure about all OSes.

Just tried on XP S3, OS doesn't allow.
I found this way (I think you use it)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
Find the entry corresponding to required NIC and edit the mask there.
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 20 09 9:36 am

Alen wrote:Great work, thank you very much.


You're welcome.

Alen wrote:Let's go further.

- Is it necessary to have GDP enabled to be able to login into Gatekeeper locally\remotely (in case Gatekeeper user knows Wingate ip)?
Addition: partly checked: I am able to login locally. What about remotely?


No, it's not necessary. GDP is only used by WGIC. GateKeeper you specify the IP you will connect to. As long as the RCS is bound to a LAN adapter, and you have a pro or better license, you can use GateKeeper remotely (with some restrictions, such as no History panel or plugin config - unless you run it over a mapped drive off the WinGate server itself).

Alen wrote:
- WGIC finds Wingate by means of GDP and broadcast message. => If routers which connect LAN to Wingate filter (drop) broadcasts WGIC will not work!?


The clients would then not automatically find the WinGate server. Unless you can configure broadcast relaying or forwarding of port 368.

The clients can be configured to connect to a specified server (e.g. just enter the IP). That works fine across subnets.

Alen wrote:
- What is mapped link and how does it work? I need a simple explanation.


Mapped link. Basically it's a simple pipe. you set it up to connect somewhere (some IP:port). then you connect to it, and it connects out, and relays data back and forth. It's largely superceded by ENS redirects (port forwarding), but has some other uses still.

Alen wrote:For example, port forwarding (mapping) is when we say to a requests receiver server to retransmit (redirect) requests received on particular port to another particular machine and resend them in their original state, as they were received initially (just redirection, no processing).


TCP Mapping does a small amount of processing. It can also specify gateway, and actually you can get it to intercept connections, and connect to original destination (rather than specific destination - just leave all mappings and default mapping empty). It also does some protocol snooping to display (if known) what is going through the mapping.

Alen wrote:- Why people change service ports for “internal” proxies? What does it give?


Not sure why. If you are running IIS on port 80 for intranet you might want to run your WWW proxy on another port to avoid port conflict.

Alen wrote:- In some proxies properties (Server requests tab) we have the Server requests option and its default value is “Reject requests”. Is this about internal requests – requests made by LAN users or it’s about requests from the Internet?


This is requests that are not in the form required for a proxy server. E.g. if a web client treats WinGate as a web server rather than a proxy. This is used for instance in the WWW proxy to handle reverse proxying. Default is to reject the request.

Alen wrote:
- In server requests we have an option: “Pipe request through to predetermined server”. What does here piping mean? Is it usual port mapping or mapped link?


sort of - it makes the connection to the specified server:port, but still performs protocol analysis / control. It's still handled by the proxy, not handed off to a mapping proxy or anything like that.

Alen wrote:- When we choose to log “Request details” in "service logs" -> "session events" section, does it also register the time request was done? (Want to decide do I need to log “Session creation” or logging "Request detail" is enough)


all log entries are time stamped. The request details are logged when the request is made (not completed, as in some). We log another entry when complete with traffic details etc. There are some log analysers that can analyse WinGate log formats.

Alen wrote:- Citate:
“Notes: When using WRP and the WinGate Internet Client, or a socks client and server, ALL client computers will immediately become multi-homed”.

What does this mean? AFAIK, multihomed is called a PC which has 2 or more network interfaces\connections looking at different networks.


Hmm, that statement is incorrect. We don't create any virtual adapter or anything like that. The machine effectively gains another IP (but the OS doesn't know about it). I'd just ignore this statement.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 20 09 9:39 am

Alen wrote:I understand everything except "100.101.102.12 / 29". Do you mean 100.101.102.8 / 29?
And it also includes router ip (but as I understand this is not a problem, because only router LAN and Wingate WAN are in the segment)!?


Sorry, I didn't spend the time to figure out what the base address should be. It should be the definition for the block of IPs you were assigned.

Alen wrote:And as I understand 2.d + 3. we make WIngate DMZ to say: "yes I am 100.101.102.9" (Internet router), receive the packet, then check route table and found that packets for 100.101.102.9 it must forward via its WAN interface. Correct?


yes

Alen wrote:And routes from 2.c) and 2.d) will work properly as (AFAIK) more "narrow" route has higher priority!


yes

Alen wrote:
I'm not 100% certain about the mask of 255.255.255.255 for the WAN adapter - whether or not windows will accept this. If not, you'll have to set it to 255.255.255.252, which wastes another IP address (since you create a new broadcast address). I'm pretty sure I've done the /32 mask before ok, but not sure about all OSes.

Just tried on XP S3, OS doesn't allow.
I found this way (I think you use it)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
Find the entry corresponding to required NIC and edit the mask there.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 21 09 1:20 am

Alen wrote:
In some proxies properties (Server requests tab) we have the Server requests option and its default value is “Reject requests”. Is this about internal requests – requests made by LAN users or it’s about requests from the Internet?

adrien wrote:
This is requests that are not in the form required for a proxy server. E.g. if a web client treats WinGate as a web server rather than a proxy. This is used for instance in the WWW proxy to handle reverse proxying. Default is to reject the request.

This is not what I was asking about, but anyway I read Wingate firewall has all incoming ports closed by default and I conclude "Server requests" option concerns to LAN users only.

Depending DMZone organization everything is clear now. I'll ask just one more question later, in the section of firewall questions.
Thank you.
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 21 09 3:40 am

- Citate: “…if you have a domain name, you will need to run a third party DNS Server”.
Isn’t it possible and enough to ask provider to register required addresses on his DNS server for our web and mail servers? Why is own DNS server use mandatory (if we have own web and other servers)?

DNS is essential for providing name lookup ability for the PCs on your network. While it is recommended that you use the DNS in WinGate, there are other options. Various methods are detailed below, with their pros and cons.
1. Wingate DNS server
...
2. Mapped Link method
This method is detailed in Adding a Mapped Link. The UDP Mapped link on port 53 allows all DNS requests to be mapped to an external DNS server. It is usually that of your ISP.
...
3. Third party DNS server
...

Why should we use mapped link? We can use NAT + restriction by white list with provider's DNS server in it for clients "direct" DNS requests!?

- What size to set for a cache size limit? (~ 20 users).
I am afraid setting too large size will result in too much data to become out-of-date. If you only have an option to delete files older than x days, this would be quite useful. I know I can purge or clean (?) cache by scheduler, but this not the same...

- What is the max size for logs and audit files?

- Routing -> Relay UDP broadcast packets.
Does Relay broadcast packets function relay only packets for the ports, listed and choosen in Advanced broadcast port settings?!

- Firewall -> Discard spoofed packets
If this option is enabled, WinGate will check to ensure that the source IP address in the packet header is really the computer that made the request. If it is not, the packet will be discarded

How does it work? How Wingate can check that the source IP is really the computer that made the request?

Can this anyhow conflict with ARP Responder function activated on Wingate WAN interface? I think not, but want to check.

- What if we open some Internet 2 LAN or 2 DMZ ports and does not check Notify on access box, does this prevent any logging of "outsiders" connections to LAN|DMZ?
I mean, when LAN users access any WIngate service we can log it either as service sessions, or user activity audit, which is good. What about logging facilities of the connections from Internet (to Wingate or through Wingate to DMZ or LAN)?
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby Alen » Nov 21 09 3:41 am

One "big" question:
We have 5 connection types\directions in Wingate Firewall window and in fact the following actual settings (as I understand):
Deny: Internet 2 LAN|DMZ,
Allow: LAN|DMZ 2 Internet, LAN|DMZ 2 Wingate, LAN 2 DMZ.

What about DMZ 2 LAN traffic?

This is actual question for me. Because of the following task, we will
1. Install a web server in DMZ zone to which clients from outside have to connect requesting data the web server has to obtain from the DB server inside my LAN.
2. Install an e-mail server in DMZ to serve clients inside and outside my LAN.

As I understand the most convenient and quite secure variant is to place those servers into DMZ zone. This way outside clients will make direct requests to the servers but the latters will be secured by Wingate firewall.
There are also other variants, like placing servers inside LAN and make port forwarding, etc.
Which one to prefer? (for now, as you understand, I am inclined to the DMZ variant)

In case we choose DMZ creation, I need to clarify the following:
- is it possible to open\close ports to each server inside DMZ individually (e.g. open only 80 and 443 for webserver, 25 for e-mail server, etc.)? /As I understand I can do it by adding port range for Internet to DMZ direction and redirect traffic to the corresponding server.
- is it possible to allow incoming traffic from DMZ to LAN only (I can’t see neither Connections from DMZ to LAN nor from LAN to DMZ in the Port security window! As I understand LAN connections to the Internet is LAN 2 Internet and LAN 2 DMZ. But I cann't see anything which could be used for DMZ 2 LAN setup)?
- how will servers inside DMZ serve LAN clients? Is any mechanism forseen for it?
- is it possible to open only necessary ports from the web server (on DMZone) to DB server (on LAN) only?
Alen
WinGate Master
 
Posts: 217
Joined: Sep 21 09 7:50 pm

Re: Many questions and a few comments after reading Wingate help

Postby adrien » Nov 23 09 5:05 pm

Alen wrote:
Alen wrote:
In some proxies properties (Server requests tab) we have the Server requests option and its default value is “Reject requests”. Is this about internal requests – requests made by LAN users or it’s about requests from the Internet?

adrien wrote:
This is requests that are not in the form required for a proxy server. E.g. if a web client treats WinGate as a web server rather than a proxy. This is used for instance in the WWW proxy to handle reverse proxying. Default is to reject the request.

This is not what I was asking about, but anyway I read Wingate firewall has all incoming ports closed by default and I conclude "Server requests" option concerns to LAN users only.


No. You're talking about the Server requests tab (that was in your post). This is not interface-specific. It's to do with the form / nature of the request itself. There are proxy requests, and other requests (ones that don't fit the requirements of a proxy request). We call these server requests. e.g. for HTTP:

GET http://www.wingate.com/ HTTP/1.0
Host: www.wingate.com
etc

is a proxy request

GET / HTTP/1.0
Host: www.wingate.com
etc

is a server request.
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Next

Return to WinGate

Who is online

Users browsing this forum: No registered users and 21 guests

cron