-
Notifications
You must be signed in to change notification settings - Fork 0
Troubleshooting
docker logs ocserv-server # startup + ocserv messages
docker exec ocserv-server occtl show status # is ocserv online?
docker exec ocserv-server occtl show users # who's connected
docker exec ocserv-server nft list table inet ocserv # NAT rules present?The server-cert / server-key paths in ocserv.conf don't exist inside the container. Check the paths and that the volume (or /swag-config) is mounted. Validate first:
docker run --rm -v ./volumes/config:/etc/ocserv:ro \
--entrypoint /usr/sbin/ocserv azinchen/ocserv-server:latest \
-t -c /etc/ocserv/ocserv.confYou're using an unedited upstream sample config that points at ocserv's test certs. Use this image's maintained samples (which point at /etc/ocserv/...) and set your real cert paths.
Anything that isn't a note: line is a real error — fix the directive it names before restarting.
-
Port not reachable: confirm the host publishes the port and the firewall/router forwards it.
ss -lntp | grep <port>on the host should show docker-proxy listening. -
Camouflage secret missing: if
camouflage = true, a client URL without/?your-secretgets a401/404, not a VPN. See Camouflage Mode. -
Certificate untrusted: with a self-signed cert, pin it (
--servercert sha256:...) rather than ignoring verification. See Clients and Devices.
Authentication succeeded but traffic doesn't flow. Check, in order:
-
NAT rules present?
docker exec ocserv-server nft list table inet ocservshould show amasqueraderule for your subnet. -
Subnet mismatch?
VPN_SUBNET(container) must equalipv4-network/ipv4-netmask(ocserv.conf). A mismatch means client IPs are never masqueraded. See Networking NAT and Routing#keep-three-things-in-sync. -
Forwarding on? The host needs
--sysctl net.ipv4.ip_forward=1. Theinit-natlog will warn if it couldn't enable it. -
Container egress works?
docker exec ocserv-server ping -c2 1.1.1.1. If this fails, it's a host/Docker networking problem, not ocserv. - Router not routing through the tunnel? For Keenetic / Netcraze and similar, the tunnel can be up while the router still uses its ISP. Configure policy-based routing on the router. See Clients and Devices.
Classic IPv6 blackhole: clients were handed an IPv6 address + ::/0 route, but the server has no IPv6 egress. Either disable IPv6 in ocserv.conf (remove ipv6-network, route = ::/0, IPv6 dns) or enable it properly (IPV6_NAT=1 + Docker IPv6). See Networking NAT and Routing#ipv6.
Symptom: the client connects, then repeatedly drops/reconnects, often when DTLS (UDP) is enabled behind Docker's userland proxy. Fixes:
-
Go TCP-only: remove
udp-portfromocserv.confand drop the UDP port mapping. Simplest and stealthier for camouflage. - Or disable Docker's userland proxy / use host networking if you need DTLS performance.
Add tunnel-all-dns = true and push dns servers in ocserv.conf so clients can't bypass the tunnel's DNS. See ocserv Configuration#dns.
occtl per-session RX/TX only update on disconnect, so use the tunnel interface counters. Snapshot them, generate a few pings from the client (e.g. ping 10.20.0.1), then re-check:
docker exec ocserv-server sh -c \
'for s in rx_packets tx_packets rx_bytes tx_bytes; do \
printf "%-12s %s\n" $s $(cat /sys/class/net/vpns0/statistics/$s); done'If rx_packets climbs by the number of pings you sent, the data path is confirmed. Pinging the gateway 10.20.0.1 proves the tunnel; pinging 1.1.1.1 proves routing + NAT end-to-end.
Server→client pings often get no reply because many clients (routers especially) firewall ICMP to their own tunnel IP — that alone is not a sign of breakage. Trust the counters and client→server/client→internet tests.
ocserv reads config (and certificates) at startup. Restart the container after editing: docker restart ocserv-server.
Next: FAQ
ocserv-server · MIT License · Built on ocserv + s6-overlay