Category: Networking

The Networking category contains posts relating to network operations, administration, management, and provisioning.

Networking

FTP Access to the MikroTik RouterBOARD 1100 AHx2

The MikroTik RouterBOARD 1100 AHx2 (RB1100AHx2) is 1U rackmount gigabit ethernet router with a dual core CPU. It can reach up to a million packets per second and supports hardware encryption. This post describes how to access the MikroTik 1100 AHx2 using FTP (File Transfer Protocol). FTP access is desirable in order to update the RouterOS software or perform other activities. The FTP client FileZilla will be used to describe the steps necessary, but you can use any FTP client.

The versions of software discussed in this post are as follows:

  • Windows 10 Pro
  • RouterOS 6.42.10 (long-term)
  • Filezilla client 3.39

Lets get started…

Start by downloading and installing the FileZilla client. Once installed open the Filezilla client and navigate to File -> Site Manager, select “New Site” and create a name for the entry (e.g., “MikroTik”). Set the Protocol to “SFTP – SSH File Transfer Protocol” and the Logon Type to “Normal”. Enter the user name and password. If you have not changed these on the MikroTik 1100 AHx2 then the user name will be admin and the password field should be left blank (See Figure 1).

Screenshot showing the FileZilla client configuration for FTP access to the MikroTik router

Figure 1

Select “Connect” and you should be connected.

That’s it. A couple of minutes with the venerable FileZilla FTP client and you have FTP access to the MikroTik 1100 AHx2.

Networking

How to Install and Configure MRTG on FreeBSD

In a previous post I described how to install and configure Tobi Oetiker’s MRTG (Multi Router Traffic Grapher) on a Ubuntu server. In this post I will describe how to install and configure it on FreeBSD. Once configured, you’ll be able to use MRTG to monitor the traffic in and out of your network using the SNMP capability in your network’s gateway/router. MRTG generates static HTML pages containing PNG images which provide a visual representation of this traffic. MRTG typically produces daily, weekly, monthly, and yearly graphs. MRTG is written in perl and works on Unix/Linux as well as Windows. MRTG is free software licensed under the GNU GPL.

Software versions used in this post were as follows:

  • apache24 2.4.23
  • FreeBSD 11.0-RELEASE
  • mrtg-2.17.4

The steps discussed assume that the FreeBSD Ports Collection is installed. If not, you can install it using the following command:

If the Ports Collection is already installed, make sure to update it:

Okay, let’s get started. All commands are issued as user root. When building the various ports you should accept the default configuration options.

Install a http server

MRTG requires an http server to be installed and operating correctly. In our example, we’ll install and use the Apache http server. Navigate to the Apache port and build it:

Once Apache has been successfully installed, Use the sysrc command to add the following line to /etc/rc.conf so that the Apache server will start automatically at system boot:

Now let’s start Apache to make sure it works:

Point your web browser to the host name or IP address of the FreeBSD host you’ve installed Apache on and you should see the venerable “It works!”

Install and configure MRTG

Now that we have an http server up and running let’s install MRTG:

What does the MRTG port install and where is that stuff located?

MRTG provides the example configuration file /usr/local/etc/mrtg/mrtg.cfg.sample that describes global configuration parameters as well as various configuration options for the SNMP targets you want to monitor. If you already have some experience with MRTG and SNMP you can simply copy or move this file to /usr/local/etc/mrtg/mrtg.cfg then modify it to meet your requirements. In our example, however, we’re going to create the requisite mrtg.cfg file from scratch.

MRTG includes the script cfgmaker that will create and populate a basic mrtg.cfg file with information obtained from your gateway/router. So, before running /usr/local/bin/cfgmaker, you should activiate and configure the SNMP service in your gateway/router. This typically involves logging into the device and enabling SNMP. The default SNMP community name is typically “public.” If you change the SNMP community name to something else, make note of it. Now, let’s run cfgmaker, substituting your SNMP community name if you’ve changed it, and adding the IP address of your gateway/router:

If you would like to add more than one device to mrtg.cfg simply append the additional URL(s) to the same mrtg.cfg file. Then, when you build the web page using the indexmaker command described below, graphs associated with each device will be displayed on the same HTML page:

