The heart of the Zorp-based firewall solution is the firewalling software itself, which is a set of proxy modules acting as application layer gateways. Zorp is an application proxy firewall. For details on the architecture of Zorp itself, see Section 2.2, The concepts and architecture of Zorp firewalls.

Zorp must be installed on an Ubuntu-based operating system (Ubuntu 18.04 LTS) which installs automatically when booting from the Zorp installation media.

The Zorp Management Server (ZMS) handles the configuration tasks of the entire solution. To access ZMS and modify the configuration of the firewalls, the Zorp Management Console (ZMC) application on the desktop can be used. ZMS is the central command center of the solution: it stores and manages the configuration of Zorp firewall hosts.

The real power of ZMS surfaces when more than one Zorp firewalls have to be administered: instead of configuring the different firewalls individually and manually, it is possible configure them at a central location with ZMS, and upload the configuration changes to the firewalls. As ZMS stores the configuration of every firewall, the configuration of the entire firewall system can be backed up. In case of an emergency, it is possible to restore the configuration of every firewall with a few clicks.

Technically, ZMS does not communicate directly with the Zorp host: all communication is done through the Zorp Transfer Agent application, which is responsible for transporting configuration files to the managed hosts, running ZMS-initiated commands, and reporting the firewall configuration and other related information to ZMS. The Zorp Transfer Agent is automatically installed on every Zorp host. The communication is secured using Secure Socket Layer (SSL) encryption. The communicating hosts authenticate each other using certificates. For more information, see Section 13.1.1.5, Configuring authentication settings in ZMS.

Communication between the agents and ZMS uses TCP port 1311. If Zorp and ZMS are installed on the same host, the communication between the transfer agent and the ZMS server uses UNIX domain sockets.

By default, the ZMS host initiates the communication channel to the agents, but the agents can also be configured to start the communication, if required.

The Zorp Management Console (ZMC) is the graphical interface to Zorp Management Server (ZMS). A single ZMS engine can manage several different Zorp firewalls. ZMC is designed so, that almost all administration tasks of Zorp can be accomplished with it and therefore no advanced Linux skills are required to manage the firewall.

Figure 2.2. Communication between ZMC, ZMS, and Zorp

For information on the installation of ZMC see Chapter 5, Installing the Zorp Management Console in Zorp Professional 7 Installation Guide.

Zorp can authenticate every connection: it is a single sign-on (SSO) authentication point for network connections. During authentication, Zorp communicates with the Zorp Authentication Agent (ZAA) application that runs on the client computers.

However, Zorp does not have database access for authentication information such as usernames, passwords and access rights. It operates indirectly with the help of authentication backends through an authentication middleware, the Zorp Authentication Server (ZAS). To authenticate a connection, Zorp connects to ZAS, and ZAS retrieves the necessary information from a user database. ZAS notifies Zorp about the results of the authentication, together with some additional data about the user that can be used for authorization.

Figure 2.3. The operation of ZAS

ZAS supports the following user database backends:

ZAS supports the following authentication methods:

ZCV is not a content vectoring engine, it is a framework to manage and configure various third-party content vectoring modules (engines) from a uniform interface. Zorp uses these modules to filter the traffic. These modules run independently from Zorp. They do not even have to run on the same machines. Zorp can send the data to be inspected to these modules, along with configuration parameters appropriate for the scenario. For example, a virus filtering module can be used to inspect all files in the traffic, but different parameters can be used to inspect files in HTTP downloads and e-mail attachments. Also, different scenarios can use a different set of modules for inspecting the traffic. Using the above example, HTTP traffic can be inspected with a virus filter, a content filter, and all client-side scripts can be removed. E-mails can be scanned for viruses using the same virus filtering module (but possibly with stricter settings), and also inspected by a spam filtering module.

Figure 2.4. Interaction of Zorp and ZCV

The interaction of Zorp and ZCV takes place as follows:

The examples demonstrated on Figure 2.5, Content vectoring scenarios in ZCV can be translated to the ZCV terms defined in the previous paragraph as follows:

Figure 2.5. Content vectoring scenarios in ZCV

This is only a basic example, but further router rules can be used to optimize the decisions. For example, it is unreasonable to remove client-side scripts in non-HTML files that are downloaded, and so on. Similarly, another rule group corresponds to the SMTP scenario, with a scanpath including a virus filtering and a spam filtering module instance.

The whole process is summarized in the following procedure.

