I have been a Microsoft MVP and a Veeam Vanguard for quite some time now, which suggests that I share experiences, insights, knowledge, and feedback with the global IT community at large.
Community activities are as diverse as their members and their personalities. But in most cases, these activities involve adding something to the community they are part of. It is, or should not be, about what’s in it for me, even when that community will rise to help you should the need arise, but about us all. We all trip and fall at certain moments in our lives, both personally and professionally, meaning we all need help at times.
Helping those who need some assistance
One of the things I do is help where and when I can to ensure that the senior citizens I know or am aware of have their connectivity needs met as well as possible. That is particularly important for them if they rely on personal care and alarm systems, as well as some basic home automation, which makes living at home not only easier but also possible.
I don’t do such things through a non-profit organization; it’s simply a matter of rising to the occasion when the need and opportunity present themselves. Recently, a little “project” presented itself that required some network gear to complete.
Anyway, there was a need for excellent connectivity and a decent backup of any critical system(s). So, I offer my skills and time. I have some spare lab parts, but not all the items I need. This project required some wireless access points that can be easily and correctly configured and managed. So, what does one do? Ask for help from companies that might have surplus gear after hardware refreshes. I have used Aruba (IAP versions) and UniFi in the past. Any kit that works without expensive, high-end controller requirements and continues to function without requiring support contracts does the job. In some instances, flashing proprietary hardware with OpenWrt helps leverage hardware that does not work or cannot be maintained without a subscription.
For this project, I acquired some donated TP-Link Omada gear that was perfect for the job at hand.
What also came in handy is the community edition or free software from Veeam, which is available without subscriptions or costs, provided it is not installed by consultants or for profit. Hence, I give some schooling and training to ensure that the most tech-savvy person can take care of it. I help, explain, and offer advice on some aspects, but they ultimately get the job done.
I also needed a gateway/router/firewall. While in this case, I might consider installing a TP-Link gateway if I ever get my hands on one, but for now, an older model proprietary firewall I recovered and flashed with OPNsense Community Edition fills that role.
Preaching
We live in a polarized world, where division hinders progress. Social media bombards us with a tsunami of bad news that can keep you doomscrolling 24/7 if you fall into that trap. Instead, apply your skills to do something that improves the lives of people who need some assistance. It doesn’t have to be big in terms of size or money. It does not have to make the news or require Herculean effort.
All it takes is some effort and some time on your part, but it can also be fun to do. Did I do this alone? The people themselves got involved; the business I asked to donate hardware delivered the gear. The cabling came from dumpster diving. The firewall is an “obsolete” proprietary firewall appliance flashed with OPNsense community edition. Is the setup perfect? Nope, but it is excellent and does a fantastic job, way better than ever before!
You also have some skills, time, or materials to help out people. Just do it.
Eventually, we all make the mistake of locking ourselves out of our firewalls. Let’s look at how to fix locking yourself out of OPNsense. Let’s look at how to fix locking yourself out of OPNsense.
With OPNsense, this is mainly due to an error in Interface configuration and firewall rules. You know, when we are too “strict” and deny traffic from private networks on the interface we use for management.
How to fix locking yourself out of OPNsense
Cause 1: Firewall rules are blocking you
These can be user-treated rules or the rules added when you select to block private address ranges on an interface.
There is an easy solution, but it requires console access. If OPNsense runs in a virtual machine, that is relatively easy, especially in the lab or when you are the hypervisor administrator. Now, if OPNsense is running on an appliance, you’ll probably need physical access to that device. Bring a keyboard and a monitor with whatever cable (VGA/DVI/HDMI/DisplayPort/USB-C) is required, or connect a physical console cable to connect to the device. This can only be done remotely if the console port is available over ethernet.
Log in with an account with sufficient rights and drop into the shell by selecting option 8.
Type:
pfctl -d
Hit “Enter”. This turns the OPNsense device into a router only by disabling the firewall. That means you now have access again via HTTPS or SSH on the interfaces you list for administration despite the error you made in the firewall rules for those interfaces.
Connect via the Web GUI and fix that mistake. When done, turn the firewall back on. To do so type:
pfctl -e
Hit “Enter”. The firewall is now enabled again.
Test whether you still have Web GUI or SSH access. If so, mission accomplished.
Cause 2: You no longer have HTTPS/SSH listening on the interface you have access to
By default, you listen to all non WAN interfaces. You might have reduced this to one or more but accidentally forgot to select the one(s) you need.
No fear, under /conf/conf.xml, you can edit the administrative webgui and ssh settings. In the example below, I have customized those settings (via the WebGUI) to listen to the specified ports.
WebGUI
SSH
Add the missing interface(s) or allow the WebGUI and SSH to listen to all of them again by reverting the settings back to default and not specifying any interfaces, as in the example below.
WebGUI
SSH
To edit these files, you can use vi, which is available by default. If you prefer Nano or such, you can install it via the FreeBSD package manager:
pkg install nano
Voila, those are the most common ways to get out of a pickle when you have locked yourself out of OPNsense.
I recently wrote a 3 part series (see part 1, part 2, and part 3) about setting up site-to-site VPNs to Azure using an OPNsense router/firewall appliance. That made me realize some of you would like to learn more about deploying an OPNsense/pfSense Hyper-V virtual machine in your lab or production. In this blog post, using PowerShell, I will start by showing you how to deploy one or more virtual machines that are near perfect to test out a multitude of scenarios with OPNsense. It is really that easy.
Hyper-V virtual switches
I have several virtual switches on my Hyper-V host (or hosts if you are clustering in your lab). One is for connections to my ISP, and the other is for management, which can be (simulated) out-of-band (OOB) or not; that is up to you. Finally, you’ll want one for your workload’s networking needs. In the lab, you can forgo teaming (SET or even classic native teaming) and do whatever suits your capabilities and /or needs.
I can access more production-grade storage, server, and network hardware (DELL, Lenovo, Mellanox/Nvidia) for serious server room or data center work via befriended MVPs and community supporters. So that is where that test work happens.
Images speak louder than a thousand words
Let’s add some images to help you orient your focus on what we are doing. The overview below gives you an idea about the home lab I run. I acquired the network gear through dumpster diving and scavenging around for discards and gifts from befriended companies. The focus is on the required functionality without running up a ridiculous power bill and minimizing noise. The computing hardware is PC-based and actually quite old. I don’t make a truckload of money and try to reduce my CO2 footprint. If you want $$$, you are better in BS roles, and there, expert technical knowledge is only a hindrance.
The grey parts are the permanently running devices. These are one ISP router and what the rest of the home network requires. An OPNsense firewall, some Unifi WAPs, and a managed PoE switch. That provides my workstation with a network for Internet access. It also caters to my IoT, WiFi, and home networking needs, which are unimportant here.
The lab’s green part can be shut down unless I need it for lab scenarios, demos, or learning. Again this saves on the electricity bill and noise.
The blue part of the network is my main workstation and about 28 virtual machines that are not all running. I fire those up when needed. And we’ll focus on this part for the OPNsense needs. What is not shown but which is very important as a Veeam Vanguard is the Veeam Backup & Replication / Veeam ONE part of the lab. That is where I design and test my “radical resilience” Veeam designs.
Flexibility is key
On my stand-alone Hyper-V workstation, I have my daily workhorse and a small data center running all in one box. That helps keep costs down and means that bar the ISP router and permanent home network, I can shut down and cut power to the Barracuda appliance, all switches, the Hyper-V cluster nodes, and the ISCSI storage server when I don’t need them.
If you don’t have those parts in your lab, you need fewer NIC ports in the workstation. You can make the OOB and the LAN vSwitch internal or private, as traffic does not need to leave the host. In that case, one NIC port for your workstation and one for the ISP router will suffice. If you don’t get a public IP from your ISP, you can use a NIC port for an external vSwitch shared with your host.
This gives me a lot of flexibility, and I have chosen to integrate my workstation data center with my hardware components for storage and Hyper-V clustering.
Even with a laptop or a PC with one NIC, you can use the script I share here using internal or private virtual switches. As long as you stay on your host, that will do, with certain limitations of cause.
Three virtual switches
OOB-MGNT: This is attached to a subnet that serves no purpose other than to provide an IP to manage network devices. Appliances like the Kemp Loadmasters, the OPNsense/pfSense/VyOS appliances, physical devices like the switches, the Barracuda firewall, the home router, and other temporary network appliances. It does not participate in any configuration for high availability or in carrying data.
ISP-WAN: This vSwitch has an uplink to the ISP router. Virtual machines attached to it can get a DHCP address from that ISP router, providing internet access over NAT. Alternatively, you can configure it to receive a public IP address from your ISP via DHCP (Cable) or PPoE (VDSL). With some luck, your ISP hands out more than just one. If so, you can test BGP-based dynamic routing with a site-to-site VPN from OPNsense and Azure VWAN.
LAN: The LAN switch is for carrying configuration and workload data. For standard use virtual machines, we configure the VLAN tag on the vNIC settings in the portal or via PowerShell. But network appliances must be able to carry all VLAN traffic. That is why we configure the virtual NICs of the LAN in trunk mode and set the list of allowed VLANs it may carry.
PowerShell script for deploying an OPNsense/pfSense Hyper-V virtual machine
Change the parameters in the below PowerShell function. Call it by running CreateAppliance. You can parameterize the function at will and leverage it however you see fit. This is just to give you an idea of how to do it and how I configure the settings for the appliance(s).
function CreateAppliance() {
Clear-Host
$Title = @"
___ _ _ _ _ _ _
/ \___ _ __ | | ___ _ _ /\ /(_)_ __| |_ _ _ __ _| | /\/\ __ _ ___| |__ (_)_ __ ___
/ /\ / _ \ '_ \| |/ _ \| | | | \ \ / / | '__| __| | | |/ _` | | / \ / _` |/ __| '_ \| | '_ \ / _ \
/ /_// __/ |_) | | (_) | |_| | \ V /| | | | |_| |_| | (_| | | / /\/\ \ (_| | (__| | | | | | | | __/
/___,' \___| .__/|_|\___/ \__, | \_/ |_|_| \__|\__,_|\__,_|_| \/ \/\__,_|\___|_| |_|_|_| |_|\___|
|_| |___/
__ ___ ___ __ __ __ __
/ _| ___ _ __ /___\/ _ \/\ \ \___ ___ _ __ ___ ___ / / __ / _/ _\ ___ _ __ ___ ___
| |_ / _ \| '__| // // /_)/ \/ / __|/ _ \ '_ \/ __|/ _ \ / / '_ \| |_\ \ / _ \ '_ \/ __|/ _ \
| _| (_) | | / \_// ___/ /\ /\__ \ __/ | | \__ \ __// /| |_) | _|\ \ __/ | | \__ \ __/
|_| \___/|_| \___/\/ \_\ \/ |___/\___|_| |_|___/\___/_/ | .__/|_| \__/\___|_| |_|___/\___|
|_|
"@
Write-Host -ForegroundColor Green $Title
filter timestamp { "$(Get-Date -Format "yyyy/MM/dd hh:mm:ss"): $_" }
VMPrefix $= 'OPNsense-0'
$Path = "D:\VirtualMachines\"
$ISOPath = 'D:\VirtualMachines\ISO\OPNsense-23.7-vga-amd64.iso'
#$ISOPath = 'C:\VirtualMachines\ISO\pfSense-CE-2.7.1-RELEASE-amd64.iso'
$ISOFile = Split-Path $ISOPath -leaf
$NumberOfCPUs = 2
$Memory = 4GB
$NumberOfVMs = 1 # Handy to create a high available pair or multiple test platforms
$VMGeneration = 2 # If an apliance supports generation 2, choose this, always! OPNsense, pfSense, Vyos support this.
$VmVersion = '10.0' #If you need this VM yo run on older HYper-V hosts choose the version accordingly
#vSwitches
$SwitchISP = 'ISP-WAN' #This external vSwitch is connected to the NIC towards ISP router. Not shared with the hyper-V Host
$SwitchOOBMGNT = 'OOB-MGNT' #This can be a private/internal netwwork or an external one, possibly shared with the host.
$SwitchLAN = 'LAN' #This can be a private/internal netwwork or an external one, possibly shared with the host.
#vNICs and if applicable their special configuration.
$WAN1 = 'WAN1'
$WAN2 = 'WAN1'
$OOBorMGNT = 'OOB'
$LAN1 = 'LAN1'
$LAN1TrunkList = "1-2048"
$LAN2 = 'LAN2'
$LAN2TrunkList = "1-2048"
write-host -ForegroundColor green -Object ("Starting deployment of your appliance(s)." | timestamp)
ForEach ($Counter in 1..$NumberOfVMs) {
$VMName = $VMPrefix + 1
try {
Get-VM -Name $VMName -ErrorAction Stop | Out-Null
Write-Host -ForegroundColor red ("The machine $VMName already exists. We are not creating it" | timestamp)
exit
}
catch {
$NewVhdPath = "$Path\$VMName\Virtual Hard Disks\$VMName-OS.vhdx"
If ( Test-Path -Path $NewVhdPath) {
Write-host ("$NewVhdPath allready exists. Clean this up or specify a new location to create the VM." | timestamp)
}
else {
Write-Host -ForegroundColor Cyan ("Creating VM $VMName in $Path ..." | timestamp)
New-VM -Name $VMName -path $Path -NewVHDPath $NewVhdPath
-NewVHDSizeBytes 64GB -Version $VmVersion -Generation $VMGeneration -MemoryStartupBytes $Memory | out-null
Write-Host -ForegroundColor Cyan ("Setting VM $VMName its number of CPUs to $NumberOfCPUs ..." | timestamp)
Set-VMProcessor –VMName $VMName –count 2
#Get rid of the default network adapter -renaning would also be an option
Remove-VMNetworkAdapter -VMName $VMName -Name 'Network Adapter'
Write-Host -ForegroundColor Magenta ("Adding Interfaces WAN1, WAN2, OOBMGNT, LAN1 & LAN2 to $VMName" | timestamp)
write-host -ForegroundColor yellow -Object ("Creating $WAN1 Interface" | timestamp)
#For first ISP uplink
Add-VMNetworkAdapter -VMName $vmName -Name $WAN1 -SwitchName $SwitchISP
write-host -ForegroundColor green -Object ("Created $WAN1 Interface succesfully" | timestamp)
write-host -ForegroundColor yellow -Object ("Creating $WAN2 Interface" | timestamp)
#For second ISP uplink
Add-VMNetworkAdapter -VMName $vmName -Name $WAN2 -SwitchName $SwitchISP
write-host -ForegroundColor green -Object ("Created $WAN2 Interface succesfully" | timestamp)
write-host -ForegroundColor yellow -Object ("Creating $OOBorMGNT Interface" | timestamp)
#Management Interface - This can be OOB if you want. Do note by default the appliance route to this interface.
Add-VMNetworkAdapter -VMName $vmName -Name $OOBorMGNT -SwitchName $SwitchOOBMGNT #For management network (LAN in OPNsense terminology - rename it there to OOB or MGNT as well - I don't use a workload network for this)
write-host -ForegroundColor green -Object ("Created $OOBorMGNT Interface succesfully" | timestamp)
write-host -ForegroundColor yellow -Object ("Creating $LAN1 Interface" | timestamp)
#For workload network (for the actual network traffic of the VMs.)
Add-VMNetworkAdapter -VMName $vmName -Name $LAN1 -SwitchName $SwitchLAN
write-host -ForegroundColor green -Object ("Created $LAN1 Interface succesfully" | timestamp)
write-host -ForegroundColor yellow -Object ("Creating $LAN2 Interface" | timestamp)
#For workload network (for the actual network traffic of the VMs. he second one is optional but useful in labs scenarios.)
Add-VMNetworkAdapter -VMName $vmName -Name $LAN2 -SwitchName $SwitchLAN
write-host -ForegroundColor green -Object ("Created $LAN2 Interface succesfully" | timestamp)
Write-Host -ForegroundColor Magenta ("Setting custom configuration top the Interface (trunking, allowed VLANs, native VLAN ..." | timestamp)
#Allow all VLAN IDs we have in use on the LAN interfaces of the firewall/router. The actual config of VLANs happens on the appliance.
write-host -ForegroundColor yellow -Object ("Set $LAN1 Interface to Trunk mode and allow VLANs $LAN1TrunkList with native VLAN = 0" | timestamp)
Set-VMNetworkAdapterVlan -VMName $vmName -VMNetworkAdapterName $LAN1 -Trunk -AllowedVlanIdList $LAN1TrunkList -NativeVlanId 0
write-host -ForegroundColor green -Object ("The $LAN1 Interface is now in Trunk mode and allows VLANs $LAN1TrunkList with native VLAN = 0" | timestamp)
write-host -ForegroundColor yellow -Object ("Set $LAN2 Interface to Trunk mode and allow VLANs $LAN2TrunkList with native VLAN = 0" | timestamp)
Set-VMNetworkAdapterVlan -VMName $vmName -VMNetworkAdapterName $LAN2 -Trunk -AllowedVlanIdList $LAN2TrunkList -NativeVlanId 0
write-host -ForegroundColor green -Object ("The $LAN2 Interface is now in Trunk mode and allows VLANs $LAN2TrunkList with native VLAN = 0" | timestamp)
Write-Host -ForegroundColor Magenta ("Adding DVD Drive, mounting appliance ISO, setting it to boot first" | timestamp)
Write-Host -ForegroundColor yellow ("Adding DVD Drive to $VMName" | timestamp)
Add-VMDvdDrive -VMName $VMName -ControllerNumber 0 -ControllerLocation 8
write-host -ForegroundColor green -Object ("Succesfully addded the DVD Drive." | timestamp)
Write-Host -ForegroundColor yellow ("Mounting $ISOPath to DVD Drive on $VMName" | timestamp)
Set-VMDvdDrive -VMName $VMName -Path $ISOPath
write-host -ForegroundColor green -Object ("Mounted $ISOFile." | timestamp)
Write-Host -ForegroundColor yellow ("Setting DVD with $ISOPath as first boot device on $VMName and disabling secure boot" | timestamp)
$DVDWithOurISO = ((Get-VMFirmware -VMName $VMName).BootOrder | Where-Object Device -like *DVD*).Device
#I am optimistic and set the secure boot template to what it most likely will be if they ever support it :-)
Set-VMFirmware -VMName $VMName -FirstBootDevice $DVDWithOurISO `
-EnableSecureBoot Off -SecureBootTemplate MicrosoftUEFICertificateAuthority
write-host -ForegroundColor green -Object ("Set vDVD with as the first boot device and disabled secure boot." | timestamp)
$VM = Get-VM $VMName
write-Host -ForegroundColor Cyan ("Virtual machine $VM has been created." | timestamp)
}
}
}
write-Host -ForegroundColor Green "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"
write-Host -ForegroundColor Green "You have created $NumberOfVMs virtual appliance(s) with each two WAN ports, a Management port and
two LAN ports. The chosen appliance ISO is loaded in the DVD as primary boot device, ready to install."
write-Host -ForegroundColor Green "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"
}
#Run by calling
CreateAppliance
Conclusion
Deploying an OPNsense/pfSense Hyper-V virtual machine is easy. You can have one or more of them up and running in less seconds. For starters, it will take longer to download the ISOs for installing OPNsense or pfSense than to create the virtual machine.
Finally, the virtual machine configuration allows for many lab scenarios, demos, and designs. As such, they provide your lab with all the capabilities and flexibilities you need for learning, testing, validating designs, and troubleshooting.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
Websites store cookies to enhance functionality and personalise your experience. You can manage your preferences, but blocking some cookies may impact site performance and services.
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
comment_author
Used to track the user across multiple sessions.
Session
These cookies are used for managing login functionality on this website.
Name
Description
Duration
wordpress_logged_in
Used to store logged-in users.
Persistent
wordpress_sec
Used to track the user across multiple sessions.
15 days
wordpress_test_cookie
Used to determine if cookies are enabled.
Session
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_ga_
ID used to identify users
2 years
_gid
ID used to identify users for 24 hours after last activity
24 hours
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.