Next, open /usr/local/etc/mrtg/mrtg.cfg and, under Global Config Options, uncomment the line WorkDir: /home/http/mrtg and change it to WorkDir: /usr/local/www/apache24/data/mrtg. This is the directory from which the Apache http server will server the MRTG html pages. If you’re using something other than Apache as your http server then you’ll need to change this path.

Next, uncomment the line Options[_]: growright, bits. By default MRTG graphs grow to the left, so the option growright specifies that the direction of the traffic visible in MRTG’s graphs flips causing the current time to be at the right edge of the graph and the history values to the left. The option bits specifies that the monitored traffic values obtained from your device is multiplied by 8 and displayed bits per second instead of bytes per second.

MRTG includes the script indexmaker. This is what we’ll use to create the pages used to display the MRTG graphs. First, let’s create the directory from which Apache http server will serve up the pages:

Then use indexmaker combined with our mrtg.cfg file to create and populate an index.html file in that directory:

Now we need to add an Alias and a Directory directive to Apache’s configuration file to support MRTG. Open /usr/local/etc/apache24/httpd.conf and add the following lines in the section containing similar Directory directives, or it can simply be appended to the bottom of the file:

And change the user and group for the following directories to mrtg:

Finally, let’s restart the http server:

Starting MRTG

Okay, now that MRTG has been installed and configured let’s start it up and see what it displays. Use the sysrc command to add following line to /etc/rc.conf:

Then start the MRTG daemon:

The MRTG daemon will now run automatically each time FreeBSD starts.

Now point your browser to http://your-http-server-address/mrtg and you should see a page that resembles Figure 1. You may have more or less graphs depending on the number of interfaces reported by your devices(s).

Screenshot showing the web page generated by MRTG

Figure 1

You’ll see the graph starting to “grow” to the right as the traffic is monitored over time, and the Y axis displayed as bits per second. If you click on any one of these graphs you’ll be taken to differnt page showing individual graphs for 30 minute, two hour, and daily averages, along with the maximum, average, and current bit rate in and out of that particular interface. By default, these graphs will update every 5 minutes.

Only interested in displaying one particular interface? Want to graph other SNMP data? Now that you that you have a basic mrtg.cfg file created you can modify it or incorporate some of the global and target parameter examples contained in the file /usr/local/etc/mrtg/mrtg.cfg.sample to further customize your configuration. Just remember to run indexmaker again to update the MRTG index.html file.

Conclusion

This concludes the post on how to install and configure MRTG on FreeBSD. As you can see, MRTG isn’t terribly complicated and proves to be a really nice port for monitoring and graphing traffic in and out your gateway/router. For a full list of all the configuration options and other information I encourage you to visit the MRTG web site.

References
http://oss.oetiker.ch/mrtg/doc/index.en.html

Networking

How to Assign Static IP Addresses to OpenVPN Clients in pfSense

(20180407 – The steps in this post were amended to address changes in recent versions of software — iceflatline)

This post describes how to configure the OpenVPN server in pfSense to assign static IP addresses to its remote access client hosts.

pfSense (i.e., “making sense of packet filtering”) is a customized version of FreeBSD tailored specifically for use as a perimeter firewall and router, and can be managed entirely from a web-based or command line interface. In addition to being a firewall and routing platform, pfSense includes a long list of other features, as well as a package system allowing its capabilities to be expanded even further. pfSense is free, open source software distributed under the BSD license.

OpenVPN is a lightweight VPN software application supporting both remote access and site-to-site VPN configurations. It uses SSL/TLS security for encryption and is capable of traversing network address translation devices and firewalls. The OpenVPN community edition is free, open source software and portable to most major operating systems, including Linux, Windows 2000/XP/Vista/7, OpenBSD, FreeBSD, NetBSD, Mac OS X, and Solaris. It is distributed under the GPL license version 2.

All steps involved assume that pfSense and its OpenVPN server are installed and operating correctly. The versions for the software used in this post were as follows:

  • pfSense 2.4.3

Let’s get started…

