[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73C3ACTNBDCVFDFY5VNHP73":3,"skill-same:01M73C3ACTNBDCVFDFY5VNHP73":49},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M73C3ACTNBDCVFDFY5VNHP73","homelab-wireguard-vpn",null,"WireGuard VPN server setup, peer configuration, key generation, split tunneling vs full tunnel routing, and remote access to a home network from mobile and laptop clients.","Horonomos-laps\u002FYana-AI","Horonomos-laps","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F355299122?v=4","01M76B3QPXE88ET2SQPDPVATZT"," Horonomos-laps","01M72ZQRJPCYPSSWT4D00VJR2A",13,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fhomelab-wireguard-vpn\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: homelab-wireguard-vpn\ndescription: WireGuard VPN server setup, peer configuration, key generation, split tunneling vs full tunnel routing, and remote access to a home network from mobile and laptop clients.\norigin: community\n---\n\n# Homelab WireGuard VPN\n\nWireGuard is a fast, modern VPN protocol. It is the right choice for remote access to a\nhome network — simpler to configure than OpenVPN and faster than most alternatives.\n\nAll configuration examples show common setups. Review each command — especially the\niptables forwarding rules and key file permissions — before applying them to your\nsystem, and make changes in a maintenance window.\n\n## When to Use\n\n- Setting up WireGuard server on a Raspberry Pi, Linux host, pfSense, or router\n- Generating WireGuard keypairs and writing peer config files\n- Configuring remote access from a phone or laptop to a home network\n- Explaining split tunneling (route only home traffic) vs full tunnel (route all traffic)\n- Troubleshooting WireGuard connections that will not come up\n- Automating peer configuration generation for multiple clients\n\n## How WireGuard Works\n\n```\nYour phone (WireGuard client)\n    │\n    │  Encrypted UDP tunnel (port 51820)\n    │\nYour home router (WireGuard server — needs a public IP or DDNS)\n    │\n    Your home network (192.168.1.0\u002F24, NAS, Pi, etc.)\n\nEvery device has a keypair (public + private key).\nThe server knows each client's public key.\nThe client knows the server's public key + endpoint (IP:port).\nTraffic is encrypted end-to-end with no central server or certificate authority.\n```\n\n## Server Setup (Linux)\n\n```bash\n# Install WireGuard\nsudo apt update && sudo apt install wireguard -y\n\n# Generate server keypair — create files with private permissions from the start\nsudo mkdir -p \u002Fetc\u002Fwireguard\nsudo sh -c 'umask 077; wg genkey > \u002Fetc\u002Fwireguard\u002Fserver_private.key'\nsudo sh -c 'wg pubkey \u003C \u002Fetc\u002Fwireguard\u002Fserver_private.key > \u002Fetc\u002Fwireguard\u002Fserver_public.key'\n\n# Write server config — substitute the actual private key value\n# Do not store private keys in version control or share them\nsudo tee \u002Fetc\u002Fwireguard\u002Fwg0.conf \u003C\u003C 'EOF'\n[Interface]\nAddress = 10.8.0.1\u002F24              # VPN subnet — server gets .1\nListenPort = 51820\nPrivateKey = \u003Cpaste_server_private_key_here>\n\n# Scoped forwarding rules: allow VPN traffic in\u002Fout, not a blanket FORWARD ACCEPT\nPostUp   = iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT\nPostUp   = iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT\nPostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE\nPostDown = iptables -D FORWARD -i wg0 -o eth0 -j ACCEPT\nPostDown = iptables -D FORWARD -i eth0 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT\nPostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE\n\n[Peer]\n# Phone — replace with the actual phone public key\nPublicKey = \u003Cphone_public_key>\nAllowedIPs = 10.8.0.2\u002F32\n\n[Peer]\n# Laptop — replace with the actual laptop public key\nPublicKey = \u003Claptop_public_key>\nAllowedIPs = 10.8.0.3\u002F32\nEOF\nsudo chmod 600 \u002Fetc\u002Fwireguard\u002Fwg0.conf\n\n# Replace eth0 with your actual outbound interface name\n# Check with: ip route show default\n\n# Enable IP forwarding (required for routing traffic through the server)\necho \"net.ipv4.ip_forward=1\" | sudo tee \u002Fetc\u002Fsysctl.d\u002F99-wireguard.conf\nsudo sysctl --system\n\n# Start WireGuard and enable on boot\nsudo wg-quick up wg0\nsudo systemctl enable wg-quick@wg0\n```\n\n## Client Configuration\n\n```bash\n# Generate a unique keypair for each client device\n# Run on the client, or on the server and transfer the private key securely — never in plaintext\numask 077\nwg genkey | tee phone_private.key | wg pubkey > phone_public.key\n\n# Client config file (phone_wg0.conf):\n[Interface]\nPrivateKey = \u003Cphone_private_key>\nAddress = 10.8.0.2\u002F32\nDNS = 192.168.1.2                  # Optional: use Pi-hole for DNS over the tunnel\n\n[Peer]\nPublicKey = \u003Cserver_public_key>\nEndpoint = your-home-ip.ddns.net:51820  # Your public IP or DDNS hostname\nAllowedIPs = 192.168.1.0\u002F24            # Split tunnel: only home network traffic\n# AllowedIPs = 0.0.0.0\u002F0, ::\u002F0        # Full tunnel: all traffic through VPN\n\nPersistentKeepalive = 25              # Keep NAT hole open (required for mobile clients)\n```\n\n## Split Tunnel vs Full Tunnel\n\n```\n# Split tunnel: AllowedIPs = 192.168.1.0\u002F24\n  Only traffic destined for your home network goes through the VPN.\n  Internet traffic (YouTube, Spotify) goes directly — better performance on mobile.\n  Best for: \"I just want to reach my NAS and Pi from anywhere.\"\n\n# Full tunnel: AllowedIPs = 0.0.0.0\u002F0, ::\u002F0\n  ALL traffic goes through your home internet connection.\n  Useful for: piggybacking home DNS\u002FPi-hole ad blocking.\n  Downside: home upload speed becomes your bottleneck everywhere.\n\n# Multi-subnet split tunnel (most common homelab use case):\n  AllowedIPs = 192.168.10.0\u002F24, 192.168.20.0\u002F24, 192.168.30.0\u002F24, 10.8.0.0\u002F24\n  Routes all your VLANs through the tunnel; internet stays direct.\n```\n\n## Key Generation and Peer Management\n\n```python\nimport subprocess\n\ndef generate_keypair() -> tuple[str, str]:\n    \"\"\"Generate a WireGuard keypair. Returns (private_key, public_key).\"\"\"\n    private = subprocess.check_output([\"wg\", \"genkey\"]).decode().strip()\n    public = subprocess.run(\n        [\"wg\", \"pubkey\"], input=private.encode(), capture_output=True\n    ).stdout.decode().strip()\n    return private, public\n\ndef generate_preshared_key() -> str:\n    return subprocess.check_output([\"wg\", \"genpsk\"]).decode().strip()\n\ndef build_client_config(\n    client_private_key: str,\n    client_vpn_ip: str,       # e.g. \"10.8.0.3\"\n    server_public_key: str,\n    server_endpoint: str,     # e.g. \"home.example.com:51820\"\n    allowed_ips: str = \"192.168.1.0\u002F24\",\n    dns: str = \"\",\n) -> str:\n    dns_line = f\"DNS = {dns}\\n\" if dns else \"\"\n    return f\"\"\"[Interface]\nPrivateKey = {client_private_key}\nAddress = {client_vpn_ip}\u002F32\n{dns_line}\n[Peer]\nPublicKey = {server_public_key}\nEndpoint = {server_endpoint}\nAllowedIPs = {allowed_ips}\nPersistentKeepalive = 25\n\"\"\"\n\ndef build_server_peer_block(\n    client_public_key: str,\n    client_vpn_ip: str,\n    comment: str = \"\",\n) -> str:\n    comment_line = f\"# {comment}\\n\" if comment else \"\"\n    return f\"\"\"\n{comment_line}[Peer]\nPublicKey = {client_public_key}\nAllowedIPs = {client_vpn_ip}\u002F32\n\"\"\"\n```\n\nKeep private keys out of source control. If you use this script, write key material\nto files with mode 600 and never log or print it.\n\n## pfSense \u002F OPNsense WireGuard\n\n```\n# pfSense: VPN → WireGuard → Add Tunnel\n  Interface Keys: Generate (creates keypair automatically)\n  Listen Port: 51820\n  Interface Address: 10.8.0.1\u002F24\n\n# Add Peer (one per client):\n  Public Key: \u003Cclient public key>\n  Allowed IPs: 10.8.0.2\u002F32\n\n# Assign the WireGuard interface:\n  Interfaces → Assignments → Add (select wg0)\n  Enable interface, no IP needed (it is set in the tunnel config)\n\n# Firewall rules:\n  WAN → Allow UDP port 51820 inbound (so clients can reach the server)\n  WireGuard interface → Allow traffic to LAN networks you want reachable\n```\n\n## DDNS (Dynamic DNS) for Home Servers\n\nMost home internet connections have a dynamic IP. Use DDNS so your VPN endpoint\nstays reachable after an IP change.\n\n```bash\n# Option 1: Cloudflare DDNS — store credentials in a secrets file, not inline\n# docker-compose entry using an env file:\n  ddns-updater:\n    image: qmcgaw\u002Fddns-updater\n    env_file: .\u002Fddns.env   # store zone_id and token here, not in compose\n    restart: unless-stopped\n\n# ddns.env (chmod 600, not committed to git):\n#   SETTINGS_CLOUDFLARE_ZONE_ID=your_zone_id\n#   SETTINGS_CLOUDFLARE_TOKEN=your_api_token\n\n# Option 2: DuckDNS (free, simple)\n  Sign up at duckdns.org → get a token and subdomain (myhome.duckdns.org)\n  Store token in \u002Fetc\u002Fddns.env (mode 600), then use a small root-owned script:\n\n  # \u002Fusr\u002Flocal\u002Fbin\u002Fupdate-duckdns\n  #!\u002Fbin\u002Fsh\n  set -eu\n  . \u002Fetc\u002Fddns.env\n  curl --fail --silent --show-error --max-time 10 \\\n    --get \"https:\u002F\u002Fwww.duckdns.org\u002Fupdate\" \\\n    --data-urlencode \"domains=myhome\" \\\n    --data-urlencode \"token=${DUCKDNS_TOKEN}\" \\\n    --data-urlencode \"ip=\"\n\n  # Cron job:\n  *\u002F5 * * * * \u002Fusr\u002Flocal\u002Fbin\u002Fupdate-duckdns >\u002Fdev\u002Fnull 2>&1\n```\n\n## Troubleshooting\n\n```bash\n# Check WireGuard status and last handshake\nsudo wg show\n\n# If \"latest handshake\" is never or very old, the tunnel is not connected.\n# Check:\n# 1. Is UDP port 51820 open on the router\u002Ffirewall?\nsudo ufw status  # or check pfSense\u002FUniFi firewall rules\n\n# 2. Is the server public key in the client config correct?\nsudo wg show wg0 public-key   # Compare to what is in the client config\n\n# 3. Is IP forwarding enabled on the server?\ncat \u002Fproc\u002Fsys\u002Fnet\u002Fipv4\u002Fip_forward  # Should be 1\n\n# 4. Does the client AllowedIPs cover the IP you are trying to reach?\n# If AllowedIPs = 192.168.1.0\u002F24 and you are trying to reach 192.168.3.5, it will not route.\n\n# Check kernel logs for WireGuard errors\ndmesg | grep wireguard\n\n# Restart WireGuard\nsudo wg-quick down wg0 && sudo wg-quick up wg0\n```\n\n## Anti-Patterns\n\n```\n# BAD: Storing private keys in version control or sharing them\n# Private keys are equivalent to passwords — never commit them to git\n\n# BAD: Using AllowedIPs = 0.0.0.0\u002F0 on mobile without considering the impact\n# Full tunnel routes all mobile traffic through your home upload — usually slow\n\n# BAD: Not setting PersistentKeepalive on mobile clients\n# Mobile clients behind NAT drop idle tunnels without it\n\n# BAD: Opening port 51820 in the firewall but forgetting IP forwarding on the server\n# Tunnel connects but no traffic routes — confusing to debug\n\n# BAD: Sharing a keypair across multiple client devices\n# Each device must have its own unique keypair — shared keys break the security model\n\n# BAD: Using a broad \"FORWARD ACCEPT\" iptables rule\n# Scope forwarding rules to the wg0 interface and direction only\n```\n\n## Best Practices\n\n- Generate a unique keypair per client device — never reuse keys\n- Use split tunneling (`AllowedIPs = \u003Chome subnets>`) for mobile\n- Set `PersistentKeepalive = 25` on all mobile clients\n- Use DDNS if your ISP assigns a dynamic IP; store credentials in env files, not inline\n- Use scoped iptables forwarding rules (inbound on wg0 only) rather than a blanket FORWARD ACCEPT\n- Add Pi-hole's IP as `DNS =` in client configs to get ad blocking over the VPN\n- Rotate the server keypair periodically and update all client configs\n\n## Related Skills\n\n- homelab-network-setup\n- homelab-vlan-segmentation\n- homelab-pihole-dns\n","# Homelab WireGuard VPN\n\nWireGuard is a fast, modern VPN protocol. It is the right choice for remote access to a\nhome network — simpler to configure than OpenVPN and faster than most alternatives.\n\nAll configuration examples show common setups. Review each command — especially the\niptables forwarding rules and key file permissions — before applying them to your\nsystem, and make changes in a maintenance window.\n\n## When to Use\n\n- Setting up WireGuard server on a Raspberry Pi, Linux host, pfSense, or router\n- Generating WireGuard keypairs and writing peer config files\n- Configuring remote access from a phone or laptop to a home network\n- Explaining split tunneling (route only home traffic) vs full tunnel (route all traffic)\n- Troubleshooting WireGuard connections that will not come up\n- Automating peer configuration generation for multiple clients\n\n## How WireGuard Works\n\n```\nYour phone (WireGuard client)\n    │\n    │  Encrypted UDP tunnel (port 51820)\n    │\nYour home router (WireGuard server — needs a public IP or DDNS)\n    │\n    Your home network (192.168.1.0\u002F24, NAS, Pi, etc.)\n\nEvery device has a keypair (public + private key).\nThe server knows each client's public key.\nThe client knows the server's public key + endpoint (IP:port).\nTraffic is encrypted end-to-end with no central server or certificate authority.\n```\n\n## Server Setup (Linux)\n\n```bash\n# Install WireGuard\nsudo apt update && sudo apt install wireguard -y\n\n# Generate server keypair — create files with private permissions from the start\nsudo mkdir -p \u002Fetc\u002Fwireguard\nsudo sh -c 'umask 077; wg genkey > \u002Fetc\u002Fwireguard\u002Fserver_private.key'\nsudo sh -c 'wg pubkey \u003C \u002Fetc\u002Fwireguard\u002Fserver_private.key > \u002Fetc\u002Fwireguard\u002Fserver_public.key'\n\n# Write server config — substitute the actual private key value\n# Do not store private keys in version control or share them\nsudo tee \u002Fetc\u002Fwireguard\u002Fwg0.conf \u003C\u003C 'EOF'\n[Interface]\nAddress = 10.8.0.1\u002F24              # VPN subnet — server gets .1\nListenPort = 51820\nPrivateKey = \u003Cpaste_server_private_key_here>\n\n# Scoped forwarding rules: allow VPN traffic in\u002Fout, not a blanket FORWARD ACCEPT\nPostUp   = iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT\nPostUp   = iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT\nPostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE\nPostDown = iptables -D FORWARD -i wg0 -o eth0 -j ACCEPT\nPostDown = iptables -D FORWARD -i eth0 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT\nPostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE\n\n[Peer]\n# Phone — replace with the actual phone public key\nPublicKey = \u003Cphone_public_key>\nAllowedIPs = 10.8.0.2\u002F32\n\n[Peer]\n# Laptop — replace with the actual laptop public key\nPublicKey = \u003Claptop_public_key>\nAllowedIPs = 10.8.0.3\u002F32\nEOF\nsudo chmod 600 \u002Fetc\u002Fwireguard\u002Fwg0.conf\n\n# Replace eth0 with your actual outbound interface name\n# Check with: ip route show default\n\n# Enable IP forwarding (required for routing traffic through the server)\necho \"net.ipv4.ip_forward=1\" | sudo tee \u002Fetc\u002Fsysctl.d\u002F99-wireguard.conf\nsudo sysctl --system\n\n# Start WireGuard and enable on boot\nsudo wg-quick up wg0\nsudo systemctl enable wg-quick@wg0\n```\n\n## Client Configuration\n\n```bash\n# Generate a unique keypair for each client device\n# Run on the client, or on the server and transfer the private key securely — never in plaintext\numask 077\nwg genkey | tee phone_private.key | wg pubkey > phone_public.key\n\n# Client config file (phone_wg0.conf):\n[Interface]\nPrivateKey = \u003Cphone_private_key>\nAddress = 10.8.0.2\u002F32\nDNS = 192.168.1.2                  # Optional: use Pi-hole for DNS over the tunnel\n\n[Peer]\nPublicKey = \u003Cserver_public_key>\nEndpoint = your-home-ip.ddns.net:51820  # Your public IP or DDNS hostname\nAllowedIPs = 192.168.1.0\u002F24            # Split tunnel: only home network traffic\n# AllowedIPs = 0.0.0.0\u002F0, ::\u002F0        # Full tunnel: all traffic through VPN\n\nPersistentKeepalive = 25              # Keep NAT hole open (required for mobile clients)\n```\n\n## Split Tunnel vs Full Tunnel\n\n```\n# Split tunnel: AllowedIPs = 192.168.1.0\u002F24\n  Only traffic destined for your home network goes through the VPN.\n  Internet traffic (YouTube, Spotify) goes directly — better performance on mobile.\n  Best for: \"I just want to reach my NAS and Pi from anywhere.\"\n\n# Full tunnel: AllowedIPs = 0.0.0.0\u002F0, ::\u002F0\n  ALL traffic goes through your home internet connection.\n  Useful for: piggybacking home DNS\u002FPi-hole ad blocking.\n  Downside: home upload speed becomes your bottleneck everywhere.\n\n# Multi-subnet split tunnel (most common homelab use case):\n  AllowedIPs = 192.168.10.0\u002F24, 192.168.20.0\u002F24, 192.168.30.0\u002F24, 10.8.0.0\u002F24\n  Routes all your VLANs through the tunnel; internet stays direct.\n```\n\n## Key Generation and Peer Management\n\n```python\nimport subprocess\n\ndef generate_keypair() -> tuple[str, str]:\n    \"\"\"Generate a WireGuard keypair. Returns (private_key, public_key).\"\"\"\n    private = subprocess.check_output([\"wg\", \"genkey\"]).decode().strip()\n    public = subprocess.run(\n        [\"wg\", \"pubkey\"], input=private.encode(), capture_output=True\n    ).stdout.decode().strip()\n    return private, public\n\ndef generate_preshared_key() -> str:\n    return subprocess.check_output([\"wg\", \"genpsk\"]).decode().strip()\n\ndef build_client_config(\n    client_private_key: str,\n    client_vpn_ip: str,       # e.g. \"10.8.0.3\"\n    server_public_key: str,\n    server_endpoint: str,     # e.g. \"home.example.com:51820\"\n    allowed_ips: str = \"192.168.1.0\u002F24\",\n    dns: str = \"\",\n) -> str:\n    dns_line = f\"DNS = {dns}\\n\" if dns else \"\"\n    return f\"\"\"[Interface]\nPrivateKey = {client_private_key}\nAddress = {client_vpn_ip}\u002F32\n{dns_line}\n[Peer]\nPublicKey = {server_public_key}\nEndpoint = {server_endpoint}\nAllowedIPs = {allowed_ips}\nPersistentKeepalive = 25\n\"\"\"\n\ndef build_server_peer_block(\n    client_public_key: str,\n    client_vpn_ip: str,\n    comment: str = \"\",\n) -> str:\n    comment_line = f\"# {comment}\\n\" if comment else \"\"\n    return f\"\"\"\n{comment_line}[Peer]\nPublicKey = {client_public_key}\nAllowedIPs = {client_vpn_ip}\u002F32\n\"\"\"\n```\n\nKeep private keys out of source control. If you use this script, write key material\nto files with mode 600 and never log or print it.\n\n## pfSense \u002F OPNsense WireGuard\n\n```\n# pfSense: VPN → WireGuard → Add Tunnel\n  Interface Keys: Generate (creates keypair automatically)\n  Listen Port: 51820\n  Interface Address: 10.8.0.1\u002F24\n\n# Add Peer (one per client):\n  Public Key: \u003Cclient public key>\n  Allowed IPs: 10.8.0.2\u002F32\n\n# Assign the WireGuard interface:\n  Interfaces → Assignments → Add (select wg0)\n  Enable interface, no IP needed (it is set in the tunnel config)\n\n# Firewall rules:\n  WAN → Allow UDP port 51820 inbound (so clients can reach the server)\n  WireGuard interface → Allow traffic to LAN networks you want reachable\n```\n\n## DDNS (Dynamic DNS) for Home Servers\n\nMost home internet connections have a dynamic IP. Use DDNS so your VPN endpoint\nstays reachable after an IP change.\n\n```bash\n# Option 1: Cloudflare DDNS — store credentials in a secrets file, not inline\n# docker-compose entry using an env file:\n  ddns-updater:\n    image: qmcgaw\u002Fddns-updater\n    env_file: .\u002Fddns.env   # store zone_id and token here, not in compose\n    restart: unless-stopped\n\n# ddns.env (chmod 600, not committed to git):\n#   SETTINGS_CLOUDFLARE_ZONE_ID=your_zone_id\n#   SETTINGS_CLOUDFLARE_TOKEN=your_api_token\n\n# Option 2: DuckDNS (free, simple)\n  Sign up at duckdns.org → get a token and subdomain (myhome.duckdns.org)\n  Store token in \u002Fetc\u002Fddns.env (mode 600), then use a small root-owned script:\n\n  # \u002Fusr\u002Flocal\u002Fbin\u002Fupdate-duckdns\n  #!\u002Fbin\u002Fsh\n  set -eu\n  . \u002Fetc\u002Fddns.env\n  curl --fail --silent --show-error --max-time 10 \\\n    --get \"https:\u002F\u002Fwww.duckdns.org\u002Fupdate\" \\\n    --data-urlencode \"domains=myhome\" \\\n    --data-urlencode \"token=${DUCKDNS_TOKEN}\" \\\n    --data-urlencode \"ip=\"\n\n  # Cron job:\n  *\u002F5 * * * * \u002Fusr\u002Flocal\u002Fbin\u002Fupdate-duckdns >\u002Fdev\u002Fnull 2>&1\n```\n\n## Troubleshooting\n\n```bash\n# Check WireGuard status and last handshake\nsudo wg show\n\n# If \"latest handshake\" is never or very old, the tunnel is not connected.\n# Check:\n# 1. Is UDP port 51820 open on the router\u002Ffirewall?\nsudo ufw status  # or check pfSense\u002FUniFi firewall rules\n\n# 2. Is the server public key in the client config correct?\nsudo wg show wg0 public-key   # Compare to what is in the client config\n\n# 3. Is IP forwarding enabled on the server?\ncat \u002Fproc\u002Fsys\u002Fnet\u002Fipv4\u002Fip_forward  # Should be 1\n\n# 4. Does the client AllowedIPs cover the IP you are trying to reach?\n# If AllowedIPs = 192.168.1.0\u002F24 and you are trying to reach 192.168.3.5, it will not route.\n\n# Check kernel logs for WireGuard errors\ndmesg | grep wireguard\n\n# Restart WireGuard\nsudo wg-quick down wg0 && sudo wg-quick up wg0\n```\n\n## Anti-Patterns\n\n```\n# BAD: Storing private keys in version control or sharing them\n# Private keys are equivalent to passwords — never commit them to git\n\n# BAD: Using AllowedIPs = 0.0.0.0\u002F0 on mobile without considering the impact\n# Full tunnel routes all mobile traffic through your home upload — usually slow\n\n# BAD: Not setting PersistentKeepalive on mobile clients\n# Mobile clients behind NAT drop idle tunnels without it\n\n# BAD: Opening port 51820 in the firewall but forgetting IP forwarding on the server\n# Tunnel connects but no traffic routes — confusing to debug\n\n# BAD: Sharing a keypair across multiple client devices\n# Each device must have its own unique keypair — shared keys break the security model\n\n# BAD: Using a broad \"FORWARD ACCEPT\" iptables rule\n# Scope forwarding rules to the wg0 interface and direction only\n```\n\n## Best Practices\n\n- Generate a unique keypair per client device — never reuse keys\n- Use split tunneling (`AllowedIPs = \u003Chome subnets>`) for mobile\n- Set `PersistentKeepalive = 25` on all mobile clients\n- Use DDNS if your ISP assigns a dynamic IP; store credentials in env files, not inline\n- Use scoped iptables forwarding rules (inbound on wg0 only) rather than a blanket FORWARD ACCEPT\n- Add Pi-hole's IP as `DNS =` in client configs to get ad blocking over the VPN\n- Rotate the server keypair periodically and update all client configs\n\n## Related Skills\n\n- homelab-network-setup\n- homelab-vlan-segmentation\n- homelab-pihole-dns\n",{"name":5,"origin":24,"description":7},"community","main","481dcd7dd2e288b9d627a2bd017db70e64e6c6fa","core\u002Fskills\u002Fhomelab-wireguard-vpn",2,"https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI","https:\u002F\u002Fyana.vutam.link\u002F","https:\u002F\u002Fgithub.com\u002FHoronomos-laps","https:\u002F\u002Fyana.vutam.link","An open-source governed runtime & execution environment for multi-agent AI systems.","2026-11-14 13:24:09",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add Horonomos-laps\u002FYana-AI --skill homelab-wireguard-vpn",{"tool":41,"command":42},"bunx","bunx skills add Horonomos-laps\u002FYana-AI --skill homelab-wireguard-vpn",{"tool":44,"command":45},"pnpm","pnpm dlx skills add Horonomos-laps\u002FYana-AI --skill homelab-wireguard-vpn","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fhomelab-wireguard-vpn\u002FSKILL.md",true,[],[50,58,65,73,81,89],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":54,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":19},"01M735GKET5YVYKAY62W2P5YXB","openai--sentry--sentry","Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data via the Sentry API; perform read-only queries with the bundled script and require `SENTRY_AUTH_TOKEN`.","MIT","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopenai--sentry--sentry\u002FSKILL.md",[],[],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M73DCAP83T17HY7SMGK7MGFE","ito-basket-compare","Compare Itô prediction-market baskets against a user's knowledge base, portfolio notes, financial context, watchlist, or research thesis. Use for read-only basket comparison and gap analysis without investment advice or live trading.","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fito-basket-compare\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":69,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":19},"01M734CYEMZFDR3KH6SW0JP8TD","implementing-network-traffic-baselining","Build network traffic baselines from NetFlow\u002FIPFIX data using Python pandas for statistical analysis, z-score anomaly detection, and hourly\u002Fdaily traffic pattern profiling","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-network-traffic-baselining\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-network-traffic-baselining\u002FSKILL.md",[],[],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":77,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M73ASZ6NJRJM44Z2P84NGQ3Q","detecting-evasion-techniques-in-endpoint-logs","Detects defense evasion techniques used by adversaries in endpoint logs including log tampering, timestomping, process injection, and security tool disabling. Use when investigating suspicious endpoint behavior, building detection rules for evasion tactics, or conducting threat hunting for stealthy adversary activity. Activates for requests involving evasion detection, defense evasion analysis, log tampering detection, or MITRE ATT&CK TA0005.","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fdetecting-evasion-techniques-in-endpoint-logs\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fdetecting-evasion-techniques-in-endpoint-logs\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":85,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M734AFNXD06Z78QRK0VKGT7Q","implementing-microsegmentation-with-guardicore","Implementing microsegmentation using Akamai Guardicore Segmentation to map application dependencies, create granular network policies, visualize east-west traffic flows, and enforce least-privilege communication between workloads across data centers and cloud.","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-microsegmentation-with-guardicore\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-microsegmentation-with-guardicore\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":19},"01M736TK27QMCXK0DVCH25SJN5","ramdisk-tmpfs-patterns","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Framdisk-tmpfs-patterns\u002FSKILL.md",[],[]]