Zorp uses strongSwan to support native Linux IPSec solutions, and also supports OpenVPN (an SSL-based VPN solution). Zorp supports both transport and tunnel mode VPN channels. Tunnel authentication is possible with X.509 certificates and with pre-shared keys (PSK). IPSec settings can be negotiated manually, or by using Internet Key Exchange (IKE).

Figure 2.6. Virtual Private Networks

Native services provide a limited number of server-like features in Zorp. Their use is optional and depends on the needs and security requirements of your organization. The use of Network Time Protocol (NTP) and Bind is recommended, while Postfix is useful for managing mail traffic from various firewall components locally.

These services are called native because they are installed with Zorp and are available by default. They are implementations of the actual Linux services of the same names. These services provide networking services that are either difficult to implement with application proxies (or at the packet filter level) or provide services for the firewall itself. For more information on these services, see Chapter 9, Native services.

Zorp supports multi-node (2+) failover clustering, as well as load balance clusters (most load balance configurations use external devices). Clustering support must be licensed separately. Zorp supports the following failover methods:

For more information see Chapter 12, Clusters and high availability.

Zorp runs on Ubuntu-based operating systems. Currently it supports Ubuntu 18.04 LTS. The Zorp packages can either be installed on an existing Ubuntu server installation from the official Balasys APT repositories, or the installation media can be used to install a minimal Ubuntu 18.04 LTS server and the Zorp packages.

A firewall controls which networks and hosts can be accessed, and who can access them. To create traffic rules, first, the networking environment of Zorp must be accurately defined, then, access control on the traffic can be applied. This can be achieved using zones and rules.

Zones consist of one or more IP subnets that Zorp handles together. By default, there is only a single zone: the IP network 0.0.0.0/0, which practically means every available IP addresses (that is, the entire Internet). It is possible to organize zones into a hierarchy to reflect the actual network, or the structure of the organization.

Although zones consist of IP subnets and/or individual IP addresses, zone organization is independent of the subnetting practices of the organization. For example, a zone can be defined that contains the 192.168.7.0/24 subnet and it can have a subzone with IP addresses from the 10.0.0.0/8 range, and the single IP address of 172.16.54.4/32. For details on zones, see Section 6.2, Zones.

The first line of network defense is a packet filter that blocks traffic based on the IP address or TCP/UDP port number of the source (that is, the client) or the destination (that is, the server) of the connection. That way, more thorough analysis, such as traffic inspection or content vectoring is performed only on traffic that is permitted at all. This technology using both packet filtering and application proxying together is called multilayer filtering.

In Zorp, packet filtering is handled by the kzorp kernel module, therefore packet filtering services are completely handled on the kernel level. When Zorp starts, it sends all information about the traffic permitted to pass the gateway (that is, the list of configured services, zones, firewall rules, and so on) to the kzorp module.

Application-level services (also called proxy services) are handled on two levels:

For both service types, the kzorp kernel module makes the client-side access control (DAC) decision. Both service types can be configured from a uniform interface using ZMC.

Handling packet filtering in the kernel has the following important consequences:

Zorp is a proxy gateway. It separates the connection between the client and the server into two separate connections: one between the client and Zorp, and another between Zorp and the server. Zorp receives the incoming client connection requests, inspects them, and transfers them to the server. Zorp also receives the replies of the server, inspects them, and replies to the client instead of the server. That way Zorp has access to the entire network communication between the client and the server, and can enforce protocol standards and the security policy of the organization (for example, permit only specific clients to access the server, or enforce the use of strong encryption algorithms in the connection).

Proxying can take two basic forms:

The traffic in a connection usually consists of two parts:

The protocol proxies of Zorp analyze and filter the control part of the traffic, but — in most cases — ignore the payload. (The antivirus and spam-filtering modules of ZCV inspect the payload.) Zorp proxies can thoroughly inspect the protocol headers to ensure compliance to the protocol, disable the use of prohibited options, and so on. Zorp can handle commonly used protocols, including:

Every protocol proxy can handle the SSL/TLS encrypted version of the protocol, and inspect the embedded traffic, giving control over HTTPS, SMTPS, and other connections.

For more information on supported protocols and for a complete list of proxies, see Zorp Professional 7 Reference Guide.

The default settings of the protocol proxies of Zorp ensure that the traffic complies with the relevant RFC of the given protocol. To provide flexibility, and to solve a wide variety of custom scenarios, the proxies can be customized and their parameters can be changed to best suit the needs of the environment and the security requirements. For example, it is possible to:

