Can the Wingate server be part of an AD Domain

[Softbreeze]

I have just started looking at Wingate and have high hopes that it will work for me. I have an active directory domain on one side of a Linksys Firewall Router and a cable modem on the other. I'm looking at replacing the Linksys router with a wingate server. My question is, Can the Wingate server be joined to my AD domain? All my servers have static IP addresses and are part of my AD domain. Of course the DNS is integrated into AD. All DNS requests are forwarded to the Linksys router.

Thanks in advance
Ken McClain

[Softbreeze]

I've thought about this a little more and I believe it should NOT be part of the AD Domain. I'm trying to replace a router which is not part of the domain. The less it touches the AD domain the better.

[logan]

I've thought about this a little more and I believe it should NOT be part of the AD Domain.

Hi Ken,

The current WinGate 6 and the upcoming WinGate 7 both easily integrate into AD environments so that's no problem at all. In either case, the computer that you will install WinGate on must be a member of the domain for WinGate to view the domains user database and authenticate users against the domain.

The advantage of WinGate 7 is that it's designed to run and work under a simple pleb domain user, whereas WinGate 6 requires that the engine log on under the domain administrator account. This is because WinGate 6 was still supporting Windows NT for a while so it needed to maintain support for NT domains as well. Now that support for NT has been deprecated, WinGate 7 is able to use a much better method of integrating with the domain.

WinGate 7 is still under development, but there are quite a few people testing the closed beta right now. If you'd like to try the beta, let us know and either Adrien or myself will send you the latest build.

[Softbreeze]

Thanks for the quick reply. I think I'll try the current version first but will keep my options open on the beta.

Ken

[logan]

You're most welcome,

There's a section of the help file dedicated to integrating with AD with walkthroughs for setting it up. I also wrote a tutorial a few years ago that never got released to public. I've included it below in case you find it useful.

_________________________


Synchronising with an Active Directory Domain Controller

This tutorial covers the steps involved with integrating WinGate into an Active Directory network environment, where the Active Directory is being hosted on a separate server within the network. WinGate will synchronise it's user database with the Active Directory, allowing you to perform NTLM authentication through the Domain Controller.


This tutorial assumes that:

• Your WinGate server has two network adaptors. One for the internet connection, and one for the local area network.
• The Active Directory server has been setup and the client computers are joined to the domain.
• The WinGate computer is a member of the domain.
• The WinGate computer has WinGate installed and configured to use the WinGate user database, or the local Windows user database.

Networking Pre-requisites

Before synchronising WinGate with the remote Active Directory server, double check that the networking requirements are met, setup and ready to go.


1) Check that the IP configuration of the WinGate computer is setup correctly. The internal network adaptors Primary DNS should be pointing to the Active Directory DNS server as this is required for the computer to login and communcate with the Domain Controller. The external network adaptor that is facing the internet should have at least one DNS server set that can resolve internet domain names.

Each network adaptor should only have gateways and DNS servers specified that can be accessed from that adaptor. It is a common mistake to configure internet DNS servers on internal network adaptors, and likewise, internal Active Directory DNS servers on external network adaptors.

Your IP configuration should look a little like the diagram below. Keep in mind that your network may have different IP ranges and addresses for the local network and the internet connection, but the basic concept should still be the same.

Adsynch.GIF (13.53 KiB) Viewed 9124 times

2) The WinGate computer needs to be a part of the domain for WinGate to communicate with the domain controller, so make sure that the computer has been joined to the domain. If the computer wasn't joined to the domain when you attempt to synchronise the user database, WinGate would not be able to retrieve the remote user list or check NTLM passwords against the Active Directory server.


3) Since your client computers need to have their DNS settings pointing to the Active Directory DNS server, the server will need to be able to resolve internet domain names for the client computers. You can specify Internet DNS servers in the forwarders tab of your DNS servers properties. For this tutorial, I want you to add only the WinGate computer to the forwarders tab. Your client computers may start to experience problems connecting to the internet, but this is expected and I will explain why this happens and how to resolve the problem later.


Adding an Internet DNS server to the Forwarders tab:

