Security

Wiredoor is designed with security in mind from the ground up. It leverages modern encryption, private networking, and fine-grained access control to help you safely expose services from otherwise unreachable environments like private networks, LANs, IoT systems, or Kubernetes clusters.

This guide outlines how Wiredoor keeps your services secure and what practices you should follow to maintain a robust security posture.

Core Security Architecture

✅ VPN-based reverse tunneling with WireGuard
✅ End-to-end encrypted traffic between the node and the Wiredoor server
✅ NAT traversal with no need to open inbound ports
✅ TLS/SSL termination using Let’s Encrypt or self-signed certs
✅ Access restriction via CIDR/IP filters
✅ No cloud vendor lock-in — fully self-hosted and auditable

Token-Based Authentication

Each node (including CLI clients and gateways) uses a unique access token that identifies it and scopes its permissions.

Best practices

Store tokens securely (e.g., config.ini, Kubernetes Secrets).
Never hardcode tokens into public repositories.
Rotate tokens regularly using the wiredoor regenerate command.
Revoke tokens immediately if a node is compromised or regenerate node config.

Certificate Management

Wiredoor handles SSL certificates in two modes:

Mode	Description
Let’s Encrypt	Used when exposing services on a valid public domain
Self-signed	Used for internal domains or IP-based access

Tips

Use valid DNS records (A or CNAME) pointing to your Wiredoor Server for public domains
For production-grade services, always prefer Let’s Encrypt over self-signed certs
Certificate renewal is handled automatically by Wiredoor

Access Control with IP Restrictions

When exposing a service, you can limit access by IP or CIDR block using the Web UI or CLI. It’s important to note that the IP or CIDR block must be public since Wiredoor is designed to expose services to the internet.


wiredoor http dashboard --domain grafana.example.com --port 3000 --allow 192.168.100.0/24 --block 192.168.100.5/32

In this example, only clients from the 192.168.100.0/24 except 192.168.100.5 IP range will be able to access the service. Make sure to use public IP ranges that are valid and accessible from outside your private network.

⚠️

Note: Restricting by private IPs or internal networks won’t work, as the service is exposed to the public internet.

Secure Node Types

Normal Nodes

Only expose services from the local machine
Ideal for standalone apps, dev servers, or small deployments

Gateway Nodes

Can expose services from an entire subnet
Must be scoped carefully with:
- Subnet definitions (e.g. 10.96.0.0/12)
- Network policies (if in Kubernetes)
- IP filtering

Kubernetes Gateway Security (Summary)

Wiredoor K8S Gateway (Helm chart) includes extra controls:

Built-in NetworkPolicy support to restrict egress access
Internal DNS resolution
Does not require privileged mode
Can be scoped to specific services via labels/namespaces

Example NetworkPolicy Helm config:

values.yaml


wiredoor:
  server: https://my-wiredoor.com
  token: your_gateway_token
 
networkPolicy:
  enabled: true
  egress:
    - podSelector:
        matchLabels:
          app.kubernetes.io/name: my-app
      namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: production

Things to avoid

Exposing services without authentication (e.g. admin panels)
Reusing node tokens across multiple machines
Running Wiredoor in public clouds without proper firewalling

Summary

Wiredoor gives you full control over service exposure without compromising on security. Combined with best practices and careful node management, it offers a strong, flexible, and private alternative to commercial ingress or tunneling platforms.