In addition, the proxies in Zorp are fully scriptable, and can be programmed in Python to perform any custom functionality. For information on customizing proxies, see Section 6.6.1, Customizing proxies, and Zorp Professional 7 Reference Guide.

Today, network traffic often uses more than a single protocol: it embeds another protocol into a transport protocol. For example, HTTPS is HTTP protocol embedded into the Secure Socket Layer (SSL) protocol. SSL encrypts HTTP traffic and many firewalls simply permit encrypted traffic pass without thorough inspection. This is not an optimal solution from a security aspect, and Zorp has a better solution to this problem: it decrypts and inspects the SSL traffic, and passes the data stream to an HTTP proxy to inspect it. This modular architecture (that is, proxies can be stacked into each other, or even chained together for sequential protocol analysis) allows for sophisticated inspection of complex traffic, for example, to perform virus filtering in HTTPS, or spam filtering in POP3S traffic. The new and enhanced version of the integrated category-based URL filtering solution is available from Zorp 7.0.5 with the smaller-sized, optimized database for usual scenarios, which requires 1 GB storage space and 300 MB daily update traffic, and with the more extensive normal database for more extended scenarios, which needs 6 GB storage space and 2 GB daily update traffic.

The configuration tree lists the configurable components of a Zorp system. Whenever an item is selected in the configuration tree, the main workplace displays the configurable parameters of the selected item. The configuration tree is organized hierarchically and this hierarchy maps the management philosophy of Zorp.

Figure 3.5. Configuration tree in ZMC

The topmost item in the configuration tree is the Site's name that has been entered during ZMS host installation. There are usually one or more items below it: ZMS and/or Zorp hosts.

In the most basic scenario, where ZMS is installed on the Zorp machine, there is only one machine listed. Note that in this case the name that appears here is the name of the ZMS host entered during installation. Under each host, a varying number of configuration components are listed.

By default two components are available for each host:

Because the ZMS Host in this example is a Management server too, it has a third component for configuring management server parameters.

Each site, host, and component has status icons or leds on its left. These are described in detail in Section 3.3.6, Status indicator icons.

The number of components increases with the configuration: many services have standalone configuration components that that have to be added to the configuration tree to be able to use them. The number of components increases as you start the real work: many services have standalone configuration components that you have to add to the configuration tree to use them.

The forthcoming chapters deal with these components in detail.

3.2.1.2. Host

A Site is composed of one or more Hosts. Hosts can be the following items:

• Zorp firewalls,

• ZCV hosts,

• ZAS hosts, and

• ZMS-managed hosts.

At the very minimum setup, when Zorp and ZMS are installed on the same machine, there is one Host registered for the given Site. The number of Zorp firewall nodes per Site is only limited by the number of licenses purchased. With the exception of Zone, PKI and Class Editor settings, the configuration parameters are always per Host.

To display system statistics for a Host component (ZMS or Zorp), click on the name of the Host. The statistics are displayed under the Host tab. The following statistics are available:

• processor

• load average

• uptime

• memory usage: RAM and SWAP

• only on Zorp hosts:

  • the version number of Zorp

  • the number and status of running Zorp Instances, Processes and Threads

• the validity and size of the product licenses (Zorp, ZMS, and so on) available on the host.

  ZMC displays a warning if a license expires soon, and an alert e-mail can be configured as well. For details on configuring e-mail alerts for license expiry, see Procedure 11.3.8.8, Monitoring licenses and certificates.

  Note
  To access license information from the command line, login to the host and enter: /usr/lib/zms-transfer-agent/zms_program_status hoststat

Figure 3.6. Host statistics

The statistics are automatically refreshed every 30 seconds by default.

Tip
Although host statistics can seem a less important, auxiliary service, it is extremely useful when firewalls operate under continuous heavy load and resource allocation needs to be optimized.

Most of ZMC is occupied by the main workspace where the variuos components of the Configuration tree can be managed. The majority of configuration tasks are performed here. The content of this pane depends on which component is selected in the configuration tree.

The new administrative components can be added to the host at the bottom part of the main workspace.

If a different Host is selected in the Configuration tree, the content of the main workspace changes too.

Although most options of the menu bar are available as buttons on other parts of the ZMC window, there are some special menu points that have no corresponding button in the main workspace. The buttons are described in the specific section which deals with the corresponding ZMC part they appear in.

