Category: Network and IT System

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

  • Secure Split-Tunnel WireGuard + AdGuard + UFW

    This SOP is the final, stable operating procedure for a small production homelab using WireGuard, AdGuard Home, Docker monitoring, and UFW. It reflects all fixes, decisions, and lessons learned.


    1) Design Goals

    • Secure private management traffic
    • No performance impact on internet traffic
    • Public DNS via AdGuard Home (intentional)
    • No public exposure of admin or Docker APIs
    • Simple, predictable routing and firewall rules

    2) Final Network Model

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

    3) 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
    

    Clients (Pi1 / Pi2)

    [Interface]
    Address = PLEASE_PUT_YOUR_PI_WG_IP
    PrivateKey = PLEASE_PUT_YOUR_PI_PRIVATE_KEY
    # No DNS line (AdGuard 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

    ❌ Never use /0 unless intentionally building a full-tunnel VPN.


    4) Routing Verification (MANDATORY)

    On each client:

    ip route
    

    Expected:

    • Default route → LAN gateway
    • 10.8.0.0/24wg0

    If default route points to wg0, stop and fix before continuing.


    5) DNS Model (FINAL)

    • AdGuard Home runs locally on a Raspberry Pi
    • WireGuard must not override DNS
    • No DNS= entry in any WireGuard config

    Public DNS services:

    • 53/udp
    • 53/tcp
    • 853/tcp (DNS-over-TLS)

    WireGuard DNS access is also allowed for internal clients.


    6) IPv6 Policy (FINAL)

    IPv6 is permanently disabled to reduce complexity and avoid dual-stack edge cases.

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

    UFW IPv6 handling is disabled:

    IPV6=no
    

    7) Firewall Policy (UFW — FINAL)

    Default Policy

    ufw default deny incoming
    ufw default allow outgoing
    

    Publicly Exposed Ports (INTENTIONAL)

    ufw allow 22/tcp        # SSH (rate-limited or WG-only)
    ufw allow 80/tcp        # HTTP
    ufw allow 443/tcp       # HTTPS
    ufw allow 51820/udp     # WireGuard
    ufw allow 53/udp        # DNS
    ufw allow 53/tcp        # DNS
    ufw allow 853/tcp       # DNS-over-TLS
    

    WireGuard Internal Traffic

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

    SSH (Choose One)

    WireGuard-only (recommended):

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

    OR public but rate-limited:

    ufw limit 22/tcp
    

    8) Docker Monitoring Policy (FINAL)

    • Docker API is never public
    • Access only over WireGuard
    • Prefer docker-socket-proxy

    Firewall rule:

    ufw allow from 10.8.0.0/24 to any port 2375
    

    Used by Uptime Kuma for monitoring only.


    9) Automation & Defense-in-Depth

    • AdGuard logs feed n8n automation
    • Attacking IPs are auto-blocked
    • Firewall provides first-layer filtering
    • Automation provides adaptive response

    Always whitelist:

    • 10.8.0.0/24
    • Admin IPs
    • Health-check sources

    10) Validation Checklist (RUN AFTER CHANGES)

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

    All must pass.


    11) Known Pitfalls (DO NOT REPEAT)

    • AllowedIPs = 0.0.0.0/0 (unintended full tunnel)
    • ❌ Setting WireGuard DNS when AdGuard is local
    • ❌ Exposing Docker ports publicly
    • ❌ Using HTTPS proxies to “secure” Docker API
    • ❌ Relying on UFW NAT side-effects for routing

    12) Final State

    • Fast internet (no tunnel overhead)
    • Encrypted management traffic
    • Public DNS intentionally exposed
    • Minimal, auditable firewall rules
    • No hidden routing or NAT dependencies

    This SOP represents the final, correct configuration.

Secret Link