Troubleshooting
If you’re running into issues with Wiredoor, here are some common problems and how to solve them.
Wiredoor CLI says “unauthorized” or “invalid token”
- Ensure you’re using a valid token for a node created in the Web UI
- If you’re using
wiredoor login
, verify the admin credentials - Rotate the token using
wiredoor regenerate
if needed
I exposed a service but it’s not reachable
Check:
- The VPN connection is active (
wiredoor status
) - The port is correct and the service is listening on the node
- The domain points to your Wiredoor server
- The node is connected in the Wiredoor UI
- No NetworkPolicy is blocking access (for Kubernetes Gateway)
I can’t connect to my Wiredoor Server
- Ensure ports 80, 443, and VPN_PORT (UDP) are open
- Use
curl
orping
to check connectivity to the server domain/IP - Verify Docker is running and the container is healthy
DNS doesn’t resolve service names in Kubernetes
- Confirm you’re using a fully qualified name like
my-service.default.svc.cluster.local
- Make sure the service is running and exposed in the correct namespace
Let’s Encrypt certificate isn’t generated
- The domain must resolve publicly to your Wiredoor Server IP
- Port 80 must be open for HTTP validation
Services show SSL warnings
- You’re likely using a self-signed certificate (internal domain)
- To avoid warnings, use a public domain and allow Wiredoor to handle Let’s Encrypt
The Wiredoor Gateway Pod can’t access my service
- Make sure it runs in a namespace with access
- Use Helm’s
networkPolicy.egress
to allow the right Pod/Namespace - Ensure the service is on the same subnet defined in the gateway node
How can I view logs?
For server logs:
docker logs wiredoor
If you’re still having trouble, open an issue on GitHub or join the community for help!
Gateway node cannot reach internal network IPs
If you’re using a Wiredoor Gateway node and it cannot reach IPs in the target internal network, make sure to check the following:
- IP forwarding is enabled:
sysctl -w net.ipv4.ip_forward=1
- **SELinux (on RedHat-based systems): ** Ensure that SELinux is not blocking forwarding or masquerading. You may need to adjust policies or set SELinux to permissive mode for testing:
setenforce 0
- Firewall Masquerading is enabled (firewalld):
firewall-cmd --permanent --add-masquerade
firewall-cmd --reload
Last updated on