1. (Windows) Start -> Programs -> Administrative Tools -> DNS
2. Right-click on your server and open the properties
3. Goto the "Forwarders" tab
4. Add the WinGate computers IP address to the "Selected domain's forwarder IP address list"
5. Click OK to finalise the change

If your DNS server has a root server configured, then you won't be able to use the forwarders tab. You will need to remove the root server and restart the DNS service to re-enable the forwarders tab.


Synchronising with the remote user database

The network should now be ready for WinGate to synchronise with the Active Directory, however, there is still one more thing to do before you can flick the synchronise switch. The WinGate service needs to freely communicate with the domain controller, so you will need to make it log on using an account from the 'Domain Administrators' user group on the Active Directory, rather than the local system service account. It is recommended that you create a new user on the Active Directory specifically for the WinGate service.


Create a new user in the Active Directory, call it WinGate (or something to that effect) and add it to the 'Domain Administrators' group. For security reasons, you should disallow logon through terminal services for this user.

Now make WinGate login using this account.

• Start -> Run -> Services.msc
• Double-click on the “Qbik WinGate Engine” entry.
• Go to the Log On tab of the properties window that just appeared.
• Select “This account”, and enter the username and password of the user that you just created.
• Restart the WinGate engine.

Now that WinGate can freely communicate with the domain, it can synchronise with the Active directory.

• Gatekeeper -> Users tab -> Database Options
• Select “Use the Operating System (Windows) user database” if it isn't already, then select “Use Remote user database ( Domain Controller / Active Directory )”.
• Enter the domain controller that you want WinGate to synchronise with. This is just a simple network path, e.g. \\server01.

That's it. Click Synchronise now to grab the remote user database, and then click OK. Open up your users list and you should now see your Active Directory user list, rather than the WinGate userlist or the local Windows user list.

Now that WinGate is synchronised with the remote user database, you should select your synchronisation options. In most scenarios, you can simply select “Synchronize entire database when WinGate starts” and “Synchronise individual users when they log in for the first time” to obtain a regular and failsafe update of the remote userlist, but these settings are completely up to you.


Extra Considerations

DNS Loops

Earlier in the turorial, I got you to set the forwarders tab of the ADDNS server to point to the WinGate computer. No doubt you have probably been experiencing difficulty with your internet connection since doing that. This configuration would have caused what's called a "DNS Loop" in your network.

A DNS Loop effectively describes a situation where a DNS request bounces infinitely between two DNS servers. Each server thinks that the other server will be able to resolve the domain name, and so the loop begins. The loop will only end if WinGate decides to try an internet DNS server for a change, or a network cable is unplugged from either server, timing the active requests out.

There are two ways to fix a DNS loop. You can either set an internet DNS server in the ADDNS forwarders tab, or you can tell WinGate not to send internet DNS requests to the ADDNS server. You already know how to modify the forwarders tab, so I have only covered the WinGate solution.

• (Windows) Start -> Programs -> WinGate -> Advanced Options -> DNS Servers
• Enter the IP address of the Active Directory server and add it to the list.

That's it. That's all you need to do. The DNS loop should cease as soon as you click OK.


Synchronising when installed on the Active Directory server

Synchronising with an Active Directory when WinGate itself is installed on the AD server is much simpler than synchronising with a remote Domain Controller. All you need to do in this situation is configure WinGate to use the local Windows user database. Since the local Windows user database is also the Active Directory user database everything should work immediately. The only thing you will need to do is disable a couple of services in WinGate.

Since the Active Directory is already running a DNS server for the client computers, you will need to disable the DNS server in WinGate. You may be running a DHCP server on your domain aswell. In this situation, you should also disable the DHCP server in WinGate.

[rboynton]

Well written, Logan. One small thing you might want to change though. Under the client computers IP range, you need to show that "254" is the end of the IP range available. The "255" address is only used for broadcast, and is not recognized as a valid IP that can be assigned to a NIC.

[Softbreeze]

