<![CDATA[Qbik New Zealand Limited]]> <![CDATA[Adding a network card with WinGate installed]]> Changing a network card when WinGate is installed on the PC is usually a straight forward process that shouldn’t require any major alterations to WinGate itself.

However,there are several points to note in when dealing with network card installations and WinGate.

  1. Install the Network card per manufacturers instructions making sure you use the most current official drivers.
  2. Once the computer has restarted after the installation, if you open GateKeeper WinGate will probably flash a system message stating that even though a new interface has been detected it cannot be bound to as there are no IP address details.(0.0.0.0) The following Point 3 will be the step taken to rectify this.
  3. Once the card is configured with approriate IP address details, the WinGate engine should be stopped and restarted for WinGate to redetect the interface and determine the appropriate bindings to services etc.
  4. Open GateKeeper and check the Bindings tab to see that the card has been bound to the correct services (as per the WinGate help file).
  5. To check the new adapters status in WinGate, open the Network tab in GateKeeper. At the bottom is the Network Interfaces pane which displays the current status of available network adapters.(Double clicking on a specific interface will bring up its policy configuration.)
Please Note:

For LAN based cards
(Network cards that will be used to connect WinGate to the rest of the LAN.)
  • This interface should be assigned with a static private class IP address (such as 10.0.0.1,172.16.0.1 or 192.168.0.1)
    If used, WinGates DHCP service will then assign addresses to clients in the same range as the private class address that was assigned to the new network card.

    Or alternatively:

  • In the case of Active Directory or similar scenarios where the interface will receive the details from a DHCP server on the network, then the card properties should be left blank (set to "obtain IP details automatically") If this is the case the WinGate DHCP service should also be disabled
For External Internet Connection based cards
(Network cards assigned with Public Ip addresses)
  • WinGate will recognise the difference between private class addressed and Public class addressed network interfaces and automatically bind them to appropriate services etc. To understand more on how WinGate treats Network Interfaces and Private versus Public IP addresses click here.
]]> <![CDATA[Configuring WinGate behind a DSL/Broadband Router]]> When configuring WinGate to access the Internet through a DSL/Broadband router, there are usually several considerations to make, depending on the particular features of the router. With more routers offering their own built in Network Address Translation(NAT) and DHCP services, it can often lead to confusion of how WinGate can work with such solutions.

This article attempts to clarify the most common steps to take when configuring these types of routing solutions with WinGate. As this article is a general overview, individual features of particular routers may vary, and if in doubt users should refer to the documentation of their particular router.

It is common in this scenario that the WinGate machine should have two network cards, one connected to the router, and one which connects it to the rest of the LAN.

Routers with DHCP (Dynamic Host Control Protocol)

If the Router comes with DHCP service it will usually be designed to assign private class IP addresses to computers on the network such as (192.168.*.* or 10.0.0.*.).

However in this case the WinGate server will be the only machine to receive network details from the routers DHCP service. These details will be assigned to the network interface that connects the WinGate machine to the router.

Note: Obviously if you wish to not use the DHCP service of the router to assign network details to the interface on the WinGate machine that it is connected to, then these same details can be applied statically.

In this scenario the second Network interface in the WinGate machine that connects it to the client machines on the LAN, (referred to here as the LAN Interface) should be configured with a static private class IP that is on a different subnet range as to what is issued by the router.

This IP address on the LAN interface of the WinGate server should be in the same address range as used by the client machines on the LAN.

As with other WinGate configurations the client machines will use this static address on the WinGate server for their Gateway and DNS entries in their network properties.

This will allow client machines to direct their Internet connections through the WinGate machine and inturn out through the router. To see an example of a network set up that uses this scenario click here

Routers with Network Address Translation

In the scenario described above, the WinGate server is assigned the IP address 10.0.0.2 on its interface that connects to the router. Its Gateway and DNS properties are automatically set to 10.0.0.1 (the internal Interface of the router) by the Routers DHCP service.

As mentioned earlier if a router provides DHCP then it will generally have built in NAT to provide translation between the routers private IP address range (in this case 10.0.0.*) and the external IP, and the Internet at large.