Log into pfSense’ “webConfigurator” interface and navigate to VPN->OpenVPN. Select the icon to edit the server and ensure that the value for “Topology” under “Client Settings” is set to “net30 – Isolated /30 network per client”, then select “Save”.

Now connect to your pfSense firewall using SSH and open /var/etc/openvpn/server1.conf. Ensure that this configuration file contains the following line pointing to a valid directory for containing OpenVPN client host configuration files. The default directory in pfSense for this purpose is /var/etc/openvpn-csc/server1. You can change this directory if you wish but for our example we’ll retain the default:

In this directory we will create a file for each remote access client host we want the OpenVPN server to assign a static IP address to. The file name of each file must be the same name as the client host’s OpenVPN SSL certificate. For example, if you would like to configure a static IP for a client host with the certificate name “bob” then create the following file:

Open this newly created file and add the following line, which contains a pair of IP addresses from the IPv4 virtual network you’ve configured for private communications between the OpenVPN server and your client hosts. Note that you cannot use just any pair of addresses from within this subnet. Each pair of ifconfig-push addresses represent the OpenVPN client and server IP endpoints. They must be taken from successive /30 subnets in order to be compatible with Windows client hosts and the TAP-Windows driver. Specifically, the last octet in the IP address of each endpoint pair must be taken from set defined in the “Configuring client-specific rules and access policies” section of the OpenVPN HOWTO. In this example, our OpenVPN server is using the virtual network 192.168.20.0/24 and we’ve chosen an appropriate pair of endpoint addresses to use from this subnet. Note that the first IP address in following line is the IP address assigned to the client host, the second is the address the server uses:

Once you’ve added this line to /var/etc/openvpn-csc/server1/bob you’ll need to restart the OpenVPN server in pfSense. You can do this from Status->Services in the pfSense “webConfigurator” interface.

Note that any files added to /var/etc/openvpn-csc/server1 will be deleted by the system if it reboots. To protect these files you can use the chflags utility to set the system immutable flag on the file. Once this flag is set, no one can delete or modify file, including root. You must be the root user to set or clear the immutable flag:

To verify that the immutable flag has been set:

Output:

To clear the immutable flag:

Conclusion

There you have it. Some minor configuration of your pfSense machine and its OpenVPN server will start assigning static IP addresses to the remote access client hosts you designate.

References

http://openvpn.net/index.php/open-source/documentation/howto.html

Networking

How To Create And Configure VLANs In pfSense

(20171231 — The steps in this post were amended to address changes in recent versions of software. Minor editorial corrections were also made — iceflatline)

pfSense is a customized version of FreeBSD tailored specifically for use as a perimeter firewall and router, managed entirely from a web browser or command line interface. pfSense includes a long list of other features, as well as a package system allowing its capabilities to be expanded even further. pfSense is free, open source software distributed under the BSD license.

A VLAN (“Virtual Local Area Network”) is a logical grouping of network hosts (and other resources) connected to administratively defined ports on a switch. This enables hosts to communicate as if the attached to the same physical medium, when in fact they may actually be located on different LAN segments. A VLAN is treated like its own subnet or broadcast domain, which means that Ethernet frames broadcast onto the network are only switched between the ports logically grouped within the same VLAN.

In this post I will describe how to create and configure a VLAN in pfSense. Once configured, you’ll be able to route (or prevent routing) traffic between this VLAN and other VLANs, and each VLAN will be able to share the same Internet connection. To help explain the steps involved, we’ll create a static VLAN on a 24-port switch and trunk that VLAN from the switch to the LAN interface on pfSense, where we will assign the VLAN a unique /24 private IP subnet.

All steps involved assume that: 1) pfSense is installed correctly and providing basic Internet connectivity to an existing LAN interface; 2) the NIC (“Network Interface Controller”) assigned to the LAN interface supports IEEE 802.1Q VLAN tagging; and, 3) the switch connected to the LAN interface is capable of supporting the creation, configuration and trunking of port-based VLANs.

The software versions used in this post were as follows:

  • 2.4.2-RELEASE-p1 (amd64)