3.2.3.7. Status bar

The bottom line of ZMC is called the status bar. When working with configuration components it can be used to check whether changes have already been Committed or there are Unsaved changes. By checking the status, it can be made sure whether the information there on the ZMC interface is the same as the information currently stored in the ZMS configuration database (committed status).

Figure 3.12. The Status bar

When logging in to ZMS through ZMC, first an SSL encrypted channel is built, then firewall configurations currently stored in the ZMS database are downloaded into ZMC. When the required configuration changes are completed they are committed back into the ZMS database. At this point no changes are made to the firewall(s); only the database on the ZMS host is modified. It takes a separate action, an upload issued to actually propagate changes from the database down to the firewall(s). With this upload action the configuration changes get integrated into the configuration files on the Zorp machine(s). For final activation, a reload or restart (depending on the situation and the service being modified) is needed to activate the changes.

A complete configuration cycle consists of the steps described in the forthcoming sub-sections.

Most administration commands for the configuration tasks can be executed from either the menus or the buttons in the Button bar. The number of buttons visible varies based on the component selected in the Configuration tree.

Figure 3.13. The Button bar

3.3.2.1. Commit and Revert

The Commit changes and Revert changes buttons are always visible, at the minimum.

Commit is used when a (set of) configuration changes are finished and the changes are required to be saved to the XML database of ZMS.

Revert serves the opposite purpose: before committing changes to the ZMS database, it is possible to clear, to undo them in ZMC.

Note
It is very important to remember that Revert is limited to ZMC, it cannot clear configuration changes that are already committed to the ZMS database. Those changes can be undone by performing a new round of changes in ZMC and then committing these changes again.

Both Commit and Revert are component–focused controls. Consequently, before selecting another component from the Configuration tree, commit the changes in the current component, otherwise they are lost. In such cases, ZMC displays the following warning:

Figure 3.14. Warning: commit the changes before leaving the component

3.3.2.3. Control service

Under Control service, services can be Reloaded or Restarted so that they reread the new configuration files that are already on the corresponding Zorp firewalls after a successful Commit / Upload cycle.

Restarting or Reloading the given service depends on the type of service (some cannot be reloaded, only restarted) and the intended outcome.

After clicking Control service, the following actions are available:

Figure 3.15. The service control dialog

Note
Besides Restart and Reload, there are also Start and Stop functions available here to start or stop services.

3.3.2.4. View and Check current configuration

View current configuration and Check current configuration are both used to retrieve information on the current state of the Zorp firewall(s).

View current configuration displays the configurations of the component selected in the Configuration tree on the selected host. This information comes from the ZMS configuration database, which is not necessarily the same as the actual settings on the selected host – when changes are already committed, but not yet uploaded. For example, if the ZMS_Host > Networking component is selected and then View current configuration is used, the following will be displayed:

Figure 3.16. Networking configuration on ZMS_Host

It is a file-by-file listing of the active configuration on the selected host. Note that it is not necessarily the same configuration that is stored in the ZMS database: after a commit but prior to an upload event they can differ significantly. To query this difference, click Check current configuration. Using the Linux diff utility by default, it compares configurations stored in the ZMS database with the configurations currently active on the selected host.

Figure 3.17. Checking current configurations

The differences are marked in red, otherwise the normal output of diff is displayed, with + and – signs designating data from the host and from the database, respectively. The diff command can be replaced with another utility of choice under the Management Server component. For details, see Chapter 13, Advanced ZMS and Agent configuration.

3.3.2.5. Files

Configuration files: 

Files provides further information and configuration options of the files and attributes described in the output window of Check current configuration and the diff command.

Files serves two purposes.: It provides vital information about which configuration files a component (of the Configuration tree) uses and gives chance to modify the properties of the listed files.

For example, in case of the Networking component, the list of used files is the following.

Figure 3.18. Files used by the Networking component

Apart from the name and location of files, information can be retrieved about the owner, owner group, access rights and file type parameters. The Manage column is very important and has a corresponding checkbox immediately below the file listing: this can be used to control what files ZMS manipulates on the host machine, if needed.

Note
It is not recommended to take files out of the authority of ZMS, because it can severely limit the effectiveness of ZMS–based administration. However, it is possible to do it, if the checkbox under the Manage column is deselected.

File settings: 

To modify the properties of a file, click on the file in the list. The following subwindow opens.

