To whom it concerns.
The below shows how to configure VLAN’s on Greenbone appliances running in the so-called Network Expert-Mode. It was put together due to the fact as of today the Greenbone 4.2 manual just hints to some extend on how to configure VLAN’s in None-Expert-Mode, which I myself haven’t verified. Nothing is stated about in the docs on how to configure this in Expert Mode. Hence this HowTo is also intended to save the reader some time to research the Internet, doing the trial-error-approach, or to open a ticket with Greenbone Support.
— The benchmarks of the new setup are, here on a GSM100 with four ports:
- Configure eth2 to an interface covering two VLAN’s. (1)
- The ID’s of the VLAN’s to use are VL111 and VL222. (2)
- ON VL111 the current settings (IP, mask etc.) to remain.
- ON VL222 the IP 10.99.222.56/32 on a /24 mask network additionally to be configured the appliance
- The VLANID’s to be reflected if possible in respective configuration files - like eth2.111 and eth2.222
- All other three interfaces to remain the same.
(1) If the interface about to be configured is the actual management interface used to access the system through ssh, use caution. Either these configurations to be done through the serial console OR temporarily another interface to be set as the management interface OR the management IP to be disabled at all, to be able to ssh-access the appliance through all interfaces for the time being. All depends on the actual network topology the appliance is in.
(2) I you are not maintaining the actual network infrastructure in your organisation your network administrator shall be able to tell you these VLANID’s.
(3) Also in respect to (2): Work closely with your network administrator, because him/her might have to implement changes on the other end (switch / router) in parallel, like changing the port from access port to trunk port and others.
(4) To configure all this here it is NOT required to enable the superuser account.
— Now let’s get started:
Login to the appliancce through ssh as (usually) admin user and in the GOS admin GUI go to …
Setup - Setup Menu
Network - Configure rthe Network settings
Edit - Edit the network configuration files
… which will give you shell access to the relevant directory containing the network configuration file like e.g.:
Use this shell to edit the network configuration.
You can use the 'nano' utility for that
The network service will be restarted once you exit the shell.
If you want to execute some network command during boot, simply
create a file 'bootscript' and this file will be executed during
the boot by using the Bash.
Type ^D (Ctrl-D), or 'exit' to return to the Greenbone OS Administration menu.
admin@mygsm001:/etc/network/interfaces.d$ ls -rtl
total 28
-rw-rw-r-- 1 admin admins 272 Jan 24 2018 eth0
-rw-rw-r-- 1 admin admins 77 Jan 24 2018 eth1
-rw-rw-r-- 1 admin admins 14435 Oct 8 12:34 eth3
-rw-rw-r-- 1 admin admins 89 Oct 12 10:46 eth2
admin@mygsm001:/etc/network/interfaces.d$ file ./eth*
./eth0: ASCII text
./eth1: ASCII text
./eth2: ASCII text
./eth3: ASCII text
admin@mygsm001:/etc/network/interfaces.d$
Next backup your current configuration by for instance just simply cat’ing the file of the interface about to change, here in our case eth2, and to copy/paste the content somewhere else locally on your machine.
admin@mygsm001:/etc/network/interfaces.d$ cat ./eth2
auto eth2
iface eth2 inet static
address 10.123.111.23
netmask 255.255.255.0
It is also advised to check the current status of the interface about to re-configure and also the routing table entries related to it:
admin@mygsm001:/etc/network/interfaces.d$ ip addr show eth2
5: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:07:32:2c:c3:19 brd ff:ff:ff:ff:ff:ff
inet 10.123.111.23/24 brd 10.123.111.255 scope global eth2
valid_lft forever preferred_lft forever
inet6 fe80::207:32ff:fe2c:c319/64 scope link
valid_lft forever preferred_lft forever
admin@mygsm001:/etc/network/interfaces.d$ ip route | grep eth2
10.123.111.0/24 dev eth2 proto kernel scope link src 10.123.111.23
Finally and next edit the configuration file (eth2)´:
admin@mygsm001:/etc/network/interfaces.d$ vi ./eth2
... ...
...
And after doing the desired changes the file should look in our example like that:
admin@mygsm001:/etc/network/interfaces.d$ cat ./eth2
auto eth2
iface eth2 inet manual
# VL111
auto eth2.111
iface eth2.111 inet static
address 10.123.111.23
netmask 255.255.255.0
vlan-raw-device eth2
# VL222
auto eth2.222
iface eth2.222 inet static
address 10.99.222.56
netmask 255.255.255.0
vlan-raw-device eth2
Based on the /etc/os-release file the Greenbone OS (GOS) is a Debian style Linux. Researching the Internet on how to configure VLAN’s trunking on Debian-style-Linux one often finds also additional settings to be done, like putting an entry into /etc/modules to load the 8021q module etc. Based on Greenbone Support additional configuration steps are not required to be undertaken here on the customised GOS, all such being loaded statically into the Kernel. And which proofed at the end as being correct in my organisation.
However and to actually apply the changes just done, exit the CLI / ssh shell by simply pressing CTRL-D or typing “exit” …
admin@mygsm001:/etc/network/interfaces.d$ exit
… which returns one to the GOS admin menu.
Only after that the new configurations actually will be applied, as one can also see / monitor in the r/syslog of the system, a typical excerpt below, after exit’ing the shell:
... ...
...
2018-10-19T11:41:46+02:00 mygsm001 system: Starting 'systemctl restart networking ' ...
2018-10-19T11:41:46+02:00 mygsm001 sudo: admin : TTY=unknown ; PWD=/home/admin ; USER=root ; COMMAND=/bin/systemctl restart networking
2018-10-19T11:41:46+02:00 mygsm001 sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
2018-10-19T11:41:46+02:00 mygsm001 systemd[1]: Stopping LSB: Raise network interfaces....
2018-10-19T11:41:46+02:00 mygsm001 kernel: e1000e: eth3 NIC Link is Down
2018-10-19T11:41:46+02:00 mygsm001 kernel: e1000e: eth1 NIC Link is Down
2018-10-19T11:41:46+02:00 mygsm001 networking[2084]: Deconfiguring network interfaces...done.
2018-10-19T11:41:46+02:00 mygsm001 systemd[1]: Starting LSB: Raise network interfaces....
2018-10-19T11:41:46+02:00 mygsm001 networking[2168]: Configuring network interfaces...RTNETLINK answers: File exists
... ...
...
2018-10-19T11:41:47+02:00 mygsm001 kernel: IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
2018-10-19T11:41:47+02:00 mygsm001 kernel: 8021q: adding VLAN 0 to HW filter on device eth1
2018-10-19T11:41:47+02:00 mygsm001 systemd[1]: Reloading OpenBSD Secure Shell server.
2018-10-19T11:41:47+02:00 mygsm001 sshd[1131]: Received SIGHUP; restarting.
2018-10-19T11:41:47+02:00 mygsm001 systemd[1]: Reloaded OpenBSD Secure Shell server.
2018-10-19T11:41:47+02:00 mygsm001 sshd[1131]: Server listening on 0.0.0.0 port 22.
2018-10-19T11:41:47+02:00 mygsm001 sshd[1131]: Server listening on :: port 22.
2018-10-19T11:41:47+02:00 mygsm001 systemd[1]: Reloading OpenBSD Secure Shell server.
2018-10-19T11:41:47+02:00 mygsm001 sshd[1131]: Received SIGHUP; restarting.
... ...
...
2018-10-19T11:41:48+02:00 mygsm001 networking[2168]: done.
2018-10-19T11:41:48+02:00 mygsm001 systemd[1]: Started LSB: Raise network interfaces..
2018-10-19T11:41:48+02:00 mygsm001 sudo: pam_unix(sudo:session): session closed for user root
... ...
...
2018-10-19T11:41:50+02:00 mygsm001 kernel: e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
2018-10-19T11:41:50+02:00 mygsm001 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready
Accessing the shell through “Edit - Edit the network configuration files” again and running the below command, returns something different than earlier and further above:
admin@mygsm001:/etc/network/interfaces.d$ ip addr show eth2
5: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:07:32:2c:c1:e3 brd ff:ff:ff:ff:ff:ff
inet6 fe80::207:32ff:fe2c:c1e3/64 scope link
valid_lft forever preferred_lft forever
The following command however returns additional sub-interfaces of eth2 on the system …
admin@mygsm001:/etc/network/interfaces.d$ ip addr show | grep eth2
5: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
9: eth2.111@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.123.111.23/24 brd 10.123.111.255 scope global eth2.111
10: eth2.222@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.99.222.56/24 brd 10.99.222.255 scope global eth2.222
… their details looking like below:
admin@mygsm001:/etc/network/interfaces.d$ ip addr show eth2.111
9: eth2.111@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:07:32:2c:c1:e3 brd ff:ff:ff:ff:ff:ff
inet 10.123.111.23/24 brd 10.123.111.255 scope global eth2.111
valid_lft forever preferred_lft forever
inet6 fe80::207:32ff:fe2c:c1e3/64 scope link
valid_lft forever preferred_lft forever
admin@mygsm001:/etc/network/interfaces.d$ ip addr show eth2.222
10: eth2.222@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:07:32:2c:c1:e3 brd ff:ff:ff:ff:ff:ff
inet 10.99.222.56/24 brd 10.99.222.255 scope global eth2.222
valid_lft forever preferred_lft forever
inet6 fe80::207:32ff:fe2c:c1e3/64 scope link
valid_lft forever preferred_lft forever
And the routing table entries tied to the eth2.* interface should look like below
admin@mygsm001:/etc/network/interfaces.d$ ip route | grep eth2
10.123.111.0/24 dev eth2.111 proto kernel scope link src 10.123.111.23
10.99.222.0/24 dev eth2.222 proto kernel scope link src 10.99.222.56
In respect to the routing we had in the first place the problem the system not being able to reach other hosts (ping, ssh) in the newly configured network, tied here to the eth2.222 interface. At the end a complete graceful reboot of the appliance through the admin GUI resolved this too.
I hope this little HowTo might be helpful for someone perhaps moving forward, though use at own risk and/or consult the Greenbone Support in case not sure or you have more complex configurations to implement in your network environment.
This was applied so on a GSM100 being on the 4.2.21 release.
Last not least: In the GSM / end-user GUI you will also sooner or later notice under Extras|Performance additional RRDTOOL graphs for the newly configured (sub)interfaces. Though I cannot say, whether they appeared right “on the spot” post-configs through the admin GUI or just after the reboot we did in respect to the little challenge with the routing table there.