VLANs allow to introduce network segmentation to our environment. After we make sure the machines sit in separate VLANs, we might want to provide some sort of inter-VLAN routing as well as some sort of a firewall (UTM) that will make sure only desired traffic gets through from VLANs to VLANs.
In last article we introduced the basic concept of a virtual switch. Now is a good time to introduce VLANs and how we can integrate them with LibVirt. This will allow us to segregate VMs just like we would segregate physical machines and devices using traditional managed switches.
Lately I’ve been toying around with the idea of finally putting more effort into learning ins and outs of CheckPoint VSX systems. Basic deployment technically allows us to rely only on physical interfaces to set up the chassis but I wanted to make sure I have something that reflects most common setups (because in 99.9% of cases you will encounter VSXes simply connected to a switch over a trunk port and very little physical cabling).
In this article you will learn how to add a basic virtual switch, as well as to move some of your interfaces to it.
Today I’ve spent a little bit of my time to figure out how to move away from policy-based VPN in favour of a route-based one instead. I was eyeing the concept for a while now and wanted to use it in my home lab to solve a couple of problems I was trying to turn a blind eye to. Without further ado, please follow the guide below to set up a route-based VPN between a StrongSwan-based peer (on RPi 3+) and an OPNSense appliance.
This afternoon was spent on searching for ways to auto-register clients and assign them into different policies based on whether they’re virtual or not and, to my surprise, I couldn’t find an out-of-the-box way of achieving this with Zabbix.
After looking into different Zabbix agent calls and modules, I found a way I could use to reliably tell whether it’s a baremetal machine or not.