WinGate Engine

WinGate Engine

In previous versions the WinGate Engine held and operated a large part of the functionality in WinGate. In WinGate 7 the WinGate Engine was rebuilt using a modular architecture. Components can be loaded, and unloaded, and provide their functionality to WinGate (and other components). The WinGate Engine organizes and manages these components through the WinGate Schema. This is where components register objects and information for WinGate and other components to use.

ENS

ENS

WinGate still provides an ENS configuration to manage network security in WinGate, including the other extended networking services (NAT, Firewall, Bandwidth control, Monitoring for Gateways) provided by the ENS driver.

GateKeeper

WinGate Management

The WinGate Management console replaces the Gatekeeper user interface from previous versions. Built with a completely new user interface, it is an intuitive step up in the management of WinGate. It features a simple navigation tree to provide easy access to component management panels, so you can access the appropriate WinGate configuration when you need.

WinGate Management has redesigned the way the interface is used to manage WinGate. In previous versions, Gatekeeper could only provide limited management capabilities when accessing the WinGate Engine via a remote connection. In WinGate 7 onwards you can access a remote WinGate installation by simply configuring the Remote Control service on the remote WinGate installation to listen for WinGate Management connections as usual. Extra configuration (such as having to map drives etc.) is no longer required.

WinGate System and Proxy Services / WinGate services

Services

Due to WinGates new modular architecture, services are now largely optional. WinGate no longer installs a large range of system and proxy services by default. When components are loaded, they will often install services to assist with their functionality. WinGate also offers a range of installable network services that will listen for, and respond to clients requests on a chosen network interface. This includes the familiar system services DNS, and DHCP, SMTP Server etc., and proxy services like the WWW, FTP, and POP3 Proxy.

WinGate installs the WWW Proxy Server by default to provide proxy functionality to clients after installation. WinGate still provides the Transparent proxy feature, but it has been renamed to Intercepting (Intercepting Proxy) and now has its own configuration within each applicable service.

Network services still have a Bindings configuration to manage which network interface(s) will be used to listen for requests.

All services can be managed and installed (if available) from the new Services panel, located at Control Panel > Services in the WinGate Management console.

System and Service policies / Policy System

Policy system

WinGate introduces a completely new policy system for WinGate 7 onwards. WinGate is built around an event based model which means a large part of its functionality is derived from responding to events. The new Policy system allows you to create policies based on events that can take place in WinGate. This means that a policy will always be processed (implemented) on the occurrence of a specified event.

In earlier versions of WinGate, you could select filters and criterion for policy creation and content. From WinGate 7 onwards the content of a policy is built around a flow chart of steps that can be taken when the event occurs. The Policy system has a range of powerful tools that you can use to create the steps of the flow chart. These can either be decision type steps that evaluate some data (in order to choose which path to follow) or a step where some kind of action will be performed (e.g. authenticating or disconnecting users, stopping a service, or sending an email).

The concept of system and service policies being based on a specific system or proxy service has been removed. WinGate policies can be easily created to respond to a list of events registered by WinGate services and components. This allows you to choose which component (the source of the event) you want to control with policies. This can be useful for controlling users access. You can create a policy based on a client connection type event registered by any of the WinGate proxy services that are installed.

Scheduler

Scheduled Events

The Scheduler system has now been replaced with the Scheduled Events system. Since WinGate is an events driven application, the new Scheduled Events system allows you to create a non-descript event that will take place at a schedule you require. These scheduled events, like other events from components in WinGate, are registered with the WinGate Events system, and made available to the various event processing systems to respond to whenever they take place (according to their schedule). This could be to trigger a policy (based on the scheduled event) or configure a WinGate script event processor to run a script whenever it takes place.

WinGate Mail

WinGate Mail

