Lab 01 ‐ pfSense and Proxmox configuration - Sleeeee/t301-admin-III GitHub Wiki

The infrastructure we will start off from is already virtualized inside Proxmox, which means we will first have to understand what it implies before installing Proxmox on our dedicated (virtualized) hypervisor. Here is the infrastructure that has been initialized before this lab :

Figure 01-01 : State of the infrastructure before the lab

By the end of this lab, we will have installed and configured pfSense on the firewall node fwns1101, installed and configure the first hypervisor hyps1101 and started a VM inside it :

Figure 01-02 : State of the infrastructure after the lab

The objective of this lab is to configure our firewall and setup Proxmox on a hypervisor. All these actions can be performed from the management LAN stuMgm. However, that subnet is not available to the outside, so the solution is to use a jump server that is open to the Internet and is part of the stuMgm subnet. To access that jump server, we will use the Remote Desktop Protocol (RDP).

For Windows users, there is a built-in RDP client called Remote Desktop Connection. Remmina is available on most Linux distributions. Remote Desktop Manager is a solution available for MACOS as well as the other common operating systems.

We can use our dedicated stu11 user with the default password Test1234! on port 33893, as indicated in the lab notes :

Figure 01-03 : Remmina profile configuration

We can now use that gateway to the stuMgm LAN. We can then update our password to something more secure and private.

The jump server is only available from the EPHEC network. This means that we will need to be inside EPHEC (or use the VDI service) to join any machine inside the management subnet (that is not accessible from the outside of course).

From the jump server, we can reach the hypervisor's management web page at https://hyp-01.lab.ephec-ti.be and authenticate using the same credentials and selecting the Proxmox VE authentication server method.

From hyp-01's web interface, we can see that the machines have already been created for us on hyp-03 :

Figure 01-04 : Overview of the machines created on hyp-03

Note that the web interface is named hyp-01, but the actual hypervisor our virtual machines reside in is hyp-03.

We will first configure the pfSense firewall. To prepare for that, we first need to fetch the MAC addresses and the subnets they are linked to :

Figure 01-05 : pfSense login interface

Below is the IP addressing we will be using to configure the firewall :

• Gateway / DNS server : 172.31.90.254
• WAN (stuWan) : 172.31.90.11 - bc:24:11:02:96:8a
• LAN (stuMgm) : 172.31.80.211 - bc:24:11:46:a3:86
• OPT1 (stuVmNet) : No IP - bc:24:11:98:19:c3
• OPT2 (stuVmNet VLAN 110) : 10.11.0.254

The WAN interface will be obviously used to reach the outside. The LAN interface resides in our management subnet, and the OPT1 interface will act as a default gateway for the VMs we will be virtualizing inside Proxmox, therefore it is placed in the stuVmNet network.

In order to install pfSense, we can click on the console tab and follow the installation process. Throughout the whole process, any DHCP-related configuration option is to be disabled ! IPv6 is none of our concern either. When prompted to revert to HTTP, decline.

We only need the WAN interface to be configured during the installation process. The other two interfaces can be configured afterwards in the shell by choosing option 2 Set interface(s) IP address.

Once the install is complete, and the interfaces are properly configured, the firewall now exposes a web page that we can access from the jump server using its stuMgm IP address, 172.31.80.211. The base credentials are admin for the username, and pfsense for the password.

The first thing we can do is to create a VLAN with ID 110, and assign it to our OPT1 (stuVmNet) interface, from the Interfaces > Assignments > VLANs menu. We now have 4 interfaces, but they still have very ambiguous names. To make our lives easier, we will rename LAN to MGM because it is on the management subnet, and OPT1 to VmNets, because it will be reached by the VMs inside our hypervisor :

Figure 01-06 : State of the renamed firewall interfaces

Now that all our interfaces are created and sorted out, we can jump to the OPT2 configuration mode (found in Interfaces) and assign the right addressing to the interface as can be found above.

For now, we will simply allow all traffic through the OPT2 interface by creating a firewall rule (found in Firewall > Rules) :

Figure 01-07 : All traffic is permitted by the firewall rule

Now that our firewall is ready, we can install the Proxmox Virtual Environment to our first hypervisor machine hyps1101. Since that machine is already virtualized by hyp-03, this will add another layer of virtualization in which we will be able to run Virtual Machines ourselves. We can take note of the hardware addresses to make the interface configuration easier :

Figure 01-08 : hyps1101 hardware addresses configuration

We can also pinpoint the drive that will be used for the installation :

Figure 01-09 : hyps1101 drive configuration

The addressing we will be using is as written below :

• Gateway / DNS server : 172.31.80.254
• FQDN : hyps1101.lab.ephec-ti.be
• stuMgm : 172.31.80.11
• stuVmNet : No IP
• stuVmNet VLAN 110 : 10.11.0.253

