The Network Menu

In this page you find:

The network menu can be used to tweak the networking configuration by adding specific hosts and routes, configuring uplinks, and adding VLANs and bonding devices.

The sub-menu on the left-hand side of the screen contains these items, each of which groups several configuration options:

  • Hosts–define hosts for local domain name resolution.

  • Routing–set up static routes and policy routing.

  • Zones and Interfaces–edit the uplinks or create VLANs.

  • Uplinks– manage additional uplinks.


On top of the page appears the table of Custom hosts, i.e., user-defined, which is right above the table showing the Hosts for system services. The former table contains host entries defined by the administrators, while the latter shows hosts that are automatically added by the Connect Switchboard when some services, like e.g., the HTTP or SMTP proxy, are enabled, since they are required to operate correctly.

The two tables share the same structure and content: Each entry contains an IP address, the associated hostname, and the domain name, if specified. The only difference is that the Hosts for system services table does not contain any Actions: Because these entries are needed by the system, they can not be edited, therefore the three available actions are available only in the first table.

Custom hosts

A new entry in the file can be added by clicking on the Add new host button right above the table.


New entries will be added to the /etc/hosts file, so do not edit that file manually, because changes to that file will be overwritten whenever new hosts are added from the GUI or the networking service is restarted.

A simple form will replace the table, in which to enter the following options:

IP address

The IP address of the remote host.


The hostname associated to the IP address.

Domain name

An optional domain name. If not supplied, the default domain name of the Connect Switchboard will be used.


The domain name is displayed in the Hosts for system services table below and can be retrieved from the CLI by using the hostname -d command.


An optional description of the host.


Tick the checkbox to enable the host. If not enabled, it can not be used.


Unlike in standard Linux systems, in the /etc/hosts file (see below), each IP address corresponds to one hostname and vice-versa. To associate more hostnames to the same IP address, repeat the procedure by inserting the same IP address but a different name.

The choice can be confirmed by clicking on the Add button, then a click on the Apply button in the green callout will reload the daemon with the new host.

Hosts for system services

At the bottom of the page, a table shows also those host that are automatically created by system services, which must be defined for a service to work correctly and can not be modified manually.

Hosts management, dnsmasq and /etc/hosts.

The dnsmasq application is used in small networks as DNS server for local hosts and as a DNS forwarder and caching server for worldwide DNS servers. The Connect Switchboard uses dnsmasq to be able to correctly resolve and answer DNS requests coming from the GREEN, ORANGE, and BLUE zones. It is sometimes desirable (e.g., for testing purposes on a remote website) to override some entries in dnsmasq, or to add some local server to dnsmasq’s cache, for local clients to be able to connect to it.

Both custom and system hosts listed in this page are stored in the /etc/hosts file at every restart of the daemon. Host added to that files directly via CLI will not persist after a reboot of the Connect Switchboard or a restart of dnsmasq.

The /etc/hosts file contains the so-called static lookup table, in the form:

IP1  hostname1  [hostname2]
IP2  hostname3  [hostname4] [hostname5]

Here, IP1 and IP2 are unique (numerical) IP addresses and hostname1, hostname2, hostname3, hostname4, and hostname5 are custom names given to those IPs. Names within square brackets are optional: In other words, each IP address can be associated with one or more names of known hosts. Custom host entries can be added to the file, that will then be resolved for all the clients connecting through the Connect Switchboard. On a typical Connect Switchboard, the /etc/hosts file contains at least the following entries:     localhost.localhost localhost   myappliance.localdomain myappliance

Here, is the IP address of the loopback device, called localhost, which is a mandatory entry for the correct working of any Linux system; while is the IP address of the GREEN interface.


Besides the default routing table, that can be seen in Menubar ‣ Status ‣ Network status, the routing on the Connect Switchboard can be improved with custom routing rules. This page displays a unique table that contains all the custom rules added.


When defining policy routing rules, the order of the rules is important. Rules in the table are evaluated from top to bottom and as soon as a rule is matched, traffic is routed according to that rule. No further evaluation is made on the remaining rules.

Whenever a change is carried out on the routing table, it is required that the changes be saved and the service be restarted.

Current routing rules

A policy route rule allows to associate specific network addresses, zones, or services (expressed as port and protocol) with a given uplink.

Static routing rules.

The main difference between static and policy routing is that the former routes all the traffic from a source network or to a destination network through a (static) gateway, while the latter provides more choices to define sources and destinations of traffic, and type of gateway. Moreover, additional option allow to select the service that creates the traffic and the TOS.