The switch used in this post was a Cisco model SG200-26; a so-called “smart switch,” featuring, among other things, Gigabit Ethernet, a web-based management interface, and simultaneous support for up to 256 port-based and IEEE 802.1Q tag-based VLANs.

Each switch, and its associated management interface is different; therefore, you’ll need to make the appropriate adjustments when following the instructions in this post in order to successfully configure your particular switch.

Let’s get started…

Configuring the Switch

As you may recall, static VLANs, often referred to as “port-based” VLANs, are created by assigning switch ports to a preconfigured VLAN identifier. In this example, we’ll configure a static VLAN on our switch and assign it VLAN ID 50. Note that you can use any positive integer between 2 and 4094 you’d like for your VLAN ID, however, VLAN IDs 1 and 4095 should be avoided because, as a general rule, most switches by default assign all ports to VLAN ID 1, the “administrative” VLAN ID, and VLAN ID 4095 as the “discard” VLAN.

Begin by navigating to VLAN Management->Create VLAN and select “Add.” Enter a value of 50 in the “VLAN ID” field and enter a name to denote this particular VLAN in the “VLAN Name” field. In this example, we’ve used the name “vlan50.” When complete, select “Apply”. (See Figure 1)

Screenshot showing the creation of a new VLAN ID 50 in the Cisco SG200-26 switch

Figure 1

Before assigning membership of a particular port to our new VLAN, we must first configure that port to be either an “Access” port or a “Trunk” port. Access ports are ports that are members of only one VLAN. This type of port is normally used for attaching end devices which are generally unaware of a VLAN membership, either because their NIC is incapable of tagging Ethernet frames a VLAN ID, or they are not configured to do so. Switch ports configured as Access ports remove any VLAN information from the Ethernet frame before it is sent to the device. Trunk ports on the other hand can carry multiple VLAN traffic, and are normally used to connect switches to other switches or to routers. It is very often the case that small-business grade switches, such as the Cisco SG200, designate each port as a Trunk port by default.

To keep our example simple, we’ll assume that the device(s) connected to the switch are not configured, or are unable to be configured, to tag Ethernet frames with a VLAN ID. Consequently, in this example, we’ll configure port 19 as an Access port, and assign it membership in our newly created VLAN. Furthermore, we’ll also assume that port 25 is currently being used to connect the switch to the pfSense LAN interface, and configure it as a Trunk port, assigning it membership in our newly created VLAN.

Navigate to VLAN Management->Interference Settings, select port 19 and then select “Edit”. Change the Interface VLAN Mode from Trunk to Access, then select “Apply” (See Figure 2). Now follow similar steps to configure port 2 as an Access port.

Screenshot showing port 19 being configured as an Access port in the Cisco SG200-26 switch

Figure 2

Next, navigate to VLAN Management->Port VLAN Membership, select port 19 and then select “Join VLAN”. Since Access ports can be added as untagged to only a single VLAN, we’ll need to first remove the default VLAN the switch automatically assigns to each port (usually VLAN 1). Highlight VLAN 1 by left-clicking on it, then select the arrow icon to remove it from the interface. Now highlight VLAN 50 by left-clicking on it, then select the arrow icon to add it to the interface, ensuring that “Untagged” is selected from among the options under “Tagging”. Select “Apply” when completed (See Figure 3).

Screenshot showing port 19 being joined to VLAN 50 in the Cisco SG200-26 switch

Figure 3

With switch port 19 configured as an Access port and joined to VLAN 50 any Ethernet frames that enter that port will be tagged with the appropriate VLAN ID. Now let’s configure the port 25, the port that is connected to the LAN NIC in pfSense. This port will be configured as a Trunk port and joined to VLAN 50 so that, in addition to passing the Ethernet frames from from devices attached to the other ports on the switch to pfSense, it will also pass Ethernet frames tagged with VLAN ID 50 entering switch port 19.

Ensure that port 25 is configure as a Trunk port, then navigate to VLAN Management->Port VLAN Membership, select port 25 and then select “Join VLAN”. Highlight VLAN 50 by left-clicking on it, then select the arrow icon to add it to the interface, ensuring that “Tagged” is selected from among the options under “Tagging”. Select “Apply” when completed (See Figure 4).