WinGate has been designed to work in this common situation and it is ofted referred to as being located behind a NAT translated Firewall, or in simple terms NAT behind NAT.

A common query is how does this work with client machines on the LAN who are behind WinGate?

This is the very reason why it was suggested earlier that LAN clients and the LAN interface on the WinGate server be configured with a different private IP address range from what is being used by the router (In our example 192.168.4.*).

Obviously this keeps routing and identification of IP addresses simple and allows for WinGate to offer its own NAT for its LAN clients.

You will also notice that the LAN Interface (IP address 192.168.4.1) on the WinGate server is not assigned a Gateway or DNS entry as the interface that connects to the router does. This is because in basic routing all traffic that is addressed to a location not found on the local subnet is forwarded to the Gateway address specified in the machines network properties.

So in this case all Internet/DNS requests are forwarded to the router (IP address 10.0.0.1) via the interface that connects the WinGate Server to the router.

Other Considerations

  • Router Firewalls
    If the router comes with a built in Firewall then it is important that approriate ports are configured to allow Internet access when dealing with WinGate in this scenario.

  • Ports for Internet applications

    Generally router configuration utilities will allow administrators to open pinholes (ports) in the router's firewall to allow traffic for Internet applications to pass through to the LAN.

    In this scenario because WinGate is handling the Internet access for the LAN, all of these "pinholes" on the router's firewall need to be set to redirect the traffic to the WinGate Server(Ip address). In the example given this address(interface)would be 10.0.0.2. Please refer to the particular router documentation on how to configure these pinholes. ]]> <![CDATA[Configuring WinGate in the Active Directory]]> With the move to Active Directory by more Windows based networks, there are several things that are needed in order to make WinGate work within this type of scenario.

    It is recommended that you read the knowledge base article relating to Active Directory factors that could influence your WinGate Configuration, before attempting to instigate WinGate in the Active Directory. You can read this article by clicking here.

    The following steps outline what is necessary to have WinGate work successfully in an Active Directory environment where WinGate is running on a machine that is not a Domain Controller, and not a (Dynamic) DNS server.

    Please Note the Following:
    • If client machines receive their IP addresses and network details that they require to function in the Active Directory from a DHCP server on the LAN, then this should be MS DHCP server providing these, not the WinGate DHCP service.
    • When setting up WinGate in Active Directory it is recommended that the WinGate machines internal IP details be set statically, and recorded as required in the AD.
    • For WinGate NAT (Network Address Translation) clients to function properly, the MS network DHCP server should be set to give the internal IP of the WinGate machine as the Gateway(Router)option to client machines, as part of its scope settings when issuing Ip addresses.

    Once WinGate is installed on the machine:
    1. Open Gatekeeper
    2. Under the System tab click on the DHCP service
    3. Stop the DHCP service
    4. On the generaltab set the Service Start up to Disabled.
    5. Click OK.
    6. Save changes in GateKeeper.
    7. Open the WinGate Advanced Options that is found under Start Menu\Programs\WinGate Advanced options.
    8. Enter the IP address of the Active Directory DNS server. This is required to prevent DNS Loops occuring between WinGate and the Active Directory DNS server.
    9. Click OK
    (Dynamic) DNS Server configuration

    If the (Dynamic) DNS server is configured to be a root server, it will need to have the Root Forward Lookup zone (entered as a (.) in the DDNS server’s DNS server properties) deleted to allow the forwarders option to be available. ( please refer to Microsoft knowledge base on how to do this.)

    Once this is done, then the option to enter a DNS server will become available under the Forwarders tab in the (Dynamic) DNS server’s DNS server properties.

    Here you should enter the internal IP of the WinGate machine. This will allow client Internet requests from clients to be forwarded by the Dynamic DNS server to be handled by the WinGate machine.

    Once this has been done,then you will need to enter the IP address of the DNS Active Directory server in the DNS server option of the WinGate Advanced Options. These options are found on the start menu under Start Menu\Programs\WinGate Advanced options.

    This is required to prevent DNS loops occuring between WinGate and the Active Directory DNS server.

    (Dynamic) DNS Server running on the SAME machine as WinGate

    For the case where WinGate may be installed on the same machine as the (Dynamic)DNS server then you must disable both DHCP service and DNS service in WinGate. There is no need in this scenario to set the Forwarders option to WinGate IP in the DNS server properties as described previously as they are now on the same machine. ]]> <![CDATA[Configuring Wingate to use Hi-speed Connections ]]> With the increasing popularity of Digital Subscriber Line(DSL) and Broadband/Satellite Internet connections, it can be difficult in understanding the way WinGate will use these types of connections to access the Internet on behalf of its clients.

    WinGate has been designed to utilize most types of connections and treats them just like a network card interface (with the obvious difference that this is considered a Internet connection and so not trusted.) The way that WinGate interacts with these DSL/Broadband connections can be generally classed under two types of set-up.

    These are:

    • Dial on Demand
      Installing the connection hardware on the WinGate server will create a network connection that has its IP address assigned by the ISP every time the connection is used. Some typical examples are USB modems, Dialup DSL/56k modems, some satellite and Cable modem solutions.

    • Online all the time.
      These types of connections are generally only found with Routers or direct Internet connections and there will be a constant public IP address assigned, as this interface is always connected to the Internet.
      (The IP is usually static although depending on ISP practice maybe renewed at regular periods) some typical types are Routers, Frame Relay solutions.
    What is important about these two types of Internet connection methods is the way that WinGate treats and configures the Internet interface.

    Dial on Demand

    With Dial on Demand type connection the modem or Internal card will generally require the users create a Dial up networking connection when it is first installed, just as is the case with an ordinary modem connection.

    On start-up, WinGate has been designed to list all dialup networking connections that are available on the WinGate server, in its Dialer configuration found under the System tab in GateKeeper.

    To utilize this particular DSL broadband connection type do the following:
    1. Open GateKeeper on the WinGate server.
    2. Select the Dialer from the System tab.
    3. On the Dialer Properties dialog, highlight the appropriate Dial up connection entry and click the Properties button below.
    4. On the Connection properties dialog that appears, select the General tab and enter the correct username and password for the connection.
    5. Make sure Enable this connection to be used by WinGate check box is ticked.
    6. Click OK.
    7. Once back to the Dialer Properties general tab make sure the make sure the Connect as required using the connection list check box at the top is ticked.
    8. Click OK
    9. Save changes in GateKeeper
    This will now allow WinGate to utilize this DSL/Broadband connection to access the Internet whenever requested to by a client machine.

    On all the time

    With these types of connections, WinGate will generally use a separate Network card (interface) to connect to the router or directly to the Internet (External IP address) and so treat this interface accordingly.

    To read more about configuring and running WinGate behind a router click here

    In the directly connected scenario where the Network card has an External Public IP address assigned (with appropriate ISP Gateway and DNS servers listed in its IP details) then WinGate will already consider it an access point to the Internet and so utilize it for client requests without any further connection configuration required in GateKeeper.

    To find out more on how WinGate treats Private and Public Ip addresses click here ]]>         <![CDATA[Considerations for WinGate in an Active Directory Environment]]> Active Directory Overview

    When implementing WinGate in an Active Directory (AD) environment there are numerous features of the AD, which will affect the way that WinGate needs to be configured.

    AD requires a DNS (DynamicDNS) server be available to register client IP address details. It can either receive this from a network MS DHCP server when it issues the client an IP address, or it can be configured to receive this information straight from client.

    DDNS servers are also required by clients in the AD to find information about Domain Controllers. When a domain controller is setup correctly it registers specific AD info (thru SVR records) with the MS DDNS server.

    To provide Internet(external) address resolution for clients in the Active Directory, the DDNS server has a Forwarders configuration, which can be set to a specified Internet DNS server that it will refer to for DNS requests that are outside of the domain that it is responsible for.

    Client workstations will use the DDNS server for the Domain requests for their AD domain, and any Internet requests will be sent by the DDNS server to the Internet DNS server specified in the forward lookup configuration.

    Active Directory and WinGate

    When WinGate is being used in the AD environment the internal Network Interface address of the WinGate server should be listed on the Forwarders tab on the DDNS server properties. This way all of the clients Internet requests will be forwarded to the WinGate Server and of course Internet requests fulfilled from there.

    Unfortunately when MS DDNS is first installed a scenario can arise where it is unable to find any other DNS servers, and so it sets itself as the Root server for all Domain Name Requests inturn effectively disabling the forwarders option. If this is how the DDNS is configured in your AD then you will need to read from MS Support how to enable Forward lookups on a DDNS server.

    You can find this here

    It should be noted that if the DDNS server is running on the same machine as WinGate, WinGates DNS service should be disabled. (As per Knowledge Base here). 

    Due to the important role the DHCP server plays in making Active Directory work, it is also recommended that the DHCP service in WinGate be disabled so not to interfere with AD network operations.

    A further note on DHCP. If WinGate clients wish to use NAT(Network Address Translation) to access the Internet through WinGate and are receiving their Ip details from a network DHCP server, then the Gateway address they receive from the DHCP server should be that of the LAN ip address of the WinGate machine.This Commonly referred to as the Router(Gateway) option in DHCP.
    ]]>         <![CDATA[How to disable the Windows Firewall service]]>
    In order to ensure that the Windows Firewall is turned of and remains off, it's best to disable the Windows Firewall service.

    1. Open the 'Run...' prompt from your Start menu

    2. Type 'services.msc' into the Run prompt and click 'OK'

    3. Find and double-click on 'Windows Firewall/Internet Connection Sharing (ICS)' from the list of services

    4. Change the services 'Startup type:' to 'Disabled'

    5. Click 'Stop'

    6. Click 'OK'

    The Windows Firewall is now permanently disabled, and can not be silently restarted by Windows without your knowledge.]]>         <![CDATA[NAT: Overview]]> Network Address Translation protocol or NAT as it is more commonly termed, is a technology that has been implemented for use by WinGate's Extended Networking Services, as a client connectivity method in WinGate.

    In simple terms NAT works by taking any data destined for the Internet from the client machine (regardless of the application it is using) and sends it to a Gateway server such as WinGate.

    WinGate will take this data packet, store the details of what client machine it came from, and then re-append the address details of the packet with the details of its own external location so that it can preform the Internet request on behalf of the client.

    When the response data comes back in from the Internet, the WinGate machine “translates” the address back into the private IP address of the original client machine and forwards the data back to the appropriate client.

    The concept of NAT technology use in proxy server solutions, was developed around the realisation that the Internet, using the current Ip version 4 addressing scheme, would run out of IP addresses to allocate to every machine that needed to access the Internet.

    NAT was offered as one solution to this dilemma by creating a proxy server solution, which could easily handle the translation between Private and Public addresses. This meant that large networks needing Internet access could use private IP addresses and only require to have one external IP address to the Internet.

    To read more about private versus public Ip addresses and how they are used in WinGate you can click here.

    WinGate implemented NAT technology as part of its Extended Networking service and it offers the following benefits:

    • Little client configuration required, no additional software needed.
    • Works at a packet level so there is greater performance with through put and speed
    • Because it works at packet level all tcp/ip internet applications on the client machine will use it. Applications don’t have to be configured individually, such as with the straight proxy method of connection where a proxy server is specified on an application by application basis.
    • Hides Internal users from direct contact with the Internet at large, reducing the security risk
    NAT does have several disadvantages with its use:
    • Client machines have no way of identifying themselves individually on the Internet if required.
    • Inability of Internet application servers running behind a NAT server to receive communications on a predefined port number.
    • Can be a problem in some instances where an Internet server only allow 1 connection from a particular IP at anyone time. If multiple clients attempt to connect to the server from behind NAT then only one will be allowed to connect as they will all appear to be connecting from the same external IP address.(A common problem with some Internet Gaming server scenarios).
    WinGate’s implementation of NAT has expanded its functionality through the use of transparent redirection, which essentially takes all client traffic that is connecting via NAT and redirects it through the appropriate Proxy service to take advantage of the features only offered by the Proxy.]]>         <![CDATA[Private versus Public IP addresses]]> WinGate is a proxy server and as such handles Internet requests on behalf of clients on the local area network. Because these clients will never directly access the Internet, they are assigned (either statically or through WinGate’s DHCP) an IP address called a private class IP address.

    WinGate will obviously be used as a proxy for all of the clients Internet requests and so only one Public (external) IP address (the Internet connection/Interface on the WinGate Server) is required by the entire LAN to reach the Internet.

    According to RFC 1597 there are three sets of private class IP address ranges that can be used when addressing machines on the LAN, these are:

  • 10.0.0.0 through 10.255.255.255
  • 172.16.0.0 through 172.31.255.255
  • 192.168.0.0 through 192.168.255.255

    What is so special about private class IP’s is that they are often called non-routable IP’s; if a user attempts to use this address directly on the Internet it will not be forwarded by routers on the Internet.

    WinGate handles these IP address ranges in accordance with RFC 1597 and so will be able to distinguish between whether an IP is private or public. e.g IP address 192.168.4.55 would be deemed to be private.

    When the WinGate engine first starts it scans all of its available Network interfaces for IP addresses. After determining whether these addresses are Public or Private addresses it will determine the usage and therefore which services they should be bound to, whether they should be firewalled, etc. This in turn helps WinGate determine which interface links WinGate to the LAN and which interface links it to the Internet.

    This is an extremely important point to understand because in order for WinGate to function correctly it must determine whether an IP address/Network Interface is deemed to be Private or Public, Trusted versus Untrusted.

    You can check the usage of the Network Interfaces found on the WinGate Server by selecting the Network tab in GateKeeper. The adapter usage will be shows as Internal or External.

    Usage column

    Of course these settings can be overwritten, so that an Public (external) IP can be trusted or considered local, however administrators should be aware of the possible security and configuration problems that may arise from this type of use.

    To change the adapter usage double click the adapter, this will open a properties dialogue box. Change the setting from "Auto Detect" to the appropriate setting. ]]> <![CDATA[Using Ping to test TCP/IP ]]> Testing TCP/IP connectivity with Ping

    Ping is a utility included with all current versions of Windows and can be used to test the connectivity between computers on the LAN, and the Internet. It does so by sending tiny packets (called ECHO_REQUEST ) packets to the target machine, who will reply back with ECHO_REPLY packets, so that the pinging machine can determine the "distance" (in time)to the target machine. For exact technical details/ settings of the Ping utility please refer to Microsoft documentation.

    With regards to WinGate functionality, Ping is extremely useful in making sure that clients can communicate effectively over the LAN to the WinGate Server, and for the WinGate server to test connectivity to locations on the Internet. It is also used most effectively in WinGate VPN scenarios to ensure that routing has been configured properly.

    Outlined below are the main scenarios in which Ping can be used to test the functionality of WinGate:

    Test Client TCP/IP configuration is setup correctly:

    1. From the Cmd line type: Ping 127.0.0.1 (which is the loopback address used to identify a machine to itself, often referred to as local host)
      If the ping is successful (and inturn TCP/IP setup correctly) you should see:

      Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
      Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
      Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
      Reply from 127.0.0.1: bytes=32 time<10ms TTL=128

    2. Next, you should use Ping to check that the client can communicate with the WinGate Server:
    3. From the Cmd line type: Ping X.X.X.X (Where X.X.X.X is the internal address of the WinGate Server e.g. 192.168.0.1)
      If the ping is successful then you have established that TCP/IP communication is working correctly between the two machines. You should see:

      Reply from 192.168.0.1: bytes=32 time<10ms TTL=128
      Reply from 192.168.0.1: bytes=32 time<10ms TTL=128
      Reply from 192.168.0.1: bytes=32 time<10ms TTL=128
      Reply from 192.168.0.1: bytes=32 time<10ms TTL=128

    It should be noted that Ping can be used in conjunction with Domain names (eg. Qbik.com) to verify connectivity between the WinGate Server and external sites. This is where the IP address is simply replaced with the Domain Name when pinging. Because ping will always return the result as a reply from an IP address, it can also be helpful in determining that DNS resolution is working correctly.

    Eg Ping www.somewhere.com

    Reply from 201.167.0.1: bytes=32 time<10ms TTL=128
    Reply from 201.167.0.1: bytes=32 time<10ms TTL=128
    Reply from 201.167.0.1: bytes=32 time<10ms TTL=128
    Reply from 201.167.0.1: bytes=32 time<10ms TTL=128
    ]]>