Moderator: Qbik Staff
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?
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)
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)!?
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?!
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)
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?
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?
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).
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?
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?
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?
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?
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”.
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?
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)?
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?
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).
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.
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?
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.
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?
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?)
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.
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.
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.
(rephrased)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.
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).
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.
Firewall hits are base64 coded packet data.
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.
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:- Is Wingate DNS Resolver enough for NAT connection method to work?
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?
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?
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?
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).
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).
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?!
11/15/09 00:00:23 fe314dI31iMAiQQ1AQAAABEADEHxnhkAES9DpNoAAEUAAMuzwgAAdxFzNX3t9eHSN9YjAAAAAAAAAAAAAAAAAAAAAAAAAAAAiQQ1ALd27EjRhAAAAAABAAAAACBDS0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUEA
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?
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?
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?
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?
Alen wrote:Why should we need it? Can you provide me with some examples of real scenarios?
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).
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.
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.
Alen wrote:I should ask you: Is Wingate DNS Resolver enough for Internet connections to work?
And the answer is: "Yes".
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).
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)?
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)?
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...
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.
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.
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.
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.
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).
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).
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".
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.
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...
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.
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)!?
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.
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?
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
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)?
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.
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?
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.
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.
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.
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.
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.
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?..
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.
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).
Alen wrote:You did not say anything about the solution I posted. Do you think it's ok and will provide everything to work?
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 :-)).
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?
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..."?
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.
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.
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.
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.
I think it looked ok. I was just trying to give alternatives.
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?
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.
It's getting quite hard to get a clear picture of your network here.
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.
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.
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?
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?
Alen wrote:3. Is it recommended to activate dead gateways detection if we have only one WAN interface with default gateway on it?
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?)
Alen wrote:2. Both lines are cheap and the question is just to get load balancing and speed increase.
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)?
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?
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?
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?
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.
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.
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.
“Notes: When using WRP and the WinGate Internet Client, or a socks client and server, ALL client computers will immediately become multi-homed”.
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'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.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
Find the entry corresponding to required NIC and edit the mask there.
Alen wrote:Great work, thank you very much.
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?
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!?
Alen wrote:
- What is mapped link and how does it work? I need a simple explanation.
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).
Alen wrote:- Why people change service ports for “internal” proxies? What does it give?
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?
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?
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)
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.
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)!?
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?
Alen wrote:And routes from 2.c) and 2.d) will work properly as (AFAIK) more "narrow" route has higher priority!
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.
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.
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
...
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
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.
Users browsing this forum: adrien and 13 guests