Questions about network configuration

  1. I see that the Ethernet interfaces are called ETH00, ETH01, ETH02, … while I was used to other Linux distributions with names like eth0, eth1, eth2, … Why have these names been used instead of the usual ones?
    During the start up phase ZeroShell performs the automatic detection of hardware and attributes each identified interface on the physical network with a logical name ETHnn. At first boot attribution is sequential, while subsequently the attribution is based on MAC addresses. In case of physical replacement of a network card the system will name the new interface with the same name as the one replaced. By doing so, a physical hardware abstraction is created so the configuration of the IP address, the VLANs, the firewall, the routing table and other depends on the names of the interfaces don’t need to be changed if a network card is added or replaced.
  2. I would like to use ZeroShell as an ADSL router for my LAN. What types of modems are supported?
    At present, ZeroShell only supports modems with Ethernet connections that support PPPoE protocol (point-to-point encapsulated in Ethernet frames). The majority of current external modems also have an Ethernet port, as well as the USB connector. It is obvious that other than the compatibility of the modem, it is necessary that the ADSL provider supports PPPoE protocol. Currently, the majority of ISPs provide it.
  3. My LAN connects to Internet with a dynamic IP address that changes if the connection is closed and then reopened. I would like the web server, the mail server and a machine with the active SSH daemon that have private IP addresses on the LAN to be reachable externally via Internet. Can I do so using ZeroShell as a router?
    You can do so using the dynamic DNS and virtual server functions. Thanks to dynamic DNS you can attribute a FQDN hostname resolved on Internet and which is updated by ZeroShell when the IP changes. In this way, you can always reach the ZeroShell router independent of the address that varies. Thanks also to the ZeroShell virtual server function, you can forward the requests that arrive on determined TCP or UDP ports to the real servers on the LAN with private addresses. In your case you should instruct ZeroShell to forward the 80 and 443 TCP ports to the web server, the 25 TCP to the mailserver and the 22 TCP port to the server that offers the secure shell. Obviously, since they are private addresses on the LAN you must also enable NAT. Lastly, the ZeroShell virtual server can also work in load balancing, by balancing the requests on multiple servers that offer the same service.
  4. I need to create a bridge that includes the Ethernet interface with which I am connected through the web interface. Unfortunately when I confirm the creation of the bridge I lose the ZeroShell connection. What does it depend on? Can the problem be resolved?
    When an interface becomes part of a bridge it loses the IP configuration and the VLAN 802.1q and it is inevitable that connection is lost from this port. The simplest way to resolve the problem is to create a bridge using the console instead of the graphical interface. Just click key B on the console and specify what interface to insert in the bridge. By doing so, the IP configuration and the VLANs migrate directly from the Ethernet interface to the bridge, enabling connection again in just a few seconds (the time needed for the bridge to pass to forwarding status). The other interfaces that must belong to the bridge can be inserted at this point via the web browser.
  5. What are Virtual LANs or VLANs?
    Often, and in particular for local networks with a lot of hosts, the Ethernet network must be divided into various segments. Each of these segments is attributed a distinct IP subnet in such a way that communication among the machines belonging to the various segments occurs via an IP router. This not only reduces multicast and broadcast traffic that would also have the negative effect of using the CPUs of all the hosts for no reason, but would also have positive effects on security. In fact, if the attribution of the hosts to a given Ethernet segment occurs in a logical manner, or rather by forming part of a logical sub-structure having a common characteristic such as they can all be administration PCs, all workstations in the research sector, all servers or all network printers in a company, then the Firewall rules can be set on the router to prevent illegal connections among machines belonging to different sectors.
    A first approach to obtain the above could be to connect all the hosts that must belong to a sector to a switch, those of another sector to a another switch and so on. N switches could then be connected with n network cables to an IP router with at least n network interfaces. This would require a big initial effort to estimate the number of switches to acquire and size in terms of port numbers and would without doubt cause overestimation of these parameters, leading to waste. On the other hand, this solution appears too static since it complicates the moving of a host from one sector to another when requested.
    A solution to these problems are switches in the medium to high range that enable the partitioning via software of the available ports, based on certain criteria. This set of ports is called a Virtual LAN or is abbreviated to VLAN. As you can imagine, the switch fabric could forward the Ethernet frames to the ports belonging to the same VLAN, while it would prevent any communication among distinct Virtual LANs. The attribution of a switch port to a certain VLAN can take place based on different criteria:

    • Port Based: the administrator configures the ports by attributing them to a VLAN and moving them to another when requested;
    • MAC Based: belonging to a Virtual LAN is not determined on priorities, but based on single hosts, depending on the MAC address that the administrator will configure as belonging to a VLAN. Compared to the previous solution, the MAC Based VLANs offer the benefit of always guaranteeing access to the same Virtual LAN independent of where you connect. This is greatly required, especially for laptops;
    • Authentication Based: belonging to a VLAN is determined based on the credentials of the user accessing a host. The most used protocol in this case, as for Wi-Fi authentication, is IEEE 802.1x (see FAQ on multi SSID in wireless access points).

    Note that the VLANS can also be composed using a combination of the aforementioned criteria.

  6. Terminology referring to Virtual LANs often refers to a trunk or trunking. What is it?
    When a single switch is not sufficient for a company, but the LAN extends over a set of them, the need arises to create Virtual LANs on each and enable communication between them. The first solution could be to use a port dedicated to the uplink for each VLAN. This would however lead to waste in terms of ports and cables; if the Virtual LANs common to two switches are n you must use n uplink cables. A better solution is to create a trunk or trunking: in other words, both switches are attributed a common port (trunk port) to all the VLANs that need to be transported. The switches tag each packet outbound of the trunk with a VLAN ID and each packet entering via trunking is forwarded on the right VLAN based on the VLAN ID. It is obvious that the two switches must use the same trunking protocol to communicate correctly via the trunk. There are different types of these protocols, which are often proprietary, and this could lead to inter-operational problems among different brands of switch that use the Virtual LANs. Yet, the most used trunking protocol is IEEE 802.1Q. The latter, for each Ethernet frame exiting the trunk configured port, adds 4 bytes and only 12 bits of which are used to identify the VLAN. The VLAN ID is therefore between 1 and 4094, considering 0 and 4095 are reserved values.
  7. In trunking protocol 802.1Q what is a Native VLAN?
    The Native VLAN of a switch is the VLAN whose packets transit untagged along a trunk as normal Ethernet frames. A Native VLAN is usually attributed VLANID 1.
  8. Does ZeroShell support VLAN IEEE 802.1Q?
    Yes, ZeroShell supports trunk protocol IEEE 802.1Q. For each network interface (Ethernet card, bridge, VPN LAN-to-LAN and VPN bond) it is possible to add one or more VLANs by specifying the VLANID between 1 and 4094. Practically, what you get is a virtual sub-interface whose name is the name of the main interface merged to the VLANID (separated by a point). For example, the VLAN 1250 applied on the ETH00 is represented by the logical interface ETH00.1250. To this VLAN, represented as a normal interface, you can add IP addresses, enable routing and NAT, apply firewall rules, attribute services such as DHCP, DNS or a Captive Portal.
  9. I configured a VLAN on a ZeroShell Ethernet port, but the packets that are too big don’t reach their destination. What does it depend on?
    Unfortunately, for a minority of Ethernet and FastEthernet cards there is no support for trunking 802.1Q within the Linux kernel. 802.1Q protocol includes a maximum size of 1522 byte (1518 normal + 4 for the tag) for Ethernet frames, while these drivers which aren’t compatible with the VLANs drop the packets greater than 1518 bytes considering them to be incorrectly formed. It is therefore recommend, after configuring the VLANs on the network, to test the functionalities by using ping with large packets.