In this page you find:
The HTTP proxy employed in the UTM is squid, whose primary ability is to cache web requests to speed up future requests of the same page, though it has many more functionalities that allows its seamless integration with the other services described in the remainder of this section. The HTTP proxy settings page is composed of a number of tabs that organise all available options: Settings (opened by default), Zones, Access Policy, Authentication, Web Filter, and HTTPS Proxy.
A click on the Enable the HTTP Proxy grey switch starts the HTTP proxy.
Transparent and Non Transparent Proxy.
A transparent proxy is a proxy system combined with a gateway: Besides retrieving and caching resources, a transparent proxy allows to carry out many useful operations on the web page or resource that the client is requesting: To filter its contents, to scan it and look for viruses, or even to block information, combining different services running on the gateway. Moreover, all these activities are accomplished without requiring the user to configure in any way the client she is using.
Non-transparent proxies on the contrary, rely on the collaboration of the client to be used (e.g., configuring the proxy settings on the web browser), requiring that the user specify by hand the location of the proxy in the setting of the browser, or she will not be able to access the Internet.
The configuration of a transparent proxy is explained in this tutorial Transparent HTTP Proxy Basic Setup.
In this panel there are some global configuration options for the proxy services:
- Port used by proxy
The TCP port on which the proxy server is listening for connections, which defaults to 8080.
- Error Language
The language in which error messages are displayed, which defaults to the one chosen in.
- Visible Hostname used by proxy
The hostname assumed by the proxy server, also reported at the bottom of error messages.
- Email used for notification
The email address shown by the proxy server in error messages.
- Maximum incoming download size (KB)
The limit for HTTP file downloads. 0 means unlimited.
- Maximum outgoing download size (KB)
The limit for HTTP file uploads (e.g., those used by HTML forms with file uploads). 0 means unlimited.
- Keep the original source IP address in not-transparent mode.
This option affects all the zones that are configured as non-transparent mode. When ticked, all the packets coming from the proxy will keep some information of the requester (client): Its IP address and the zone/interface from which the traffic originated.
Configuration option for the ports the clients are allowed to use when browsing:
- Allowed Ports
The TCP destination ports to which the proxy server will accept connections when using HTTP. Enter either a single port (From Port) or a range (Fill also the To (Optional)….
- Allowed SSL Ports
The TCP destination ports to which the proxy server will accept connections when using HTTPS. Enter either a single port (From Port) or a range (Fill also the To (Optional)….
Configuration options to enable the logging facility and choosing what to log.
- Enable HTTP proxy logging
Log all the URLs being accessed through the proxy. It is a master switch, hence the following four options are enabled (click on an option to toggle its current value).
(recall that the more is logged, the more space on the UTM‘s hard disk is needed).
- Log query terms
Log the parameters in the URL (such as
- Log user agents
Log the user agent sent by each browser.
- Log content filtering
Log when the content of web pages is filtered.
- Log outgoing connections
Let the firewall log the outgoing web accesses, i.e., those directed through the RED interface to the Internet. This options only works for transparent proxies.
Bypass transparent proxy¶
In this panel some exception to the transparent proxy can be defined: which sources (i.e., clients) and destinations (i.e., remote servers) should be ignored by the proxy, even if it is enabled in that zone.
- Bypass transparent proxy from (SUBNET or IP or MAC)
The sources that should not be subject to the transparent proxy. Entries can be single IP addresses, subnets, or MAC Addresses.
- Bypass transparent proxy to (SUBNET or IP)
The destinations that are not subject to the transparent proxy. Entries can be single IP addresses or subnets.
Use CIDR notation to enter subnets.
Configuration options for the space occupied on disk by the cache and the size of the objects stored.
- Cache size within memory (MB)
The amount in megabytes of memory that the proxy should allocate for caching web sites in the system memory.
- Cache size on hard disk (MB)
The amount in megabytes that the proxy should allocate for caching web sites on the hard disk.
- Minimum object size (KB)
The lower size limit in megabytes of a single object that should be cached.
- Maximum object size (KB)
The upper size limit in megabytes of a single object that should be cached.
- Do not cache this destination
The resources downloaded from these sites will never be stored in the cache. Entries can be domain names or single IP addresses (without subnet).
Objects whose size does not fall within the above defined ranges will never be stored in the cache on disk, but downloaded each time they are requested by a client.
- Enable offline mode
When this option is enabled, the proxy will never try to update cached objects from the remote web server, therefore clients will be able to browse cached, static websites even after the uplink went down.
This option proves useful to surf the Internet while the uplink is down, if the page requested has been cached before. However, this option may cause some trouble when trying to refresh a page, even with a working uplink, since the HTTP proxy would always serve the cached page. The only possibility to have a refreshed copy of a web page is in this case to clear the cache of the proxy server.
- Clear cache
Click on the clear cache button to immediately erase the cache on disk.
If there is another proxy server in the LAN, it can be contacted before actually requesting the original resource. This panel contains configuration options for the connection between the UTM and the upstream proxy.
- Use upstream proxy
Tick this checkbox to enable an upstream proxy and show more options. When enabled, before retrieving a remote web page that is not already in its cache, the UTM‘s proxy contacts the upstream proxy to ask for that page.
- Upstream server
The IP address of the upstream proxy server.
- Upstream port
The port on which the proxy service runs on the server.
- Upstream user
The username to connect to the proxy server, if needed.
- Upstream password
The password to connect to the proxy server, if needed.
- Forwarding IP address
Tick the checkbox to forward the client IP address to the upstream proxy
- Forward username
Tick the checkbox to forward the username to the upstream proxy.
Select how the users can access the proxy in each enabled zone. Click on the icon to the right-hand side of each zone and select any of these option from the drop-down menu that will appear.
- not transparent
The proxy server is available to anyone with no need to log in, but the clients need to configure their browser manually or tell the browser to search for a proxy (i.e., using either PAC or the WPAD protocol to set up the browser’s proxy settings).
The proxy server is available to anyone and no browser configuration is needed: All the HTTP traffic is intercepted and forwarded to the proxy server, that is in charge of retrieving the requested web pages and serve them to the clients.
- transparent (keep original source IP address)
This configuration is very similar to the previous option, with the only difference that every packet that leaves the proxy keeps some of the client’s original information: Its IP address, plus the zone and interface from which the traffic originated.
The proxy is not active for that zone.
Some browsers, including Internet Explorer and Firefox, are
able to automatically detect proxy servers by using WPAD. Most
browsers also support PAC, through a special URL. When using an
UTM as the proxy server, this URL looks like this:
The accesses policies are applied to every client that is connecting through the proxy, regardless of its authentication. An access policy rule is a time-based scheme that permits or prohibits accesses depending on diverse parameters about the user (e.g., the source or destination of the traffic), and the client used or the content downloaded (e.g., the user agent, the mime types, virus scanning, and content filtering).
A list of the already defined rules is displayed on the page. Any rule can specify if the web access is blocked or allowed, and in the latter case a filter type can be activated and selected.
The policies are evaluated from top to bottom, therefore their order is important: you can reorder them bu using the up and down arrows on the right-hand side of each rule.
To add a new access policy rule, simply click on Add policy: A form will open, in which to configure all the parameters, organised in tabs.
Give the policy a unique name.
Tick the checkbox to enable or disable the rule. Disabled rules will not be applied, the default is to enable the rule.
Select whether the rule should allow or deny the web access from the drop-down menu . When set to Deny access, the Mimetypes option in the Filtering tab is activated.
- Filter type
This drop-down menu allows to select what type of check should the rule perform. Available options are: none for no check and virus detection only to scan only for viruses. Moreover, if any content filter profile has been created (see below), it appears as an option and can be selected and applied to the rule.
- Authentication type
The type of authentication to apply to the clients. It can be None, in which case no authentication is required, group based or user based. One or more groups or users, to which to apply the policy, can then be selected among the existent ones from the list that will show up.
Authentication is only local, hence before being able to use it, at least one user or group must be created in the Authentication tab.
- Source Type
The sources of the traffic to which this rule applies. It can be <ANY>, a zone, a list of networks, IP addresses or MAC addresses.
- Destination Type
The destinations of the traffic to which this rule will be applied. This can be either <ANY>, a zone, or a list of networks, IP addresses, or domains.
- User agents
The allowed clients and browsers, as identified by their user agent, i.e., their identification string.
A list of the MIME types of incoming files that should be blocked, one per line. MIME types can only be blocked (i.e., blacklisted) but not allowed (i.e., whitelisted), therefore this option is only available in Deny access policies. This option allows to block any files not corresponding to the company policy (e.g., multimedia files).
- Enable time restriction
Decide whether the rule has effect on specific days and/or a time period. By default a rule is always active, but its validity can be limited to either an interval or to some days of the week.
By ticking the checkbox, the following options become available:
- Start hour, Stop hour
To fine-tune the interval of the day during which the access policy is active, write the start and end times, including minutes, from these drop-down menus.
- Enable for the following days
Select one ore more days of the week by clicking on each of them in the drop-down menu.
The UTM‘s proxy supports four different authentication types, that are shown in the drop-down menu at the top of the page: Local Authentication (NCSA), LDAP, Windows Active Directory (NTLM) and RADIUS. The NCSA type stores the access credentials on the UTM, whereas the other methods rely on an external server: In those cases it is mandatory to provide all the necessary information to access that server.
Underneath the drop-down menu from which to select the authentication type, options are split in two parts. The one above, Authentication settings contains common configuration items, while the one below changes upon the selection of the authentication type, presenting the settings that are specific to each method.
The common items that can be configured in this panel are:
- Authentication realm
The text shown in the authentication dialog and used as the realm of kerberos or winbind when joining an Active Directory Domain. When Windows Active Directory is used for authentication, the FQDN of the PDC should be used.
If the server name is
localauthand the domain name is
example.org, the FQDN is
- Number of Authentication Children
The maximum number of authentication processes that can run simultaneously.
- Authentication cache TTL (in minutes)
The time in minutes during which the authentication data should be cached, before being deleted.
- Number of different IPs per user
The maximum number of IP addresses from which a user can connect to the proxy simultaneously.
- User / IP cache TTL (in minutes)
The time in minutes an IP address is associated with the logged in user.
Once the common configuration form have been filled in, depending on the authentication type chosen it is possible to configure the specific settings for the authentication type selected. Local Authentication (NCSA), LDAP, Windows Active Directory (NTLM), RADIUS.
NCSA specific settings¶
- NCSA users
A list of the existing users, if any was created.
Click Add user to add more users and provide a username and password in the form.
- NCSA groups
A list of the existing groups, if any was created.
Click Add group to add more groups. A group is created by entering a group name and selecting one or more users that should belong to that group. A user may belong to more than one group.
While the same user can be legally part of one or more groups, care must be taken that the the groups the user belongs to do not define contrasting access policies. As an example, consider a user member of two groups, one with the policy to allows access to the website www.example.org, while the second group’s policy blocks the access to that web page. In this case, it is not easy to predict whether that user will be granted or not access to the site. The management of these issues is left to the designer of the access policies.
- Min password length
The minimum length for the local user’s password, which is by default 7 characters long.
LDAP specific settings¶
- LDAP server
The IP address or FQDN of the LDAP server.
- Port of LDAP server
The port on which the server is listening. The default value is 389.
- LDAP base distinguished name
The base distinguished name, this is the start point of the search.
- LDAP type
This drop-down menu allows the choice of the type of the authentication server among Active Directory Server, LDAP v3 server, LDAP v2 server, or Novell eDirectory Server.
- Bind DN username
The fully Distinguished Name of a user, which must have the permission to read user attributes
- Bind DN password
The password of the bind DN user.
- user objectClass
The objectClass that the bind DN user must belong to.
- group objectClass
The objectClass that the bind DN group must belong to.
NTLM specific settings¶
- PDC IP address
The IP address of the PDC.
- PDC hostname
The hostname the PDC.
Both hostname and IP address are needed to create the DNS entry to access the Primary Domain Controller.
- BDC IP address
The IP address of the PDC.
- BDC hostname
The hostname the PDC.
- Join AD Domain
Enter the Active Directory’s domain.
- Domain name for legacy systems
Write here the domain name if the Active Directory is on a Windows 2000 or older system.
- Join ADS
Click this button to test the connection with the AD.
New in version 5.0.
Both hostname and IP address are needed to create the DNS entry to access the Backup Domain Controller.
Requirements for the use of NTLM.
In order to be able to use Windows’ native authentication with active directory (NTLM), a few conditions must be satisfied:
The authentication settings need to be saved and applied before trying to join the domain.
The UTM must join the domain.
The system clocks on the UTM and on the active directory server must be synchronised.
The authentication realm must be a FQDN.
The PDC hostname has to be set to the netbios name of the Active Directory server.
The UTM clock can be synchronised with the clock of the Active Directory server by issuing the following command from the shell:
net time set -S IP_OF_AD_SERVER
The setup of a realm using NTLM authentication is described in this tutorial.
NTLM authentication with Windows Vista and Windows 7.
The HTTP Proxy in the UTM uses negotiated NTLMv2, while both Windows Vista and Windows 7 allow by default only straight NTLMv2. As a result, a client using one of these operating systems may fail to authenticate to the HTTP proxy even when supplying the correct credentials. The following changes to the client configuration are required to correctly authenticate:
(run as administrator)
Find the configuration option Network Security: LAN MANAGER Authentication Level
Select the value “Send LM * NTLM - use NTLMv2 session security if negotiated”
After applying these changes the client browser should correctly authenticate using the AD login name for the HTTP Proxy.
RADIUS specific settings¶
- RADIUS server
The IP address or URL of the RADIUS server.
- Port of RADIUS server
The port on which the RADIUS server is listening. Defaults to 1645.
- RADIUS Identifier
An additional identifier.
- RADIUS Shared secret
The password to be used.
The UTM's content filter abilities are based on the BitDefender URL filtering solution, that uses two filtering techniques which can be customised for each filter profile.
The first one consists of an advanced method of web pages categorisation, based on their content, while the second method uses a combination of white- and blacklists URLs and domains: All the URLs requested by a client are looked up in this list and are only served if they are found in the whitelist.
If the system has not yet been registered to Endian Network, the URL filter lists can not be downloaded. In this case, an informative message appears: By clicking on it, the registration form will open.
A filter is needed to be able to use the content filter. There is a default profile available, which allows access to every web page and should never be deleted. Additional profiles, that are needed when defining new access policies, can easily be created.
On the page, there is a list of the existing profiles, accompanied by a remark and by the available actions.
Above the table, there is a New filter link: When clicked, the link is replaced by the filter editor, that is used to configure a new profile. The following settings can be defined:
- Profile name
The name given to the profile.
- Activate antivirus scan
Enable the antivirus in the content filter.
Click General Use, Adult content and Productivity to open drop-down menus and add categories of pages that will be taken into account by the web filter.
Black and whitelists¶
In these textfields, personalised lists of web pages can be added.
- Allow for the following sites
Web pages that are whitelisted, i.e., always served to the client.
- Block for the following sites
Web pages that are blacklisted, i.e., never served to the client.
Content filtering may cause both false positives and false negatives, hence list domains that should always be blocked or allowed can be entered here. This policy will be applied regardless of the results of the content filter’s analysis.
New in version 5.0.5: URL Filtering option.
In this page it is possible to configure the HTTPS proxy server and the way it intercepts and applies content filtering to SSL-encrypted traffic, i.e., traffic through the 443 port.
The page is initially divided in three panels, the first one to choose the operating mode of the HTTPS proxy, the other related to the certificate needed in the Decrypt and scan mode.
- HTTPS proxy operating mode
Choose form the drop-down menu how the proxy should analyse the HTTPS encrypted traffic. The following options are available:
Disabled. The HTTPS proxy will not analyse the traffic.
URL filtering only. In this modality, described below, the HTTP proxy will only apply content filtering to the pages, but not decrypt them.
Full. The HTTPS proxy will decrypt and fully inspect the pages.
Once the modality has been chosen, click on Save, then on the Apply button in the green callout.
The URL Filtering mode
The URL Filtering mode allows to apply content filtering to HTTPS pages in a less invasive way compared to the Decrypt and scan mode; it is also easier to deploy, but it can be less effective. In details, this are the differences from the Decrypt and scan mode:
No need to install certificates on the clients. This means that the traffic will not be decrypted.
As a consequence, there will be no antivirus check on the HTTPS pages.
When a page is blocked by the proxy, the browser will receive a Connection refused error message.
Whitelists and Blacklists for both the HTTPS and HTTP Proxies are defined in the Access policy and Content Filter tabs.
To correctly allow the URL Filtering mode to operate, the clients using the proxy must be configured to use the UTM as their DNS server. If they do not, then the DNS Proxy must be enabled on the UTM for all the zones that use the HTTP(S) Proxy.
When enabled as Decrypt and scan mode, squid will intercept all clients’ requests and forward them to the remote server, like in the case of HTTP requests. The only difference is that for HTTPS requests, an intermediate certificate is needed for the client to connect via HTTPS to the UTM, which then can deliver the request, retrieve the remote resource, control it, and then send it to the client who requested it.
The following additional options are available for this mode:
- Remote certificates acceptance policy
This option controls how the UTM accepts the certificates from the remote server. The following values are available:
Accept every certificate. The proxy server accepts all certificates, even invalid ones, and then re-encrypts the connection to the client using a trusted, on-the-fly generated, certificate.
Show warning for untrusted certificates.The proxy server accepts all certificates, but when it encounters an invalid one, it re-encrypts the connection to the client with an invalid, on-the-fly generated, certificate. In this way the client can decide whether to trust or not the remote server.
Block connections using untrusted certificates. The proxy server will block connections to remote servers that use invalid HTTPS certificates.
- Forward HTTPS connections directly to the Upstream proxy
When this option is used, the HTTPS traffic will be managed directly by the upstream proxy, otherwise it is managed by the UTM.
- Bypass the following destinations
Write in the textfield the IP address or domain names of remote web sites that should be not be checked by the HTTPS proxy, one per line.
The two panels at the bottom are used only for the Decrypt and scan mode and allow to manage the certificate that will be used by the UTM.
The upload or the creation of a new certificate implies to invalidate any previously uploaded or created certificate. It will also be necessary to deploy the new certificate to all the clients.
- Upload proxy certificate
To use an existent certificate, click on Browse…, choose the certificate on the local hard disk, then click on Upload to copy the certificate to the UTM.
- Create a new certificate
To create a new certificate from scratch, click on this button. A confirmation dialog box appears, requiring a confirmation. Click on OK to proceed or on Cancel to close the dialog box and go back.
After the certificate has been uploaded or created, a new option in the form of a hyperlink will appear next to the Upload proxy certificate label:
- Download HTTPS proxy certificate
Click this hyperlink to download the certificate, which will be needed by the the clients.
In the knowledge base these tutorials are available:
How to set up the HTTPS proxy (only decrypt and scan mode),