Printing Across VLANs: A Secure and Scalable Solution

In my previous configuration, I used a CUPS server with multiple network interfaces to enable printing from computers on restricted networks onto the printer located in the admin network. However, after some research and exploration, I discovered a more efficient way to achieve this goal by utilizing VLANs for network segmentation.

Creating a Dedicated Printer VLAN

To start, I created a dedicated "printer" VLAN that can only communicate with the internet but is isolated from other VLANs. Networks from which I want to enable printing, are configured to allow creating connections to the printer VLAN. This ensures that printing traffic within the restricted networks cannot accidentally traverse to other parts of the network, while computers can print to the printer. The printer VLAN is now the primary focus for setting up the UDP proxy container.

Configuring the UDP Proxy Container

To enable printing across multiple networks, I created a Linux container, for a UDP proxy, with network interfaces on both the printer VLAN and any additional VLANs that need to support printing. In this setup, the UDP proxy container acts enable notifications of the printers on the printer VLAN to computers.

Here's an example of how to configure the UDP proxy relay using the udpbroadcastrelay command:

# Configure the first relay for NetBIOS
./udpbroadcastrelay --id 1 --port 137 --dev printer-vlan-interface --dev computer-vlan-interface -f
# Configure the second relay for NetBIOS
./udpbroadcastrelay --id 2 --port 138 --dev printer-vlan-interface --dev computer-vlan-interface -f
# Configure the third relay for SSDP
./udpbroadcastrelay --id 3 --port 1900 --dev printer-vlan-interface --dev computer-vlan-interface --multicast 239.255.255.250 -f

Unlock Seamless Remote Access: The Power of Split DNS with Tailscale

 As a remote worker or someone who frequently collaborates with others on different networks, you're likely familiar with the challenges of maintaining seamless communication and connectivity across various environments. One innovative solution to this problem is split DNS combined with Tailscale, a powerful tool for creating secure, managed tunnels between devices.

What is Split DNS?

Split DNS refers to a configuration approach where your device uses different DNS servers depending on whether you're connected to your local network or an external network (such as the internet). This allows your device to resolve names and access resources locally without relying on the DNS servers associated with the external network, which can be slower and less secure.

How Tailscale Works

Tailscale is a popular tool for creating managed VPN tunnels between devices. It provides a simple and secure way to connect to remote networks while ensuring your data remains encrypted and private. When you install Tailscale on multiple devices, it creates a network of encrypted connections that allow you to access each other's computers as if they were directly connected to the same local network.

Mastering Matter: Seamless Smart Home Integration with Network Segmentation

I’ve been intrigued by the idea of integrating devices with Matter for some time. My smart home setup includes a pair of SwitchBot Hubs, some Govee lights, and an air purifier. Each of these devices comes with its own dedicated app, and while some offer integration with Home Assistant, the process often comes with limitations—such as requiring devices to be connected to the main network.

The primary reason I hadn’t yet migrated these devices to Matter was my desire to maintain network separation for IoT devices, even when using Matter.

Network Segmentation Challenges

Previously, I set up an IoT VLAN where devices on this virtual network are isolated from the main network. Devices like my phone, computer, and Home Assistant server, which are on the main network, can still access the IoT VLAN. However, this setup presented a few hurdles for Matter integration:

1. IPv6 Requirement: I hadn’t enabled IPv6 on the IoT VLAN to reduce the attack surface for potential network threats. Unfortunately, Matter requires IPv6 for communication, so enabling it became a necessity.

2. Local Network Limitation: Home Assistant’s Matter implementation only scans the local network for devices. Since my Home Assistant server resides on the main network, it couldn’t detect Matter devices located on the IoT VLAN.

First Attempt and Challenges

I explored solutions, including this guide on setting up Home Assistant across multiple VLANs. While I managed to connect Matter devices to Home Assistant, this configuration caused my non-Matter devices to become unavailable. Upon inspection, I realized that Home Assistant had designated the IoT VLAN as its default network. This occurred because Home Assistant appears to sort networks by IP subnet, and my IoT VLAN (10.0.15.0/24) was prioritized over my main network (172.16.1.1/24).