Figure 3.19. Changing file properties

Warning
There must be a solid reason for changing these properties and one must be prepared for the possible consequences of such actions. A good understanding of Linux is recommended before making changes in file properties.

Consider different if these properties change: 

The third part of the window is for configuring the work of the comparison utility, which is diff by default. It can be defined which file properties are required when checking for changes.

Figure 3.20. Configuring diff conditions

Tip
Checking for configuration file differences is beneficial from a security aspect too: it is an additional tool for making sure nobody has altered critical files on the firewall.

Postprocess script: 

At the bottom of the Configuration tab, a postprocess command can be specified that is run after the corresponding configuration file is uploaded to the firewall host. Some services rely heavily on this option. For example, Postfix that runs /usr/sbin/postmap %f as a postprocess command to transport virtual domains and set various access restrictions are properly.

Scripts tab: 

Configuration files under Linux are reread during service reloads or restarts. These actions are performed by running the corresponding scripts exclusively from the /etc/init.d directory. The Scripts tab of the Files window provides an interface where the starting scripts can be checked and alter and fine-tune them with special Pre upload and Post upload commands. With simple components, such as Networking, these options are rarely used, but in some cases might prove especially useful.

Some components, for example, Text Editor, can manage configuration files that are automatically reloaded. They cannot be restarted after a Commit. To set the status icon of these components to Running, select Configuration automatically runs on the Scripts tab.

Some components are related to or dependent upon each other, meaning that modifying one modifies the other too. If modifying a component affects another component, the status of this related component changes to Invalidated in the Configuration tree. ZMC automatically handles related components and all actions (Commit, Reload, and so on). Just select the Apply action for the dependent components checkbox in the confirmation dialog of the action.

When reloading or restarting a component related to the Packet Filter, the skeleton of the Packet Filter is automatically regenerated. See Appendix A, Packet Filtering for details on generating skeletons.

Most firewalls are administered by a group of administrators and not just by a single individual. In a Zorp system each administrator can have his or her own ZMC console and administrators can be separated geographically. Regardless of their locations they administer the same set of Zorp firewalls through a single ZMS host machine. Therefore, to avoid configuration inconsistency caused by more than one administrator working with the same configuration simultaneously, a configuration lock mechanism ensures that a component's configuration can only be modified by a single administrator at a given time. Locking takes place per component, as soon as they are changed, for example, a setting in a component, the status bar displays the following string: Unsaved changes and that component is locked for configuration.

However, modifying a component might make it necessary for other components to be locked as well, in order to prevent configuration from inconsistent changes.

There exist some generic rules that can be applied for managing locking successfully:

Active locks can be viewed at Management > Locks:

Figure 3.21. Management > Locks - Viewing active locks

The Owner column can take two values:

The lock placement is automatic. The first administrator who starts modifying a component's settings gets the lock of that actual component. In the Active locks column the exact name of the locked component (Site/Host/Component) is displayed. Locks are cooperative, meaning that any administrator can release any other administrator's locks by selecting the desired component in the Lock management window and then clicking Release. The administrator whose lock is released this way is immediately notified in a warning dialog. Also note that as a result of the release of the forced unlock, the GUI owning the released lock closes without saving any modifications in order to avoid any inconsistency in the configuration.

It is not possible to edit a component that is already locked by someone else, because a notification dialog immediately appears upon trying to change anything inside the given component. The following window will be displayed for any other administrator who wishes to edit the component:

Figure 3.22. Notification on a locked component

As required by the mentioned lock queue mechanism implemented in ZMS, administrators shall not normally release each other's locks, but they can preregister for future locks while the current lock is active.

The above window will however not disappear, after the locking administrator commits the changes. Other administrators therefore, can either preregister for locking the component by clicking yes or choose not to preregister by clicking no.

In case an administrator preregisters for the locking of an element, the following window appears:

Figure 3.23. Component waiting for locking

As soon as the locking administrator releases the lock, the window Component waiting for lock disappears and the user wishing to edit the component is granted the lock automatically. Normally, this shall not take long.

The Configuration tree in ZMC displays various indicators to provide a quick overview about the status of the managed sites, hosts, and components. Site and Host-level status is indicated by leds, while icons are used to display Component-level status information.

Figure 3.24. Status indicator icons and leds

Hovering the mouse cursor over a led or icon displays a tooltip with the full description of the status.