• SMTP Server / SMTP Delivery service

  In previous versions of WinGate, the SMTP Server was installed to provide mail delivery services for WinGate users who need to send mail through WinGate. In WinGate 7 we released a new SMTP Delivery service to provide management, and operation of the mail delivery queue. This new service also allows several WinGate components to send emails from inside of WinGate (if configured to do so).

  The WinGate SMTP Server now is used to provide reception of mail from users and sources outside of WinGate so it can be placed in the delivery queue for processing by the SMTP Delivery service.

• POP3 Server

  The POP3 Server in previous WinGate versions provided collection services for users wanting to access their WinGate mailboxes. From WinGate 7 onwards the POP3 Server is only required to receive clients who are attempting to collect mail from their WinGate mailboxes using the POP3 Protocol.

  The old POP3 Server also provided handover to the POP3 Proxy service when it received clients proxy requests for retrieval of mail from remote POP3 locations. In WinGate 7 the POP3 proxy handover feature was removed, and so now you will need to install the POP3 Proxy service to facilitate POP3 Proxy clients.

  WinGate Mail also now has a separate POP3 Collection service to provide the periodic collection of mail from specified remote POP3 mailbox accounts. These can be redistributed to local (or remote) mailboxes by the SMTP Delivery service.

• Mailboxes

  WinGate now stores mailboxes in a volume for easy management and sorting. Each mailbox is stored in the IMAP4 mailbox format, so there is now no distinction between a POP3 and an IMAP4 mailbox for users. This is determined primarily by the email protocol they use to connect and access mail from their WinGate mailbox. In the case of clients who use POP3, they will only have access to their inbox folder of their WinGate mailbox.

• Domains

  WinGate now displays all domain handlers that have been created to handle email addressed to a specific domain, on the new Domains tab. Each domain handler is now referred to as a domain rule. You can create associated email address handlers, and email address list handlers for the domain from this tab. WinGate 7 removed the addition of all local mailboxes as predesignated address handlers as in previous versions.

Logging

Logging system

The Logfile server which was available in earlier versions has been replaced with a completely new logging system. The Logging system allows you to tailor what WinGate will log and how it will construct each log file. Components can register themselves as sources of logging information, and you can have them log information to either a global log file, their own log file, or to another log file if needed. You also can set the amount of information they supply to a log based on several different levels of information.

WinGate also provides usage logs for log sources that can provide traffic and usage information. Usage logs are built in a flexible W3C compatible format so they can be read by 3rd party W3C logging analyzers if required.

User Database

User database

From WinGate 7 onwards you have the option of three different types of user database for user control and management in WinGate. It retains the WinGate user database which now offers NTLM authentication support. There is also the new Windows Users and Groups Connector which allows you to employ the user database on the Windows operating system where WinGate is installed.

Alternatively, WinGate now has a separate Active Directory user database connector, so you can easily configure WinGate to use an Active Directory user database when located in a Windows Active Directory environment.

Cache

HTTP Cache

WinGate has a new HTTP Cache to provide for storage and retrieval of commonly requested HTTP files by WinGate clients. This provides much quicker processing times for cache requests than performing a search on the HTTP Cache volume itself.

For easy management of the cache, you can create multiple volumes on local or UNC drives and manage their storage independently. The HTTP Cache also allows you to use specify cache rules to control how an what resources are cached.

WinGate 8: WinGate 8 uses a new, proprietary cache index system that provides greater performance and flexibility than WinGate 7's database cache.

WinGate 7: WinGate 7 uses a database to store the cache index. By default it will use a MS Access database but you can configure WinGate to use any database that supports ODBC.

Winsock Redirector Service

Winsock Redirector Service

The Winsock Redirector Service (WRS) is no longer installed by default.

It should be noted that the WinGate Internet Client is only installable to certain Windows operating systems (Windows 2000, XP, Server2003) and so this limits the scope of clients that can use the WRS.

However the WRS now provides application control for the new Policy system to use when processing a policy. This means that when a policy is made to process a connection event by a WinGate Internet Client application through the WRS, it can be made to handle that type of application in a special way (e.g. stopping it from making a connection to the Internet, allowing it through etc.)