Screenshot showing port 25 being joined to VLAN 50 in the Cisco SG200-26 switch

Figure 4

That’s it for configuring the switch. If your switch supports both a running configuration and a startup configuration, make sure to save the changes you’ve made to the startup configuration so that they are not lost should the switch reboot for any reason.

Configuring pfSense

Now we need to create and configure VLAN 50 in pfSense. Navigate to Interfaces->Assignments and make note of the device driver name assigned to the LAN NIC. For this example we’ll assume the device driver name is “em1” (See Figure 5). The LAN interface will serve as the “parent interface” for the VLAN interfaces we will create in the next step.

Screenshot showing the device driver name assigned to the LAN NIC in pfSense

Figure 5

Next, navigate to Inerfaces->Assignments->VLANs and select the “+ Add” icon. In the subsequent screen, select “em1”, the LAN NIC interface, from among the options in the drop down list under “Parent interface”, and enter the value of 50 under “VLAN tag”. Add an optional description for this VLAN under “Description”, then select “Save” (See Figure 6).

Screenshot showing the configuration of a VLAN interface in pfSense

Figure 6

After creating the VLAN interface, return to Interfaces->Assignments and select the “+ Add” icon to add the “VLAN 50 on em1-lan (VLAN 50)”, then select “Save” (See Figure 7). At this point you’ll notice that under the “Interface” column pfSense has likely denoted VLAN 50 as an optional or “OPT” interface. Don’t worry, we’ll address that next.

Screenshot showing the addition of a VLAN interface in pfSense

Figure 7

For this example we’ll assume that pfSense has assigned VLAN 50 as OPT4. Navigate to Interfaces->OPT4 and select “Enable Interface”. Under “Description” replace “OPT4” with “VLAN 50”, then select “Static IPv4” from among the options in the drop down list under “IPv4 Configuration Type”. We’ll use network 192.168.50.0/24 for VLAN 50 by assigning the static IP address 192.168.50.1 on this interface, and selecting the network mask of “24” under the “Static IP Configuration” section. The other parameters can remain at their default values. Select “Save” and “Apply changes” when complete (See Figure 8). Now if you navigating back to Interfaces->Assigments you will see VLAN 50 listed and labeled with the description you added when enabling the interface in the previous steps.

Screenshot showing the VLAN 50 interface being enabled in pfSense

Figure 8

Next, we need to build a firewall rule for our two new VLANs so that traffic can pass to / from the WAN interface, and by extension, to the Internet. Navigate to Firewall->Rules and select the VLAN 50. Select the “Add” icon (there are currently no rules so either Add icon will work) to create a new rule. For our example, we’ll build a simple outbound pass rule for any protocol in VLAN 50, similar to the way a typical LAN outbound pass rule would be configured. Select “any” from among the options in the drop down list Under “Protocol”, and under “Source” select “VLAN50 net” from among the options in the drop list. If desired, you may enter a description of this newly created rule for your reference under “Extra Options”. The other parameters can remain at their default values. Select “Save” and “Apply changes” when complete (See Figure 9).

Screenshot showing the creation of a firewall rule for VLAN 50 in pfSense

Figure 9

Unless you plan to assign static IP addresses to host devices, you’ll want to configure a DHCP server for the new VLAN 50. Navigate to Services->DHCP server and select VLAN 50. Select “Enable DHCP server on VLAN50 interface”, then enter the range of IP addresses within the network 192.168.50.0/24 you’d like the DHCP server to use under “Range”. Finally, pfSense will use the IP address assigned to this interface as the gateway address by default. For our example this address will be 192.168.50.1. If your requirements call for something different, enter an IP address for the network gateway under “Gateway”. The other parameters can remain at their default values. Select “Save” when complete (See Figure 10).

Screenshot showing the creation and configuration of a DHCP server for VLAN 50 in pfSense

Figure 10

You’ll also want to navigate to Services->DNS Forwarder->Interfaces and ensure that interfaces used by the DNS Forwarder for responding to queries from clients includes VLAN50, then select “Save” and “Apply changes” when complete (See Figure 11).

