Networks, VPNs & Firewalls

This page collects knowledge about home networking, routers, VPNs, and firewall setups that appeared in the group.

WireGuard is frequently recommended as the default VPN choice:

• WireGuard:
  • Very small codebase and modern cryptography.
  • Excellent performance and low latency.
  • Easy to configure: each peer has a private/public key pair and an allowed IP range.

• OpenVPN:
  • Older, battle-tested.
  • Extremely flexible; supports many auth methods.
  • Typically more complex to configure and tune.

General pattern:

• For your own infrastructure (home server, lab, family access): prefer WireGuard.
• Use OpenVPN only where compatibility or policy demands it.

Example minimal WireGuard server configuration snippet:

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <server_private_key>

[Peer]
# laptop
PublicKey = <laptop_public_key>
AllowedIPs = 10.0.0.2/32

Common scenarios discussed:

• Remote access to home NAS or services.
• Administering self-hosted applications on the LAN while away.
• Exposing a single client with fixed IP through WireGuard for easier firewall rules.

Typical recommendation:

• Have a single WireGuard endpoint on your router/home server.
• Allow only the VPN subnet to reach your internal services (via firewall rules).
• Use a dynamic DNS name if you don’t have a static public IP.

Advanced home users often move from ISP-provided routers to something more capable:

• OPNsense (and pfSense) appear as common firewall/router OS choices:
  • Stateful firewall, NAT, traffic shaping, VPNs, VLANs, captive portals.
  • Run on small x86 hardware (fanless boxes, old PCs).

• MikroTik hEX and similar routers:
  • Affordable and powerful small routers.
  • Require learning RouterOS concepts (interfaces, queues, bridges, firewall).

Key ideas:

• Terminate VPNs on the router or firewall:
  • Gives full-network access via VPN.
  • Simplifies ACLs and per-subnet rules.

• Use VLANs where possible:
  • Separate “trusted” LAN, guest Wi-Fi, IoT, and servers.
  • Apply stricter rules to IoT/guest segments.

Guiding principles evident from discussions:

• Prefer “default deny”:
  • WAN → LAN: block everything except what is explicitly needed.
  • LAN → WAN: restrict sensitive servers if they do not need outgoing internet.

• Avoid exposing raw admin interfaces:
  • Don’t port-forward SSH or databases directly from the internet.
  • Use VPN + SSH, or at least restrict allowed IPs strongly.

• Log and monitor:
  • Enable firewall logging for dropped packets on WAN.
  • Use tools like `vnstat`, `nload` or router-integrated graphs to catch anomalies.

• Keep configuration in version-controlled backups:
  • Export OPNsense/pfSense/MikroTik configs regularly.
  • Store them in a private Git repository.

A recurring theme is that simpler network topologies are easier to secure. Extra complexity must justify itself.