The only IP address we are assigning is the one linked to the stuMgm subnet. This is the only entry point to reach the hypervisor itself, which makes sense because any direct communication with the hypervisor is meant to manage it or the VMs it runs.

From there, we can enter the console session for hyps1101, and start installing Proxmox using the parameters that were mentioned above :

Figure 01-10 : Proxmox installation screen

Once the type 1 hypervisor environment is installed, it should logically be able to reach fwns1101's management IP. We can thus access hyp1101's shell and assert its connectivity with the firewall :

root@hyps1101:~# ping 172.31.80.211
PING 172.31.80.211 (172.31.80.211) 56(84) bytes of data.
64 bytes from 172.31.80.211: icmp_seq=1 ttl=64 time=0.532 ms
64 bytes from 172.31.80.211: icmp_seq=2 ttl=64 time=0.314 ms
64 bytes from 172.31.80.211: icmp_seq=3 ttl=64 time=0.286 ms
64 bytes from 172.31.80.211: icmp_seq=4 ttl=64 time=0.520 ms

By default, Proxmox will expose a web page on its network interface (which is on the stuMgm LAN) on port 8006. This means that from the jump server, we can access the web interface with the URL https://172.31.80.11:8006

Of course we remember that so far, the only available entry point to the management network is through the jump server. To remove this extra step, we will later set up a VPN tunnel to access the stuMgm subnet from our own devices.

To grant connectivity to the network that will later contain VMs, we will have to match the VLAN configuration that we enabled on the firewall. As a reminder, the stuVmNet network is set to hold VLANs, and the OPT2 interface of our firewall (10.11.0.254) will be the default gateway for VLAN 110. We can thus create a Linux Bridge through stuVmNet on our hypervisor, which we will call vmnets. We do not have to give it an IP since the only subnet we will be using for now is its VLAN 110. That obviously means we have to make the bridge VLAN aware :

Figure 01-11 : vmnets Linux Bridge configuration

Once this is done, we can create our VLAN 110 on the hypervisor. Giving it the name vmnets.110 will configure the interface and VLAN tag correctly, and all that is left is to assign it the right IP address, 10.11.0.253 :

Figure 01-12 : vmnets.110 VLAN configuration

With the network properly set up, we now have connectivity with the gateway, which is the OPT2 interface of fwns1101 :

root@hyps1101:~# ping 10.11.0.254
PING 10.11.0.254 (10.11.0.254) 56(84) bytes of data.
64 bytes from 10.11.0.254: icmp_seq=1 ttl=64 time=0.371 ms
64 bytes from 10.11.0.254: icmp_seq=2 ttl=64 time=0.358 ms
64 bytes from 10.11.0.254: icmp_seq=3 ttl=64 time=0.327 ms
64 bytes from 10.11.0.254: icmp_seq=4 ttl=64 time=0.414 ms

Before starting to run Virtual Machines, we still have a bit of setting up regarding the storage. Let's start with adding RAID 1 by mirroring our hard drive in order to have better storage fault tolerance. In the ZFS tab, we can select both available disks and choose the Mirror RAID option. This is what the ZFS state looks like after performing the operation :

Figure 01-13 : RAID 1 configuration for ZFS

The last step is to download a disk image that we will boot on our VMs. With little storage space to spare on our hypervisor, we will download a Debian netinstall ISO (way smaller file size than an offline install). Under the iso images section found in local storage, we can download the ISO found at the following URL :

https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.1.0-amd64-netinst.iso

Everything is now set up on the hypervisor and we can start running VMs.

It is now pretty simple to deploy our first VM with the following options :

• OS : The Debian 13 netinstall we downloaded earlier
• Disks : 8Go VirtIO Bloc
• Network : VLAN 110 - firewall disabled

Following the installer prompts will configure our VM. Since it was a netinstall, we have confirmation that network connectivity is working as expected, though it can't hurt to double-check with a ping :

showcase@debian:~$ ping archlinux.org
PING archlinux.org (95.217.163.246) 56(84) bytes of data.
64 bytes from archlinux.org (95.217.163.246): icmp_seq=1 ttl=49 time=33.1 ms
64 bytes from archlinux.org (95.217.163.246): icmp_seq=2 ttl=49 time=32.8 ms
64 bytes from archlinux.org (95.217.163.246): icmp_seq=3 ttl=49 time=33.4 ms
64 bytes from archlinux.org (95.217.163.246): icmp_seq=4 ttl=49 time=31.2 ms

The ip a command will confirm the machine has received an IP address from the DHCP pool (10.11.0.50-100) configured on fwns1101 :

2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 0e:24:11:93:b7:5a brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    altname ens18
    inet 10.11.0.54/24 brd 10.11.0.255 scope global dynamic noprefixroute ens18
       valid_lft 7147sec preferred_lft 7147sec
    inet6 fe80::b24:11ff:fe93:b75a/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever