Showing posts with label Proxmox. Show all posts
Showing posts with label Proxmox. Show all posts

Monday, December 23, 2024

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.

Monday, July 22, 2024

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.

Wednesday, March 27, 2024

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.

Monday, February 26, 2024

Empowering Privacy: Unveiling the World of Affordable VPNs through Shared Bandwidth Projects and Proxmox Efficiency

In an era where digital privacy is a growing concern, Virtual Private Networks (VPNs) have become indispensable tools for safeguarding online activities. However, the cost of premium VPN services can be a deterrent for many users. Fortunately, a new wave of projects that leverage shared user bandwidth has emerged, offering a cost-effective alternative to traditional VPNs. In this blog post, we'll explore the benefits of such projects and discuss how setting them up as Linux containers on a Proxmox server can be a resource-efficient solution. 

Shared Bandwidth VPN Projects:

Mysterium

Mysterium is a decentralized VPN network that operates on a peer-to-peer model. Users can share their excess bandwidth in exchange for MYST tokens. By becoming a node in the Mysterium network, users contribute to the overall infrastructure and, in return, gain access to affordable VPN services. Setting up Mysterium nodes as Proxmox Linux containers ensures efficient resource utilization and easy management.  I set this up following the instructions for Linux nodes.


EarnApp

EarnApp takes a unique approach by allowing users to earn money by sharing their internet bandwidth. Users can convert their earned tokens into VPN services, creating an innovative system where the community contributes to the network's growth. Proxmox's virtualization capabilities make it straightforward to deploy and manage EarnApp nodes, making it an attractive option for those seeking a low-cost VPN solution.


Saturday, February 24, 2024

Cracking the Code: Navigating Network Nightmares with Home Assistant, LibreNMS, and Wireshark

Introduction:

Hey there! Ever found yourself scratching your head over a quirky network issue that just won't quit? I recently had my fair share of head-scratching moments when network broadcast storms started causing serious disruptions in our switches and wireless access points. In this post, I'm breaking down the steps I took to unravel this persistent, network mystery.

Setting the Scene:

Picture this – network switches and access points dropping off the radar every few nights. To get to the bottom of it, I needed to gather some intel without losing sleep, especially as these problems seemed to occur in the middle of the night.  First move? Configuring Home Assistant to ping, with the Ping integration, a crucial switch and give me a notification on my phone when things go south. It became my silent night watchman, marking the time when the broadcast storm kicked in.

The Quest for Network Clarity:

LibreNMS, a network monitoring system, was my next stop. Although it did show spikes in network bandwidth, the specifics were elusive. SNMP logs lacked the juicy details needed for a deep investigation.

Enter rsyslogd:

To beef up my data game, I brought in rsyslogd on a Proxmox server. This Linux container was configured to capture logs from the admin VLAN, where switches and access points were. This did capture a lot of data, however, drowning in logs was not my idea of fun.  It was too hard to find the root cause of these issues.

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...