Category: Server

  • Understanding the UFW Rule: Allowing TCP Access to Port 8123 from a Specific IP

    Firewalls are a foundational component of any secure Linux system. On Ubuntu and other Debian-based distributions, UFW (Uncomplicated Firewall) provides a simple yet powerful interface for managing firewall rules.

    In this post, we’ll break down the following UFW rule, explain what it does, and discuss when and why you might use it:

    sudo ufw allow from 10.8.0.2 to any port 8123 proto tcp
    

    What Is UFW?

    UFW is a frontend for iptables designed to make firewall configuration easier and less error-prone. Instead of dealing with complex rule chains, UFW lets administrators define intent-based rules that are readable and maintainable.


    Breaking Down the Rule

    Let’s look at each part of the command in detail.

    sudo

    Firewall rules require administrative privileges. sudo ensures the command is executed with root permissions.

    ufw allow

    This tells UFW to permit traffic that matches the rule. UFW rules typically fall into three categories:

    • allow
    • deny
    • reject

    In this case, we are explicitly allowing traffic.

    from 10.8.0.2

    This restricts the rule to traffic originating only from the IP address 10.8.0.2.

    This is an important security control:
    instead of opening a port to the entire internet, access is limited to a trusted host.
    IP addresses in the 10.0.0.0/8 range are private addresses, commonly used for:

    • VPNs (OpenVPN, WireGuard)
    • Internal networks
    • Secure tunnels between services

    to any port 8123

    This specifies the destination:

    • Any local interface on the machine
    • Port 8123

    Port 8123 is often used by applications such as:

    • Home Assistant
    • Custom web dashboards
    • Internal APIs
    • Development or monitoring tools

    proto tcp

    This limits the rule to TCP traffic only.

    That matters because:

    • TCP is connection-oriented and reliable
    • UDP traffic to the same port would still be blocked unless explicitly allowed

    What This Rule Accomplishes

    In plain language, this rule means:

    “Allow TCP connections to port 8123 on this server, but only if they come from 10.8.0.2.”

    Everything else—other IPs, other ports, or other protocols—remains blocked by default.


    Why This Is a Best Practice

    This rule demonstrates several strong security principles:

    ✅ Principle of Least Privilege

    Only a single IP address is allowed access, rather than opening the port globally.

    ✅ Reduced Attack Surface

    Even if port scans are performed, the service is unreachable from unauthorized sources.

    ✅ Clear Intent

    The rule is readable and self-documenting, which makes long-term maintenance easier.


    Verifying the Rule

    After adding the rule, you can confirm it with:

    sudo ufw status verbose
    

    You should see an entry similar to:

    8123/tcp ALLOW IN From 10.8.0.2
    

    Common Use Cases

    This type of rule is commonly used for:

    • Allowing VPN clients to access internal services
    • Restricting admin dashboards to a jump host
    • Securing IoT or automation services
    • Protecting internal APIs from public exposure

    Final Thoughts

    The command:

    sudo ufw allow from 10.8.0.2 to any port 8123 proto tcp
    

    is a great example of how UFW can be both simple and secure. By combining IP-based restrictions, port targeting, and protocol control, you can expose only what’s necessary—nothing more.

    If you’re managing services that don’t need public access, rules like this should be your default approach.

  • Building a Secure, Split‑Tunnel WireGuard Homelab (End‑to‑End)

    This page documents the complete, final configuration of a secure homelab built with WireGuard, Raspberry Pis, UFW, AdGuard Home, Fail2Ban, n8n automation, and Uptime Kuma. It is written as a from‑top‑to‑bottom reference: design intent, implementation, validation, and final security posture.

    The goal is not maximum complexity, but clear, intentional security that is easy to operate and reason about.


    Design Goals

    • Secure all management access using WireGuard
    • Preserve full internet speed (no full‑tunnel VPN)
    • Expose only explicitly intended public services
    • Eliminate accidental routing, NAT, and DNS side effects
    • Provide monitoring, alerting, and automated response
    • Keep the system auditable and maintainable

    Final Architecture Overview

    • Main Server: WireGuard server and central management node
    • Raspberry Pi 1 & 2: WireGuard clients and service hosts
    • VPN Subnet: 10.8.0.0/24
    • Tunnel Mode: Split tunnel (VPN traffic only)
    • DNS: Local (AdGuard Home on Raspberry Pi)
    • Firewall: UFW (IPv4 only)
    • IPv6: Disabled intentionally

    Only traffic destined for the VPN subnet traverses WireGuard. All normal internet traffic continues to use the local gateway.


    WireGuard Configuration (Final)

    Server — /etc/wireguard/wg0.conf

    [Interface]
    Address = 10.8.0.1/24
    ListenPort = 51820
    PrivateKey = PLEASE_PUT_YOUR_SERVER_PRIVATE_KEY
    
    [Peer]
    PublicKey = PLEASE_PUT_YOUR_PI1_PUBLIC_KEY
    AllowedIPs = 10.8.0.2/32
    
    [Peer]
    PublicKey = PLEASE_PUT_YOUR_PI2_PUBLIC_KEY
    AllowedIPs = 10.8.0.3/32
    

    Raspberry Pi Clients — /etc/wireguard/wg0.conf

    [Interface]
    Address = PLEASE_PUT_YOUR_PI_WG_IP
    PrivateKey = PLEASE_PUT_YOUR_PI_PRIVATE_KEY
    # No DNS line (AdGuard Home runs locally)
    
    [Peer]
    PublicKey = PLEASE_PUT_YOUR_SERVER_PUBLIC_KEY
    Endpoint = PLEASE_PUT_YOUR_SERVER_PUBLIC_IP_OR_DNS:51820
    AllowedIPs = 10.8.0.0/24
    PersistentKeepalive = 25
    

    Critical rule: AllowedIPs = 10.8.0.0/24

    Using /0 would unintentionally create a full‑tunnel VPN and introduce NAT dependencies. The /24 mask ensures a true split tunnel.


    Routing Validation (Required)

    On each Raspberry Pi:

    ip route
    

    Expected output:

    • Default route → LAN gateway
    • 10.8.0.0/24wg0

    If the default route points to wg0, stop and correct the configuration before continuing.


    DNS Design (AdGuard Home)

    • AdGuard Home runs locally on a Raspberry Pi
    • WireGuard does not override DNS
    • No DNS= directive exists in WireGuard configs

    Public DNS services are intentionally exposed:

    • 53/udp, 53/tcp — DNS
    • 853/tcp — DNS‑over‑TLS

    DNS logs feed automation for abuse detection and response.


    IPv6 Policy

    IPv6 is intentionally disabled to reduce complexity and avoid dual‑stack routing and DNS edge cases common in small environments.

    Sysctl — /etc/sysctl.d/99-disable-ipv6.conf

    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    

    UFW IPv6 toggle — /etc/default/ufw

    IPV6=no
    

    The environment operates entirely over IPv4.


    Firewall Policy (UFW — Final)

    Default Policy

    ufw default deny incoming
    ufw default allow outgoing
    

    Publicly Exposed (Intentional)

    • 22/tcp — SSH (WireGuard‑only or rate‑limited)
    • 80/tcp — HTTP
    • 443/tcp — HTTPS
    • 51820/udp — WireGuard
    • 53/udp, 53/tcp — DNS
    • 853/tcp — DNS‑over‑TLS

    WireGuard Internal Access

    ufw allow in on wg0
    ufw allow in on wg0 to any port 53
    ufw allow in on wg0 to any port 853
    

    SSH Access Model

    Preferred (WireGuard‑only):

    ufw allow from 10.8.0.0/24 to any port 22 proto tcp
    

    External scans and LAN SSH attempts correctly show blocked.


    SSH Hardening

    • SSH key‑only authentication
    • Password authentication disabled
    • Root login avoided or disabled
    • SSH reachable only via WireGuard IPs

    Ping confirms network reachability. SSH access requires correct user and authorized key placement.


    Docker Monitoring (Uptime Kuma)

    • Docker API is never public
    • Accessed only over WireGuard
    • Exposed via read‑only docker‑socket‑proxy

    Firewall rule:

    ufw allow from 10.8.0.0/24 to any port 2375
    

    This allows monitoring without exposing control capabilities.


    Detection, Alerting, and Automation

    • Fail2Ban blocks brute‑force attempts
    • AdGuard Home logs capture DNS abuse
    • n8n processes events every minute
    • Automated IP blocking is applied
    • Alerts are delivered to Slack
    • Uptime Kuma monitors hosts and containers

    This provides a full detect → alert → respond pipeline.


    Validation Checklist

    wg
    ip route
    ping 10.8.0.1
    ping 8.8.8.8
    ping google.com
    ufw status verbose
    ss -tulpen | head -n 30
    

    External port scans for SSH should show blocked. SSH access works only from WireGuard peers using WireGuard IPs.


    Common Pitfalls (Avoided)

    • AllowedIPs = 0.0.0.0/0 (unintended full tunnel)
    • Overriding DNS when AdGuard runs locally
    • Exposing Docker APIs publicly
    • Using HTTPS proxies as Docker security
    • Relying on firewall NAT side effects

    Final Summary

    This setup results in a secure, split‑tunnel WireGuard network between a main server and multiple Raspberry Pis, while keeping performance high and avoiding unnecessary complexity.

    The main server acts as the WireGuard server, and each Raspberry Pi connects as a client on a private VPN subnet (10.8.0.0/24). Only internal VPN traffic is routed through WireGuard, while normal internet traffic continues to use each device’s local gateway. This design avoids speed degradation and removes the need for NAT or full‑tunnel routing.

    DNS handling is intentionally local. Because one Raspberry Pi runs AdGuard Home, WireGuard does not override system DNS settings, preventing common resolution issues and keeping behavior predictable.

    IPv6 is permanently disabled to reduce complexity and avoid dual‑stack edge cases. The firewall exposes only explicitly intended services, and SSH access is restricted to WireGuard peers using key‑only authentication.

    Monitoring, alerting, and automated response are handled through Uptime Kuma, Fail2Ban, and n8n, providing real‑time visibility and protection.

    The final result is a fast, secure, low‑maintenance homelab with a clearly defined attack surface, intentional access paths, and documented operating procedures — designed for reliability rather than complexity.

  • 0) Goals we achieved

    • Main server runs WireGuard server (wg0)
    • Pi1 + Pi2 run WireGuard clients
    • Split tunnel (VPN traffic only; internet stays normal/fast)
    • AdGuard Home runs on a Pi and keeps DNS control (no WG DNS override)
    • Optional: Monitor Docker hosts from Uptime Kuma over WireGuard
    • IPv6 permanently disabled (optional)
    • UFW firewall locked down with only the ports you want public

    1) WireGuard on the Main Server (Server side)

    1.1 Install

    sudo apt update
    sudo apt install -y wireguard
    

    1.2 Generate keys

    wg genkey | sudo tee /etc/wireguard/server.key | wg pubkey | sudo tee /etc/wireguard/server.pub >/dev/null
    sudo chmod 600 /etc/wireguard/server.key
    

    1.3 Create /etc/wireguard/wg0.conf

    sudo nano /etc/wireguard/wg0.conf
    

    Paste:

    [Interface]
    Address = 10.8.0.1/24
    ListenPort = 51820
    PrivateKey = <SERVER_PRIVATE_KEY>
    

    Insert the private key:

    sudo cat /etc/wireguard/server.key
    

    1.4 Enable + start

    sudo systemctl enable wg-quick@wg0
    sudo systemctl start wg-quick@wg0
    sudo wg
    

    2) WireGuard on Raspberry Pi 1 and Pi 2 (Client side)

    Do this on each Pi, changing the IP.

    2.1 Install

    sudo apt update
    sudo apt install -y wireguard
    

    2.2 Generate keys

    wg genkey | tee ~/client.key | wg pubkey > ~/client.pub
    chmod 600 ~/client.key
    

    2.3 Create /etc/wireguard/wg0.conf

    Pi1 config (10.8.0.2)

    sudo nano /etc/wireguard/wg0.conf
    
    [Interface]
    Address = 10.8.0.2/24
    PrivateKey = <PI1_PRIVATE_KEY>
    # IMPORTANT: No DNS line (because you run AdGuard)
    
    [Peer]
    PublicKey = <SERVER_PUBLIC_KEY>
    Endpoint = <SERVER_PUBLIC_IP>:51820
    AllowedIPs = 10.8.0.0/24
    PersistentKeepalive = 25
    

    Pi2 config (10.8.0.3)

    Same, but:

    Address = 10.8.0.3/24
    PrivateKey = <PI2_PRIVATE_KEY>
    

    Critical split tunnel rule:

    AllowedIPs = 10.8.0.0/24
    

    ❌ Do NOT use .../0 or 0.0.0.0/0.

    2.4 Start on each Pi

    sudo systemctl enable wg-quick@wg0
    sudo systemctl start wg-quick@wg0
    sudo wg
    

    3) Add Pi peers to the Main Server

    On the main server, open:

    sudo nano /etc/wireguard/wg0.conf
    

    Add:

    [Peer]
    PublicKey = <PI1_PUBLIC_KEY>
    AllowedIPs = 10.8.0.2/32
    
    [Peer]
    PublicKey = <PI2_PUBLIC_KEY>
    AllowedIPs = 10.8.0.3/32
    

    Restart:

    sudo systemctl restart wg-quick@wg0
    sudo wg
    

    4) Verify split tunnel is correct

    4.1 Tunnel ping tests

    From Pi1/Pi2:

    ping 10.8.0.1
    

    From server:

    ping 10.8.0.2
    ping 10.8.0.3
    

    4.2 Confirm internet stays normal (split tunnel)

    On Pi2:

    ip route
    

    You should see:

    • default route via your LAN gateway (ex: 192.168.x.1)
    • 10.8.0.0/24 dev wg0

    If you ever see default via wg0, you accidentally full-tunneled.


    5) DNS note (AdGuard Home on Pi)

    You fixed this correctly.

    ✅ If AdGuard runs on the Pi, do NOT set DNS = ... in the WG config.
    Because WireGuard would override system DNS and break resolution.


    6) Optional: Disable IPv6 permanently (Ubuntu / Pi)

    6.1 Sysctl method (recommended)

    sudo nano /etc/sysctl.d/99-disable-ipv6.conf
    

    Paste:

    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    

    Apply:

    sudo sysctl --system
    

    Verify:

    ip a | grep inet6
    

    7) Firewall (UFW) with your current public ports (22, 80, 443)

    7.1 Reset + defaults

    sudo ufw disable
    sudo ufw reset
    sudo ufw default deny incoming
    sudo ufw default allow outgoing
    

    7.2 Allow required ports

    SSH (choose one)

    Safer (WireGuard only):

    sudo ufw allow from 10.8.0.0/24 to any port 22 proto tcp comment "SSH via WireGuard"
    

    Or if public SSH is needed:

    sudo ufw limit 22/tcp comment "SSH rate limit"
    

    HTTP/HTTPS:

    sudo ufw allow 80/tcp comment "HTTP"
    sudo ufw allow 443/tcp comment "HTTPS"
    

    WireGuard port:

    sudo ufw allow 51820/udp comment "WireGuard"
    sudo ufw allow in on wg0 comment "WireGuard tunnel"
    

    7.3 Enable

    sudo ufw enable
    sudo ufw status numbered
    sudo ufw status verbose
    

    8) Optional: Docker monitoring over WireGuard (Uptime Kuma)

    8.1 Install docker socket proxy on each Pi (recommended)

    Create docker-compose.yml:

    version: "3.8"
    services:
      docker-socket-proxy:
        image: tecnativa/docker-socket-proxy
        container_name: docker-socket-proxy
        ports:
          - "2375:2375"
        environment:
          CONTAINERS: 1
          INFO: 1
          PING: 1
          VERSION: 1
        volumes:
          - /var/run/docker.sock:/var/run/docker.sock:ro
        restart: unless-stopped
    

    Run:

    docker compose up -d
    

    8.2 Firewall: allow Docker proxy ONLY over WireGuard

    On each Pi:

    sudo ufw allow from 10.8.0.0/24 to any port 2375 comment "Docker API via WireGuard only"
    

    8.3 Add in Uptime Kuma

    • Monitor Type: Docker Host
    • URL:
      • http://10.8.0.2:2375
      • http://10.8.0.3:2375

    9) What NOT to do (the pitfalls we hit)

    • ❌ Don’t expose Docker 2375 publicly
    • ❌ Don’t use AllowedIPs = .../0 (that becomes full tunnel)
    • ❌ Don’t set DNS = 10.8.0.1 unless server truly runs DNS
    • ❌ Don’t rely on Certbot/Caddy to “secure Docker API” (wrong model)
    • ✅ Use WireGuard + firewall instead

    Quick “health checklist” commands

    On any node:

    sudo wg
    ip route
    sudo ufw status verbose
    ss -tulpen | head -n 30
    

    If you want, I can also generate a one-page printable version of this runbook with:

    • blanks for keys/IPs
    • checkboxes
    • and “expected outputs” for each command.
Secret Link