While in version 6.0 there is no static routing anymore, to define a static policy routing rule like in previous versions of Endian appliances, select in the ROUTE VIA section the option Static gateway and provide the IP address of the gateway, disregarding other options.

The policy routing table shows all the rules defined for routing, along with the following information: Source and destination networks, TOS, Gateway, Service, Remark, and the available actions.

As mentioned before, rules that appear higher in the table have higher priority and will be evaluated first. Traffic will then be routed according to the first matching rule found.

When clicking on the Add new route button, the rule editor will open, in which the setup of the rule is guided by several drop-down menus.

Routing rule editor

The following options are available:



The first drop-down menu allows to choose the source of the traffic. More entries, one per line, are accepted, but all must belong to the same type, either: A zone or interface, OpenVPN or L2TP users, IPs or networks, or MAC addresses. To apply the rule to all sources, select <ANY>.

Depending on the choice, additional options appear below in form of drop-down menus or textboxes, allowing to supply the necessary values.



The second drop-down menu permits the choice of the destination of the traffic, in form of a list of IP or networks, OpenVPN or L2TP users. Again, by selecting <ANY> the rule will match every destination.



The service that the rule should match.


User defined permits to specify a custom protocol and the ports to block, an option that proves useful when running services on ports different from the standard ones.


The type of traffic that is interested by the rule: TCP, UDP, TCP+UDP, ESP, GRE, and ICMP. TCP and UDP are the most used, GRE is used by tunnels, ESP by IPsec, and ICMP by the ping and traceroute commands.

Destination port

The destination port for the rule.


There exist dozens predefined services that can be chosen from the drop-down menus and should suffice to cover the most use cases. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., the SSH server listens to port 2345 or the web server runs on port 7981) or if a service, not included in the list, is using a particular port.

Route Via

Decide how the traffic should be routed for this rule. The following options are available:

Static gateway

An IP Address through which the traffic matching the rule will be sent.


Use this option to set up a static route. See below an explanation of static routing.


The uplink that should be used for this rule. There is the option, when the uplink becomes unavailable, that the routing be carried over to the backup link corresponding to the selected uplink. This option is enabled when the checkbox next to the drop-down menu is ticked.

OpenVPN user

An OpenVPN user, chosen from those available in the drop-down menu.

L2TP user

An L2TP user, chosen from those available in the drop-down menu.

OpenVPN client (gw2gw)

The traffic matching the rule will be sent through a VPN tunnel acting as an OpenVPN client connecting to an OpenVPN server.

Type Of Service

The type of service (TOS) can be chosen here. Four values can be chosen, depending on what is the most important characteristic of the traffic interested by that rule: default, lowdelay, reliability, or throughput.


A remark or comment to explain the purpose of this rule.


The position in which to insert the rule (relative position in the list of rules).


Tick this checkbox to enable the rule (default). If unchecked, the rule is created but not active: A rule can be enabled later.

Log all accepted packets

This checkbox must be ticked to log all the packets affected by this rule.


The activation of this option may cause the size of the log files to dramatically improve.

A click on the Add Rule button will save the rule, to activate it and reload all the routing entries, click on the Apply button in the green callout.

See also

There is a tutorial to set up basic policy routes available here.

Zones and Interfaces

In this page it is possible to configure network interfaces and set up VLANs and bonding devices, each organised in a table.


This table contains the zones configured on the Connect Switchboard and their configuration: IP subnet, NIC assigned to each of them. Unconfigured zones are marked as Disabled.

To add a new zone, click on the Add new ZONE button which will bring up the zone creator.

Zone Creator


Click on the dropdown to select the zone name which is a numbered list starting from ZONE4 up to ZONE31 allowing for a maximum of 32 definable zones (including default GREEN, ORANGE and BLUE).


Click on the dropdown to select from the available network zone types which include LAN, DMZ, and WIFI.


Enter a descriptive name to be used for the zone.

Select interfaces

Choose from the drop-down menu which interfaces will serve the zone.


To remove an interface, click on the x next to the selected interface.

IP/CIDR addresses

Add in the textbox new IP and subnets assigned to the zone, in CIDR format. If you have more than one subnet you wish to assign the zone you may enter each new subnet on its own line.

When done, click on Add zone to save the new configuration, then on Apply to enable it.