Screenshot showing the inclusion of the VLAN 50 interface in the DNS Forwarder in pfSense

Figure 11

Wrapping up

At this point the LAN switch and pfSense should be configured to support VLAN 50. To test, connect a host device such as a desktop or laptop computer to port 19 on the switch. If you’ve configured everything as described, you should receive an IP address within the DHCP address range you’ve specified for VLAN 50 network 192.168.50.0/24. The default gateway, DHCP server and DNS server addresses should be 192.168.50.1. You should also have Internet connectivity.

Be aware that as currently configured, each VLAN is routed to all other VLANs. If you would like to disallow some or all traffic to/from a particular VLAN you must create firewall rules explicitly stating what traffic should not be routed. Keep in mind that pfSense evaluates firewall rules on a first-match basis (i.e. the action of the first rule to match a packet will be executed). So, for example, if you wanted to block all VLAN 50 traffic from reaching the LAN you might create a rule to that effect before the one we created previously to route all VLAN 50 traffic to any destination (See Figure 12).

Screenshot showing the placement of a firewall rule blocking all traffic in VLAN 50 from reaching the LAN in pfSense

Figure 12

Conclusion

VLAN support in pfSense is not hard to configure nor complicated to manage, assuming your switch and NICs support this capability. To help explain the steps involved, we created a static VLAN on a commodity 24-port small-business switch and trunked that VLAN to the LAN interface on pfSense. We then created and added the VLAN interface, created the requisite firewall rules, and assigned the VLAN a unique /24 private IP subnet with host addressing handled using DHCP. The VLAN is able to share the pfSense’s Internet connection and we are able further configure pfSense to prevent routing traffic between each VLAN, if desired.

Networking

How To Access Your VirtualBox Guest VM From The Host Using SSH

(20180430 — The steps in this post were amended to address changes in recent versions of software — iceflatline)

Recently I had the occasion to spin up a Ubuntu server Virtual Machine (“VM”) in VirtualBox on a Windows-based host machine. Those of you who have performed a similar excercise know that the default window size that VirtualBox provides to command-line-based VMs, like *BSD and Ubuntu server, etc., is rather small, somewhere in neighborhood of the standard VGA resolution of 640 x 480 pixels. Normally the fix for this, of course, would be to install what VirtualBox calls “Guest Additions,” which consists of device drivers and other applications that optimize the guest operating system for, among other things, the ability to enlarge the window size. However, getting Guest Additions to install and run properly on command-line-based guest VMs is a monumental pain in the ass. One work-around that seems to work fairly well is to switch the VM window to “scale mode” (View->Switch to Scale Mode or Host+C), resulting in what is essentially a magnified version of the window and its contents. An even better solution, in my opinion, is to configure the VM so that you can connect to it directly from the host machine using Secure Shell (“SSH”), giving you full control over the window and text size of the guest VM.

This post explains how to access a VirtualBox Ubuntu server guest VM from the VirtualBox host machine using SSH. It then goes on to explain how to accomplish the same task when using a FreeBSD guest VM. The software versions used in this post were as follows:

  • FreeBSD 11.0-RELEASE
  • Ubuntu Server 18.04 LTS
  • VirtualBox 5.2.6

Let’s get started…

First, let’s add a new “VirtualBox Host-Only Ethernet Adapter” in VirtualBox. This new adaptor will allow us to enable a private network consisting of our host machine and our guest VM. The host can connect to any guest VMs configured to use this adaptor, and they can connect to each other, but nothing outside of this virtual network will be permitted access.

Navigate to Files->Preferences->Network and click on the “+” icon to add new adaptor. You’ll see that VirtualBox creates a new adaptor called “VirtualBox Host-Only Ethernet Adapter #2” (See Figure 1).

Screenshot showing the creation of a VirtualBox Host-Only Ethernet Adapter in VirtualBox

Figure 1

Right now you might be thinking “but couldn’t I just use the existing default VirtualBox Host-Only Ethernet Adaptor?” You absolutely could; however, setting up a second one allows you to customize it to your liking, leaving the default adaptor in its default configuration as a fallback.