Figure 3.25. Tooltip after hovering the mouse over an icon

ZMC provides two graphical aids that can help administration when parts of a host's configuration settings have to be recreated on another host.

Figure 3.26. Selecting multiple components in the Configuration tree

There are two options to refer to components involved in network configurations.

If links are used, IP addresses can be entered manually or select the link target from a drop-down menu. Using links has the advantage that future changes in the network setup do not influence the operability of the connection.

Delete the existing links with the Unlink and Unlink as value options.

Components can be referenced with the help of variables. By using variables values appearing in several places can be changed at once. If a variable is modified, all corresponding values are changed. Variables are denoted with $ characters preceding and following their names.

$autobind-ip$

During the management and maintenance of the firewall host it is often useful to be able to temporarily turn off certain rules, policies, and so on. In Zorp this feature is implemented via the Disable/Enable options of the local menus. To display the local menu of a rule or object, right-click on the object. For example, a packet filter rule that is only rarely used can be simply disabled when it is not required, to be enabled again when it is required. Disabled rules and objects are generated into the configuration file as comments with the # prefix.

Disabled objects can be edited, modified similarly to any other objects. However, their validity (whether for example, the required parameters are filled, their name is unique, and so on) is checked only when they are enabled again.

The following objects can be disabled in the various ZMC components:

Host:

Packet filter:

Disabling a group automatically disables its childrens as well.

Zorp:

Networking:

Date and time:

Content vectoring:

ZAS:

Heartbeat:

IPSec VPN:

Mail transport:

ZMC displays information in several places as tables of entries having various parameters or meta-information. Such filter windows are used to display firewall rules, Zorp logs, Active connections, and so on. The common properties and handling of these tables is summarized in this section.

Figure 3.27. A filter window

Filter windows consist of three main parts:

The actions available in the command bar are described at the documentation of the actual component using the filter window (for example, Log viewer).

Each entry of the table consists of a single row, with the various parameters displayed in labeled columns.

To filter the entries, use the filter bar located above the table. The Filter type specifies the column to search for the expression (string or regular expression) typed in the field. To search, click Filter now. To restore the full list, click Clear. To create custom filter expressions, select the Advanced option as Filter type. The filter expressions can also be combined using the logical AND (if all criteria are met) and OR (if any criteria are met) operations. Custom filters can be run once (click Ok), or they can be bookmarked for repeated use (click Save).

Figure 3.28. Advanced filtering

Saved filters are also displayed in the Filter type combobox. To manage saved filters (delete, rename and edit), click Edit bookmarks.

Figure 3.29. Editing bookmarks

In some cases (for example, in the Log viewer), advanced filters can be configured to highlight the entries matching the filter expression. To configure highlighting, select Color matching and set the color of the highlighting.

The command bar offers various operations to display and export the logs of the host. The following operations are available:

The Interfaces tab of the Networking ZMC component lists the network interfaces available on the host, along with their type, IP addresses, and connected zones.

Figure 5.2. Network interface configuration

If the interface settings are changed, in order to activate the changes, restart the modified network interface. Additionally, it may be required to temporarily stop an interface for security or maintenance reasons with the Actions button under the network interface listing.

Rule(proto=6,
    dst_iface='eth0',
    service='test'
    )

Rule(proto=6,
    dst_iface='dyn',
    service='test'
    )

In some cases it can be useful to fine-tune the network for special purposes. For example for Virtual Local Area Network (VLAN) technology: many organizations use it for security and network traffic separation purposes. VLANs are logically separated components of physical networks. Logical separation means that although they are on the same physical network (otherwise known as broadcast domain) hosts on separate VLANs cannot communicate with each other unless a router is set up that provides the interconnection. Routing functions for VLAN, and VLAN creation in general, are typically performed by Layer 3 Ethernet switches. Provided that VLAN-capable network cards are installed in the machine, Zorp fully supports VLANs and ZMS provides a control for configuring it.

VLAN interfaces are named in the following manner:

ethx.n where

Figure 5.5. Configuring VLAN and alias interfaces

Using alias interfaces allows to configure multiple IP addresses to a physical device. Alias interfaces are named in the following manner:

ethx:n where

An alias can be defined for existing physical and VLAN interfaces.

Spoof protection means that the packet filter module of a firewall checks to ensure that packets arriving on an interface have source IP addresses that are legal in networks reachable through that given interface and accepts only those packages that match this criterion.

