Secure Networking with Hub-and-Spoke Topology Using WireGuard and eBGP

Free Range Routing (FRR) is a powerful, open-source routing software suite that provides implementations of various routing protocols, including BGP, OSPF, IS-IS, RIP, PIM, and more.
It’s designed to run on Linux and Unix-like systems, making it a flexible solution for a wide range of network setups—from small labs to large-scale data centers.

Why FRR?

  • Scalability: Supports complex network topologies.
  • Flexibility: Easily integrates with existing network infrastructures.
  • Community-driven: Regular updates and active community support.

A Brief History

FRR originated as a fork of the Quagga project (which is still used for the Looking Glass service) in 2016, aiming to create a more dynamic and community-focused development path. Since then, it has grown into a robust and widely adopted routing platform, used by service providers, enterprises, and research institutions.

Demo Lab Overview

🌐 Topology

This demo lab showcases a Hub-and-Spoke topology using WireGuard for secure tunneling between the nodes.
We use unique ASN (Autonomous System Number) to run eBGP (external Border Gateway Protocol) between the entities.
The OS we use is Ubuntu 24.04.1.

Hub:

  • Public IP: Static (known)
  • Tunnel IP: 10.5.5.1

Spoke #1:

  • Public IP: Ephemeral
  • Tunnel IP: 10.5.5.20

Spoke #2:

  • Public IP: Ephemeral
  • Tunnel IP: 10.5.5.10

The Hub acts as a central point with a fixed public IP, while both Spokes establish dynamic WireGuard connections, enabling BGP peering over the secure tunnels.

Objectives

  • Establish WireGuard tunnels between the Hub and Spokes.
  • Configure BGP on FRR to route traffic between the nodes.
  • Ensure seamless communication between Spokes through the Hub.

In the next sections, we’ll dive into the WireGuard setup, followed by configuring FRR BGP for efficient routing.

Firewall Considerations

  • Hub:
    • Allow inbound UDP 51820 to accept incoming WireGuard connections from the Spokes.
  • Spokes:
    • Allow outbound UDP 51820 to the Hub’s public IP to establish the WireGuard tunnel.
  • BGP (TCP 179) runs inside the WireGuard tunnel and does not require any firewall exceptions.

Why Use WireGuard?

We chose WireGuard for this setup to enhance the privacy, integrity, and security for every bit we transport across the internet.
Wireguard provides:

  • End-to-End Encryption: All traffic between Hub and Spokes is encrypted using state-of-the-art cryptographic protocols (ChaCha20 for encryption, Poly1305 for message authentication).
  • Simplicity & Performance: WireGuard is lightweight, easy to configure, and offers high performance with low overhead.
  • Ephemeral IP Handling: Its ability to handle dynamic public IPs makes it ideal for spokes with changing network addresses.
  • Integrity & Authentication: Only peers with the correct public keys can establish connections, ensuring data integrity and preventing unauthorized access.

WireGuard Setup

📦 Prerequisites

Ensure WireGuard is installed on all nodes:

🔑 Key Generation

On each node (Hub and Spokes), generate WireGuard key pairs:

  • privatekey  → Keep this secure.
  • publickey  →Share with peers.

⚙️ Hub Configuration (/etc/wireguard/wg0.conf)

⚙️ Spoke Configuration (/etc/wireguard/wg0.conf)

Spoke #1:

Spoke #2:

🚀 Start WireGuard

On all nodes, start and enable WireGuard:

✅ Verify Tunnel

Run on each node to check peer status:

example-output for Spoke1:

Once the tunnels are active, you can ping between the nodes using their Tunnel IPs.

Next, we’ll dive into configuring BGP to enable dynamic routing over the WireGuard tunnels.

Install FRR

Ensure FRR is installed on all nodes, we will stick on the stable release of FRR:

expected output:

Check if FRR daemon is up and running with systemctl status frr.service

output:

Let’s enable BGPd with vi /etc/frr/daemons

Restart the daemon with with systemctl restart frr.service
With enabled BGPd FRR uses minimal resources:

Compute-allocation for FRR with enabled BGPd

Let’s access the virtual-console of the Hub with sudo vtysh and setup the virtual-router. We also log all configuration commands entered via the vtysh shell:

Hub

Spoke #2

Spoke #1

Let’s see if Spoke#1 can see the Hub as a BGP neighbor:

The Lab seems to be in a pretty good shape 🙂
Go ahead and try to establish a connection with Spoke#2!

Let’s announce a BGP-Route

