With WinGate 6.0, Qbik introduced a new way of dealing with service bindings.
In WinGate and many other server applications, a binding is an association between a network connection point (in many cases the combination of an IP address and a port number) and a network service (e.g. a mail server or web proxy).
This defines the interface over which a server process will provide service to clients. It stands to reason therefore that in order for a service to be accessible to a client, it must be "bound" to an interface that is accessible to the client computer.
Bindings allow client PCs to connect to network services, and allow the administrator to specify which service will respond to connections on which interfaces and ports. Additionally, there are security issues associated with providing remote access to services. Bindings therefore need to be considered a point of security control.
This basic picture is made more complicated when considering hardware and more recent operating systems (specifically Windows 2000 and later). Network connections may involve NICs (Network Interface Cards), modems and wireless adapters. Ultimately, these items may be considered to provide one or more IP addresses to bind to, but each of them also brings different behaviours that can affect the operation of WinGate. An unpleasant example of this involves laptop computers on wireless LANs. It is not uncommon for the connection between the laptop and the wireless network to be momentarily "lost", resulting in the disabling of the interface by the operating system, when a laptop is moving from one place to another. Also USB-based adapters can be plugged in at any time. Many adapters can also change their IP address without notice, thereby invalidating service bindings. In previous versions of WinGate, and in many other network software applications (e.g. IIS even), this means service may be lost, or require a restart or manual reconfiguration of a service.
To cope with these and other technical issues, Qbik introduced Dynamic Binding in WinGate. WinGate now contains software that monitors network hardware and reports any changes. There is also functionality in WinGate devoted to responding to these changes by creating and removing service bindings, and automatically opening and closing firewall holes as appropriate. The exact behaviour is determined by a per-service binding policies. Immediately after installation these policies are set to useful and safe defaults. A sophisticated user-interface is provided for finer control beyond these defaults.
The major benefits are as follows:
This combination of benefits is akin to the technology known as "plug-and-play". In effect, WinGate is now the first "plug-and-play" web proxy. Refer to the final section for some examples of installations.
The nature of dynamic systems (that which separates them from static systems) is that they respond to changes in their surroundings.
As the name suggests, WinGate's Dynamic Binding system is a system which automatically responds to changes which affect the service bindings. Response is initiated either by hardware notifications, changes to hardware operating parameters (such as IP address) or configuration changes made in WinGate by the user. The response to all of these is very similar.
Given some change has occurred, the first step taken is to calculate all the bindings that should exist in WinGate.
This calculation involves the matching of individual per-service binding policies to detected available network adapters and their IP addresses. A binding policy is defined by a match criteria (how to match) and match parameters (what to match to). If a service's binding policy matches an available interface and IP address, then the resultant bindings and their associated parameters are added to the list of "bindings that should exist". This snapshot list is then compared with the current set of all existing service bindings to determine which (if any) bindings should be created or destroyed.
Firstly, all bindings to be deleted are stopped and removed from the system. This avoids possible collision scenarios and reduces the "resource peak" that would otherwise occur. Secondly, any new bindings are created and changes to binding parameters are applied.
Lastly the WinGate driver is advised of all relevant changes to the set of network services. The automation of service bindings creation would not be complete without automated (and matching) configuration of the WinGate Firewall. Full integration results in the appropriate opening and closing of firewall ports.
All changes are broadcast to connected GateKeepers.
As a simple example, consider a WWW proxy server in WinGate. It would be quite reasonable to provide this service for clients on an internal LAN. Previous versions of WinGate, and most other web proxy products require the administrator to manually specify the particular IP address to bind to. This is a simple approach, but a slightly flawed one. Firstly there is the basic requirement to create the proper configuration. This is information that is site specific, i.e. it cannot be configured into WinGate itself. Secondly this creates the ongoing need to update that configuration to "keep in step" with changes to the network. These tasks are simple but can be error-prone. The unpleasant way of finding out that a configuration update is required, is by finding that network service has been disrupted.
This is one of the fundamental benefits of Dynamic Binding. Specification of adapter and IP address can be a more general and intuitive expression of desired policy, rather than explicit information. By providing this form of matching, it is possible to configure the automatic creation of network services according to the apparent (and changing) configuration of the network.
One of the key parameters of an adapter, which contributes to how it is used in dynamic bindings, is the adapter usage. This is a function of what sort of network the adapter is connected to (internal, external, or DMZ). WinGate automatically makes an initial judgment about the most likely usage of an adapter based on the IP addresses it may have allocated to it. This means that the deemed usage of an adapter may change if the IP address of the adapter changes from a public IP address to a private IP address, this may happen for instance if you plug an adapter into a different network. The administrator may also manually specify how the adapter is being used if due to local network configuration WinGate makes the wrong assumption (e.g. if you are using public IP addresses on your LAN).
In our example of the WWW proxy, we simply set the adapter specification policy to "Any internal adapter". Alternative options are "Any external adapter", "Any adapter" (at al ) or a specific adapter may be chosen (in which case you may also select any or one of any number of specific IP addresses assigned to that adapter). This creates a configuration that is correct at time of installation and also stays correct over time, i.e. it is not affected by network changes.
By virtue of the criteria, a set of binding policies may match a large number of adapter and address combinations, resulting in a large number of bindings. With this power of expression comes a related responsibility. This is directly reflected in aspects of binding policies. Labels such as "internal" and "external" should evoke a sense of consequence when creating or modifying these policies. The set of default policies is designed to be useful but conservative.
The first visible evidence of Dynamic Binding occurs in the Network Panel of the Gatekeeper application. A new pane called "Network Connections" has been added at the bottom of the main, right-hand panel. This is a view of the latest adapter information and is the information that WinGate uses in its Dynamic Binding processing. An example screen-shot appears below:
The view indicates there are two adapters in the PC, both in good working order. General descriptive information is included. The crucial information for Dynamic Binding is a unique identity (not shown) associated with each adapter, the list of associated IP addresses and the usage. As described previously, these are the primary inputs to the matching process.
Double-click an adapter and a properties dialog is shown, as below:
This provides the administrator with the ability to override the default adapter usage, otherwise assumed by WinGate as described above.
To access binding policies for configuration, select a service and then select Bindings in the Configuration pane. The resulting dialog, for the POP3 server, is shown below:
Binding policies are listed in the lower right. The criteria appears as descriptive text and the policy may be enabled or disabled. Pressing the "Apply" button should immediately show any resulting effect on the bindings used by the service. The port field shows that for this policy, the port is inherited from the General configuration. This means if you change the port number of the service (in the General tab) then the bindings will be reassigned to that new port number. In the upper right hand list we finally see the bindings created by the policies shown. The bindings indicate that the POP3 Server will be available on port 110 to clients connected to the External interface, and these clients may use TLS to negotiate a secure connection. Additionally the second binding shows that the POP3 server will be available on port 995 to clients connected to the External interface, but requiring that the client applications negotiate an SSL connection.
The details of adding or editing a binding policy are very similar. Pushing the Add button results in the following dialog:
A single, central tree control is all that is needed to represent the binding criteria. By simply selecting an entry in this tree, a criteria is set. Internally a criteria is the combination of adapter specification and IP address specification. This dialog does all the work of representing all possible variations as a tree. It also displays by way of the icon used, the current status of the interfaces shown. The text field at the bottom of the dialog shows a plain text description of what this policy will do. Lastly, the particular port used by a resulting binding can be entered as an override, and where supported by the service, SSL or TLS options may be enabled or disabled, and the certificate to be used for these connections may be selected. This allows the user to configure different SSL certificates on each interface to suit specific requirements.
In summary, WinGate 6.0 allows the user more flexibility, and a more natural way of expressing the desired behaviour of WinGate, resulting in a more reliable configuration, which can adapt to changes in the network without user intervention.
©2008 Qbik New Zealand Limited
WinGate is a registered Trade Mark of Qbik IP Management Limited. All other trademarks and copyrights are owned by their respective owners.