To edit an existing zone, click on the edit icon in the Actions column and the zone editor opens and it will be possible to edit the settings, by changing the following options.

Zone Editor

Enabled | Disabled

Click on the switch to change the status of the zone.


This switch is not available for the green zone, because that zone is a mandatory requirement for the Connect Switchboard to work properly.

IP/CIDR addresses

Add in the textbox new IP and subnets assigned to the zone, in CIDR format.

Select interfaces

Choose from the drop-down menu which interfaces will serve the zone.


To remove an interface, click on the x next to the selected interface.

When done, click on Update zone to save the new configuration, then on Apply to enable it.


The idea behind offering VLAN support in Connect Switchboard is to allow arbitrary associations of VLAN IDs to the zones and to provide an additional level of separation (and therefore another level of security) between the zones. The existing VLANS are shown in the table, if any had already been created.

A new VLAN can be defined by clicking on the Add new VLAN button above the VLAN list.

Add new VLAN

In the VLAN editor, a few click suffice to create a VLAN on an interface, by configuring the options:


The physical interface to which the VLAN is connected to. Only the available interfaces can be chosen from the drop-down menu. The menu also shows the status of the link of the interface.


It is not possible to define a VLAN that serves one zone (e.g., a VLAN on BLUE) on an interface that already serves another zone (e.g., eth1 serving GREEN). When trying to do so, the form closes and a red callout appears, informing that the VLAN can not be created.


The VLAN ID, which must be an integer number between 0 and 4095.


The zone to which the VLAN is associated with. Only the zones that have been defined in the network configuration wizard can be selected. The option “NONE” can be chosen, if that interface is used as a High Availability management port.


It will not be possible to define a VLAN on interfaces that are already assigned to a zone, VLAN, or uplink.

Whenever a virtual LAN is created, a new interface is created and named as ethX.y where X is the number of the interface and y is the VLAN ID. This interface is then assigned to the chosen zone and will show up as a regular interface in the various sections that report network information, like Menubar ‣ Status ‣ Network Configuration or in the Dashboard, where it can be selected to be drawn in the graph.

Bonding devices

Network bonding is a technique that allows to combine two or more network interfaces in a single bond and act as a single connection, with the main advantage to increase the throughput and the data flow.

New bonding devices can be added by clicking on the Add new bonding button.

Bonding device editor

The following options are available to configure a new bonding device.


Choose from the drop-down menu the name of the bonding device.

Select interface

Select at least two interfaces that will be part of the new bond among those available


Interfaces that are already in use–in VLANs, as uplink, or serving a zone–can not be part of bonding device and are therefore are not available.

Bond mode

Select the bonding policy mode you wish to utilize for the network bond.

  • balance-xor. Transmissions are based on the selected hash policy. The default is to derive a hash by XOR of the source and destination MAC addresses multiplied by the modulo of the number of port interfaces. In this mode traffic destined for specific peers will always be sent over the same interface. As the destination is determined by the MAC addresses this method works best for traffic to peers on the same link or local network. If traffic has to pass through a single router then this mode of traffic balancing will be suboptimal.

  • balance-rr. Sets a round-robin policy for fault tolerance and load balancing. Transmissions are received and sent out sequentially on each bonded port interface beginning with the first one available.

  • active-backup. Sets an active-backup policy for fault tolerance. Transmissions are received and sent out through the first available bonded port interface. Another bonded port interface is only used if the active bonded port interface fails.

  • 802.3ad. Sets an IEEE 802.3ad dynamic link aggregation policy. Creates aggregation groups that share the same speed and duplex settings. Transmits and receives on all ports in the active aggregator. Requires a switch that is 802.3ad compliant.

  • balance-tlb. Sets a Transmit Load Balancing (TLB) policy for fault tolerance and load balancing. The outgoing traffic is distributed according to the current load on each port interface. Incoming traffic is received by the current port. If the receiving port fails, another port takes over the MAC address of the failed port. This mode is only suitable for local addresses known to the kernel bonding module and therefore cannot be used behind a bridge with virtual machines.

  • balance-alb. Sets an Adaptive Load Balancing (ALB) policy for fault tolerance and load balancing. Includes transmit and receive load balancing for IPv4 traffic. Receive load balancing is achieved through ARP negotiation. This mode is only suitable for local addresses known to the kernel bonding module and therefore cannot be used behind a bridge with virtual machines.

When done, click on Add bonding device to save the new configuration, then on Apply to enable it.