Perfect!!!
Last night I set up wingate in my environment (before seeing this document) and got it working. However I didn't get to the synchronization step. I did make one mistake during install. I didn't configure it to use a user database. I believe I tried but I couldn't get past the login credential. I'll try reinstalling it tonight.

By the way my AD domain controller is actually a virtual machine under ESX 4.1. I have WinGate running on a PC running XP + SP3. Since my ESX server has multiple NICs in it, I was wondering if any testing has been done with WinGate running in a VM? I can see issues with having a firewall as a VM but In my home (software development) environment I could probably get away with it. Currently I have my DC VM boot first before any other server or VM is booted.I guess I could put a firewall VM before the DC in the boot order. The problem I see with this is that if the Gatekeeper service requires authentication and it starts before the DC that could present a login problem for the service.

I currently am using the trial version, but after last nights testing I will definately be purchasing Wingate. I still have the port forwarding and PureSight testing to complete though.

Thanks
Ken

[rboynton]

Sure! I am using Wingate with the free VMWare server product. I also use ESX 4.1 with another client running 4 hosts.

The only tricky part is to have one available NIC on each host (the same NIC) and dedicate it to the internet connection by setting up a new VSwitch on each host. You then take each of those host NIC cables and run them to a switch with a VLAN which includes the internet connection. The reason you dedicate the same NIC on each host for that purpose is so things will continue working when you use VMotion, HA, or DRS. If you only have one host, then simply take the extra host NIC and dedicate it to the virtual machine running Wingate. It works very nicely, I might add!

Last edited by rboynton on Nov 18 10 4:16 pm, edited 1 time in total.

[logan]

Well written, Logan. One small thing you might want to change though. Under the client computers IP range, you need to show that "254" is the end of the IP range available. The "255" address is only used for broadcast, and is not recognized as a valid IP that can be assigned to a NIC.

Well spotted! Fixed now.

I didn't configure it to use a user database. I believe I tried but I couldn't get past the login credential. I'll try reinstalling it tonight.

If you did not select Windows User Database during the installation, WinGate will be using it's own user database.

Here's the trap. The default username and password that you need to login with is Administrator with a blank password (in other words, just press OK at the login prompt for the first time). You will then be prompted to set a password for the administrator account.

If you selected the Windows User Database, then WinGate will be using the local Windows user database and you'll need to login with the local Administrator account (not a domain admin).

I was wondering if any testing has been done with WinGate running in a VM?

Plenty of testing has been done actually. I've used most of the virtual machine technologies (VMWare Server/Workstation, ESX, Xen, KVM, Hyper-V, Virtual-PC, Virtual-Server) simply out of curiosity. WinGate worked fine on all of them. I've sketched up a diagram to show you my usual network layout to host WinGate in a virtual environment. Excuse the quality :).

WinGate in a Virtual Environment.PNG (13.7 KiB) Viewed 9112 times

• With two network adapters on the host computer, I connect one to the Internet (router/modem/whatever), and the other to the local network.
• On the host OS, I do not assign an IP config for the external adapter so that a) the host cannot connect directly to the internet and b) the internet cannot connect directly to the host. Just a wise precaution I think.
• I set up the WinGate VM with two bridged adapters for External and Internal adapters on the host. In the WinGate VM, the external adapter connects to the modem and the internal adapter gets a static IP address.
• For all the other VM's, I set up just one bridged adapter to the internal network and set each of the VM's to connect to the internal adapter of the WinGate VM.
• Also I set the internal adapter of the host OS to connect through the WinGate VM as well.

That's basically it. You should be able to see that all internet traffic ends up going through the WinGate VM anyway, so this is as good as having a separate physical machine to host WinGate on.

As for what order to start the VM's in, I'd say start the domain server, and then when that's running, start the WinGate VM and any other VM's with static IP configs.
Lastly, and assuming that WinGate is serving DHCP, start any VMs that will rely on DHCP for their IPconfig. However if your domain server is doing DHCP for the network, then boot WinGate and all other VMs at the same time after the domain server has started.

[logan]

^^ I didn't notice that you had already replied Rick :)

I'll leave this here anyway

[Softbreeze]

Thanks to all who responded.
This is the best forum I've used.