Now, double-click the new adaptor (or highlight it and select the edit icon) and note the IP address and subnet mask (e.g., 192.168.135.1 and 255.255.255.0) that VirtualBox has arbitrarily assigned under the “Adapter” tab. You may change these network parameters if desired, however, it is preferable to retain “1” as the value of the last octet in the IP address (See Figure 2).

Screenshot showing the IP address and subnet mask assignment in the VirtualBox Host-Only Ethernet Adapter #2

Figure 2

Optionally, you may configure a DHCP server on the VirtualBox Host-Only Ethernet Adapter #2 so that the guest VM obtains an IP address automatically at boot time. This can be accomplished by navigating to Files->Preferences->Network, double-clicking the new adaptor (or highlighting it and selecting the edit icon), selecting the “DHCP Server” tab and the selecting “Enable Server”. You’ll then need to modify the various DHCP server parameters (e.g., Server Address, Server Mask, etc.), keeping in mind that they should encompass the IP address configured for the adaptor, else the IP address should be modified so that it lies within the DHCP server parameters you’ve configured. When finished, select “OK” (See Figure 3). Note: I typically forgo using the DHCP server, electing instead to use a static IP address. That way, I can consistently use the same address each time I want use SSH to connect to the guest VM.

Screenshot showing the DHCP server configuration tab in the VirtualBox Host-Only Ethernet Adapter #2

Figure 3

Let’s configure our Ubuntu server VM so that it will use the new VirtualBox Host-Only Ethernet Adapter #2. Shutdown the Ubuntu server VM if it’s running. Right-click on the VM and select Settings->Network. Select the “Adapter 2” tab, then select “Enable Network Adapter”. From among the options under “Attach to:”, select “Host-Only Adapter”, then select “VirtualBox Host-Only Ethernet Adapter #2” from among the options under “name:”. Now select “OK” (See Figure 4).

Screenshot showing the selection of VirtualBox Host-Only Ethernet Adapter #2 for use by the Ubuntu server virtual machine

Figure 4

Now start the Ubuntu server VM. After the system has fully booted, login to the VM at the VirtualBox console window and execute the command ifconfig -a to list all network devices. In addition to your primary network device, enp0s3 (in this example), you should now see a second network device listed, enp0s8 (in this example). If you chose to setup a DHCP server when creating VirtualBox Host-Only Ethernet Adapter #2, then enp0s8 should already have an IP address assigned to it from among the pool of addresses you chose to use with setting up the DHCP server, in which case you should make a note of this address and use it to connect to the Ubuntu server VM using SSH.

If you elected not to setup a DHCP server when creating VirtualBox Host-Only Ethernet Adapter #2, then you’ll need to assign a static IP address to network device enp0s8. First, install the package ifupdown:

Then open /etc/network/interfaces as the root user and add the following lines, making sure to change the values shown in this example so that they fall within the IP subnet parameters chosen when creating the new VirtualBox Host-Only Ethernet Adapter #2:

Now start the interface so that it obtains the new network parameters:

At this point you should be able to connect to the Ubuntu server VM via SSH using this static IP address.

FreeBSD Guest VM

A similar approach can be taken for a FreeBSD guest VM. The setup and configuration of the VirtualBox Host-Only Ethernet Adapter in VirtualBox is identical to what has been described thus far for the Ubuntu server VM. However, in order to assign a static IP address to the new network interface, em1 in the case of FreeBSD, you’ll need to open /etc/rc.conf as the root user and add the following line, making sure to change the values shown in this example so that they fall within the IP subnet parameters chosen when creating the new VirtualBox Host-Only Ethernet Adapter #2:

Then restart the interface so that it obtains the new network parameters:

Conclusion

The default window size that VirtualBox provides to command-line-based guest VMs like BSD and Ubuntu servers is typically very small, resulting in a poor user experience for those administrators trying to perform work beyond just a few quick simple commands. Fortunately, VirtualBox can be configured so that the user can connect directly to a guest VM from the host machine using SSH, giving the user full control over window and text sizing.