Problem description
In restrictive networks (e.g. public Wi-Fi in waiting rooms, hotels, or guest networks), it is common for certain ports or protocols (especially UDP) to be blocked. This can prevent Defguard from establishing a functional tunnel.
For example, when attempting to connect via Defguard in such an environment, the tunnel may technically establish but remain unusable due to blocked or filtered traffic.
Problem:
Defguard currently does not provide a built-in mechanism to handle networks where VPN traffic (e.g. UDP) is restricted or blocked.
Proposed solution
- Support fallback to TCP-based transport
- Optional encapsulation (e.g. UDP over TCP or HTTPS-like transport)
- Configurable port fallback (e.g. switching to commonly open ports like 443)
- Traffic obfuscation to avoid simple protocol-based blocking
Alternatives considered
Locally configuring a tool like socat to wrap UDP traffic into a different transport, allowing packets to bypass restrictions and be unpacked again at the destination.
Impact
Important
Problem description
In restrictive networks (e.g. public Wi-Fi in waiting rooms, hotels, or guest networks), it is common for certain ports or protocols (especially UDP) to be blocked. This can prevent Defguard from establishing a functional tunnel.
For example, when attempting to connect via Defguard in such an environment, the tunnel may technically establish but remain unusable due to blocked or filtered traffic.
Problem:
Defguard currently does not provide a built-in mechanism to handle networks where VPN traffic (e.g. UDP) is restricted or blocked.
Proposed solution
Alternatives considered
Locally configuring a tool like socat to wrap UDP traffic into a different transport, allowing packets to bypass restrictions and be unpacked again at the destination.
Impact
Important