On the HUB, we will announce a BGP route (10.5.7.1/32) for testing.
To do this, we will create a dummy interface and assign an IPv4 address.
FRR will then announce this network via BGP to the peers (Spoke#1 and Spoke#2).
Finally, we will verify if we are advertising the route to Spoke#1.

Ok, let’s see if we receive route 10.5.7.1/32 on Spoke#1 and check connectivity:

Good! That’s it so far.


We have established a highly secure and scalable network topology across the internet. By leveraging WireGuard for routing transmission and communication, we ensure that this network topology remains exceptionally secure.


Extract certificate and key from acme.json

Traefik V2.3 creates a file called acme.json after a successful certification-creation (cert-provider: let’s encrypt).

To extract the certificate and key from this file I have created this bash-script:
https://github.com/ugu5ma/extract_acme_json_traefik

Getting Started with Wazuh: Setting Up Your Lab Environment for XDR and SIEM”

In today’s cybersecurity landscape, having a robust and flexible security information and event management (SIEM) system is crucial.
Wazuh, an open-source security platform, offers comprehensive solutions for threat detection, integrity monitoring, incident response, and compliance.

Wazuh has an interesting history. In 2015, the Wazuh team decided to fork OSSEC, an open-source host-based Intrusion Detection System (IDS), to expand its core functionalities with additional features, enhancements, and a user-friendly interface.
Wazuh has grown significantly since its inception. It is now a comprehensive, open-source security platform that provides unified XDR (Extended Detection and Response) and SIEM (Security Information and Event Management) capabilities. The platform is designed to monitor infrastructures, detect threats, respond to incidents, and ensure regulatory compliance.

This blog will guide you through setting up Wazuh in a lab environment, focusing on its basic capabilities in Extended Detection and Response (XDR) and SIEM.
Whether you’re a cybersecurity professional or an enthusiast, this step-by-step guide will help to get started with Wazuh to secure your systems effectively.
We start with the defaults to make the lab-setup not more complex as necessary.

My Lab-env is as follows:

HostIPOS
Wazuh-Server10.50.100.76Ubuntu 24 LTS
Wazuh-Agent10.50.100.110RHEL 9
Wazuh-Agent10.50.100.111RHEL 9
Wazuh-Agent10.50.100.201Windows

Basic setup of Wazuh-Server

with root rights execute curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

Example output:

Please note the autogenerated User/Password to get later access to the Dashboard.

Linux: Basic setup of Wazuh-Agent

with root rights execute:


run the Agent installer (10.50.100.76 = Wazuh-Server)

example output:

Start the Wazuh-Agent and check the status:

example output:

Windows: Basic setup of Wazuh-Agent

Download the Agent-Installer and execute the command with admin-rights:

example-output:

Access the Dashboard

open a Browser and access: https://10.50.100.76
Don’t be surprised that the connection is interested, we use the default certs.


We see the default Dashboard:

Wazuh is shipped with default rules.
In a productive environment the real work would start now:
Create/adapt rules that are suitable for the required purposes and environment.
We will start with fixing the first (easy) vulnerability finding.

Fix a chrony-finding/vulnerability

Lets pick an RHEL-Agent and check the details of the chrony-finding:

  1. Navigate to Configuration Assesment
  2. Select an Agent
  3. Agent ID 02 looks as a good candidate
  4. filter the findings for chrony
  5. click on the failed check
  6. read carefully the finding and check the settings on the Agent to get it fixed

get the chrony finding fixed

The crony process is not executed by user chrony, let’s get it fixed:

To force a new assessment a restart of the Wazuh-agent is necessary.

Go back to the Dashboard/finding-screen and check again the chrony-finding:

Chrony looks good now, just another 82 findings to fix

In one of the next sessions I will go into the details of Wazuh, it is a great product.

Run DeepSeek LLM locally on your M series Mac with LM Studio and integrate iTerm2

With the integration of LM Studio and iTerm2, powered by the cutting-edge DeepSeek LLM, developers can now streamline their workflows.
This setup enhances coding efficiency while maintaining complete control over their data.

Running DeepSeek LLM locally offers several benefits:

  1. Customization: You have full control over the model and can fine-tune it to better suit your specific needs and preferences.
  2. Offline Access: You can use the model even without an internet connection, making it more reliable in various situations.
  3. Cost Efficiency: Avoiding cloud service fees can be more economical, especially for extensive or long-term use.

These advantages make running DeepSeek LLM locally a powerful option for developers and users who prioritize privacy.

The following steps show the integration of LM Studio with iTerm2.

LM Studio

Download your preferred LLM and load the Model:

  1. Jump to the Developer screen
  2. Open Settings and set the Server Port to: 11434
  3. Start the Engine

The screen shows now a running service:

Click on the copy-button and close the page

iTerm2

Open the Settings of iTerm2

  1. install the plugin
  2. Enable AI features
  3. enter any API Key (entry is necessary but is not checked locally)
  4. For the first test you can leave the AI Prompt
  5. Use llama3:latest Model
  6. paste the URL copied from LM Studio and add /v1/chat/completions

    The final URL is then
    http://localhost:11434/v1/chat/completions

close the Settings-Windows

Action

-Press command-y in your iTerm2 session
-type your question into the windows and press shift-enter to ask your LLM:

Now you can use your local running LLM, even when you switch off your network-adapter 🙂