For example, if eth0 connects to the Intranet (10.0.0./8) and it is spoof-protected, the firewall does not accept datagrams on this interface with source IP addresses other than the 10.0.0.0/8 range. It does not accept datagrams with source IP address from the 10.0.0.0/8 range on interfaces other than eth0 either.

For further details on zones, see Section 6.2, Zones. For more information on Spoof control in relation to packet filter rules, see Section A.4.3.3, Spoof protection.

The bottom part of the Interfaces tab can be used to specify activation scripts and various other parameters of the network interfaces. The following options can be configured:

The state of the configured interfaces is indicated by coloured leds in front of the name of the interface:

The state of the interface is automatically updated periodically. The frequency of the update can be configured in Edit > Preferences > General > Program status.

Status update can also be requested manually from the local menu of the interface:

Hovering the mouse over an interface displays a tooltip with status information and detailed statistics about the interface. The following status information is displayed:

The statistics about the traffic handled by the interface is divided into Received and Sent sections, relevant for the received/sent packets, respectively.

A route has the following parameters:

The above parameters are interpreted the following way: messages sent to the Address/Netmask network should be delivered through Gateway using Interface.

New entries into the routing table can be added by clicking the New button of the control bar; existing entries can be modified by clicking Edit. The updated routing tables take effect only after the new configuration is uploaded to the host, and the routing tables are reloaded using the Actions/Reload buttons of the control bar.

Figure 5.16. Adding new routing entries

The list of routing table entries can be sorted by all of its parameters (network, gateway, and so on) by clicking on the header of the respective column. By default, the list is displayed according to the general listing policy of the routing tables, that is, the networks connecting via a gateway are listed after the directly connected networks.

The list can be filtered using the filter bar above the list.

Figure 5.17. The Filter bar

Routes can be temporarily disabled by right-clicking the selected route and selecting Disable from the appearing local menu.

When the Zorp host is administered via a terminal, the routes have to be entered manually by editing the /etc/network/static-routes configuration file. Each line of this file corresponds to a route, and has the following format:

interface_name to address/netmask through gateway metric [metric]

For the modifications to take effect, the routing tables have to be reloaded by issuing the /usr/lib/zms-transfer-agent/zms-routing params="reload" command.

By default, ZMC defines a zone called internet on every site. The internet contains the 0.0.0.0 and the ::0 networks with the 0 subnet mask. This zone means any network: every IP address not belonging to any other zone belongs to the internet zone.

Figure 6.1. Zones

The internet zone is typically used in firewall rules where one side of the connection cannot be defined more exactly.

Zones are managed on the Site component in ZMC. The left side of the main workspace displays the zones defined on the site and their descriptions. IP networks that belong to the selected zone are displayed on the right side of the workspace.

Use the control buttons to create, delete, or edit the zone definitions and the IP networks. Use the arrow icons to organize the zones into a hierarchy (see Section 6.2.3, Zone hierarchies for details).

If a zone is created, modified or deleted in a ZMC, the change is immediately visible in the zone lists of the same ZMC without committing the changes. If these changes to a zone or zones are committed, the changes become visible in the zone information of other ZMCs as well.

Zones can be organized into a tree, much like the directories of a file system. Define a topmost zone and with many subzones, each for administratively different parts of your networks. A zone and its subzone have parent-child relationship: child zones automatically inherit all properties and settings of their parents. For example, Zone A is the parent zone of Zone B, and all clients in Zone A may browse the web through HTTP. Zone B inherits this setting, so all clients of Zone B have unrestricted HTTP access.

To stop a zone from inheriting the properties of the parent zone, use a DenyService. For details on DenyServices, see Procedure 6.4.3, Creating a new DenyService.

Zones can be reorganized as needed.

Figure 6.5. Zones, inheritance, and DenyServices

To remove a child zone from the hierarchy, select the zone and click the left arrow.

Starting with Zorp 5.0, you can directly use hostnames in zones. During startup, Zorp automatically resolves these hostnames to /32 IP addresses, and updates them periodically to follow any changes in the IP addresses related to the hostname. When using hostnames in zones, note the following considerations and warnings:

To find a zone or a subnet, select the site in the configuration tree and click the Find button.

Figure 6.8. Finding zones and subnets

You can search for the name of the zone, or for the IP network it contains. When searching for IP networks, only the most specific zone containing the searched IP is returned. If an IP address belongs to two different zones, the straightest match returns the most specific zone.