Given that the IoT VLAN blocks connections to other networks, this default setting broke many of my integrations. Frustrated, I reset the virtual machine to its previous state and decided to revisit the problem later.

Seamless Local Control: Integrating WeatherFlow with Home Assistant Across VLANs

I've been pleased with my Home Assistant setup for some time now. One of my main focuses has been achieving local control. This ensures reduced latency for device commands and maintains functionality for state updates and commands even without an internet connection.

I've successfully transitioned many devices to local control using Zigbee, Z-Wave, and ESPHome, but not all integrations have been straightforward. A notable exception has been the WeatherFlow integration for my Tempest weather station.

WeatherFlow offers two types of integrations. The first relies on the cloud, where the weather station sends data to the Tempest cloud service, and the WeatherFlow cloud integration then pulls this data into Home Assistant at intervals.

The second method utilizes the fact that the Tempest weather station broadcasts weather state changes via UDP on the local network. The local WeatherFlow integration in Home Assistant listens for these broadcasts. However, my setup had the Tempest weather station on a different network VLAN than my Home Assistant server. Since UDP broadcasts typically don’t cross VLAN boundaries, this local integration wasn’t working.

I had multiple reasons for placing the Tempest weather station on a separate VLAN. Primarily, the default behavior of sending frequent UDP broadcasts can lead to significant network traffic, especially impacting wireless networks. Additionally, I segment my network for security purposes, preventing devices on the Tempest's VLAN from scanning or connecting to computers on more secure VLANs.

Unlocking Raspberry Pi Potential: Navigating Network Booting Challenges for Enhanced Performance and Reliability

I've set up several Raspberry Pis around our house for various projects, but one recurring challenge is the potential for SD card failure due to heavy file system writes. To mitigate this, I've transitioned some of my Raspberry Pi 4s to boot from USB drives, but this limits compatible cases.

Backing up these SD cards or USB drives can be cumbersome, yet essential in case of failure. Recognizing that Raspberry Pis since the 3 B model can boot from the network, I decided to utilize my Proxmox server to host the boot server.

Initially, I explored Piserver, the official solution from the Raspberry Pi Foundation. Setting it up involved creating a VM and booting from the Raspbian distribution iso. While it provided a straightforward interface for booting devices from the network and selecting distributions, it fell short of my needs.

Empowering Your Home's Power Protection: A Deep Dive into UPS Monitoring and Integration

Our household relies on several Uninterruptible Power Supplies (UPSs) to safeguard our network equipment and computers. A crucial aspect of maintaining these UPSs is monitoring their batteries to determine if they need replacement.

For UPSs located near desktop PCs, monitoring battery status is straightforward. These UPSs can typically be connected via USB, allowing us to use monitoring software to check battery health.

However, monitoring UPSs situated in network racks is more complex. Some UPSs only offer serial or USB ports, requiring a computer to directly connect and retrieve battery status. Alternatively, certain UPSs feature a network port and cloud connectivity, enabling them to upload status data to the cloud for remote viewing.

We have an APC UPS with cloud connectivity, which facilitates notifications for significant status changes through their Smart Connect service. Despite its benefits, this solution has drawbacks for our specific needs. Firstly, there's no integration with Home Assistant, preventing us from automating devices based on UPS status, such as shutting down devices during power outages when battery levels drop below a certain threshold. Secondly, reliance on a cloud connection means that if our internet goes down, the automations wouldn't function.

Empowering Family Legacy: How I Transitioned to Self-Hosting with Gramps Web

For several years now, I've been maintaining a genealogy website containing information from both my and my wife's family history. One of my main objectives has been to ensure this wealth of information is readily accessible not just for our extended family, but also for our children whenever they want to look into their roots.

 Initially, I hosted this website through a paid hosting service, utilizing TNG. While this setup served its purpose adequately, my recent acquisition of a Proxmox server prompted me to explore the possibility of self-hosting. Given this shift, I decided to transition to open-source software, as it would grant me greater flexibility in making adjustments as needed.

In my search for suitable open-source genealogy software, I came across Gramps Web. Its user-friendly interface and compatibility with the Gramps genealogy desktop software caught my attention.