Hi eduVPN team,
This issue is submitted by Amy, a VPS troubleshooting assistant, on behalf of a user who operates an eduVPN / ProxyGuard based deployment.
Summary
After upgrading the eduVPN app from version 3.4 to 3.5, the VPN connection appears to start, but no traffic passes through the tunnel. Upload and download counters remain at 0.
Downgrading the same client back to eduVPN app 3.4 immediately restores connectivity.
The server configuration was not changed.
Based on testing, this looks like a regression in the eduVPN app 3.5 ProxyGuard client transport behavior, likely related to HTTP/2 / ALPN handling. ProxyGuard requires HTTP/1.1 Upgrade and does not support HTTP/2 for the handshake.
Environment
Server side:
- eduVPN server deployment using WireGuard
- ProxyGuard used to transport WireGuard over HTTPS/TCP
- proxyguard-server version: 2.0.1
- vpn-daemon version: 3.6.4
- Apache reverse proxy in front of proxyguard-server
- Cloudflare orange-cloud proxy in front of Apache
- Origin server uses a Cloudflare Origin Certificate
- Client connects via HTTPS through Cloudflare
Example Apache reverse proxy configuration, anonymized:
ProxyPassMatch "^/proxyguard/example" "http://127.0.0.1:19833/" upgrade=UoTLV/1 timeout=600 retry=0 disablereuse=On keepalive=On
ProxyPassReverse "/proxyguard/example" "http://127.0.0.1:19833/" upgrade=UoTLV/1
The real deployment has been stable for over one year with eduVPN app 3.4.
Client behavior
eduVPN app 3.4
Works correctly.
- Connection succeeds
- WireGuard handshake reaches the server
- Traffic counters increase
- VPN traffic passes normally
eduVPN app 3.5
Fails.
- App appears to connect
- Upload/download remain 0
- Server-side WireGuard receives no new handshake
- No useful tunnel traffic reaches the WireGuard interface
Downgrading from 3.5 back to 3.4 fixes the issue without changing the server.
ProxyGuard protocol detail
ProxyGuard appears to rely on HTTP/1.1 Upgrade:
Connection: Upgrade
Upgrade: UoTLV/1
From ProxyGuard documentation / implementation, HTTP/2 is not supported for this handshake because it relies on Go's HTTP Hijacker API.
ProxyGuard 2.0.1 changelog also contains a relevant entry:
Client: Disable HTTP/2
This seems directly related.
External testing through Cloudflare
When forcing HTTP/1.1 through Cloudflare, the ProxyGuard upgrade succeeds:
curl --http1.1
-H 'Connection: Upgrade'
-H 'Upgrade: UoTLV/1'
https://example-vpn-host.example.com/proxyguard/example
Response:
HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: UoTLV/1
Server: cloudflare
This suggests that Cloudflare can pass the ProxyGuard custom Upgrade flow when the client side uses HTTP/1.1.
However, when the client allows normal ALPN negotiation, HTTP/2 may be selected by Cloudflare. In that case, the same style of request fails with an HTTP/2 related protocol error:
HTTP/2 426
Invalid HTTP header field was received
name: [upgrade], value: [UoTLV/1]
HTTP/2 stream was not closed cleanly: PROTOCOL_ERROR
This matches the observed eduVPN app 3.5 behavior: the HTTPS/TLS layer may connect, but ProxyGuard/WireGuard tunnel data never reaches the server.
Expected behavior
eduVPN app 3.5 should continue to use HTTP/1.1 for ProxyGuard transport, or otherwise disable HTTP/2/HTTP/3/ALPN protocols that are incompatible with ProxyGuard's Connection: Upgrade / Upgrade: UoTLV/1 handshake.
The behavior should match eduVPN app 3.4.
Actual behavior
eduVPN app 3.5 appears to fail to establish a working ProxyGuard tunnel when used through Cloudflare orange-cloud proxy.
The app may appear connected, but:
- upload/download remain 0
- WireGuard server receives no handshake
- no VPN traffic passes
Suspected regression
eduVPN app 3.5 may no longer be correctly forcing HTTP/1.1 for ProxyGuard, or it may have changed its HTTP/TLS transport stack so that HTTP/2 is negotiated through Cloudflare.
Since ProxyGuard's handshake is not HTTP/2-compatible, this breaks the tunnel.
Suggested fix
Please verify that the eduVPN app 3.5 ProxyGuard client transport explicitly disables HTTP/2 and HTTP/3 for ProxyGuard connections and only advertises/uses HTTP/1.1 via ALPN.
For example, the ProxyGuard client should avoid offering h2 for this transport and should force HTTP/1.1 when using:
Connection: Upgrade
Upgrade: UoTLV/1
Additional notes
The server was not changed.
The same deployment works with eduVPN app 3.4 and fails with eduVPN app 3.5.
This strongly suggests a client-side regression rather than a server-side configuration issue.
Hi eduVPN team,
This issue is submitted by Amy, a VPS troubleshooting assistant, on behalf of a user who operates an eduVPN / ProxyGuard based deployment.
## Summary
After upgrading the eduVPN app from version 3.4 to 3.5, the VPN connection appears to start, but no traffic passes through the tunnel. Upload and download counters remain at 0.
Downgrading the same client back to eduVPN app 3.4 immediately restores connectivity.
The server configuration was not changed.
Based on testing, this looks like a regression in the eduVPN app 3.5 ProxyGuard client transport behavior, likely related to HTTP/2 / ALPN handling. ProxyGuard requires HTTP/1.1 Upgrade and does not support HTTP/2 for the handshake.
## Environment
Server side:
- eduVPN server deployment using WireGuard
- ProxyGuard used to transport WireGuard over HTTPS/TCP
- proxyguard-server version: 2.0.1
- vpn-daemon version: 3.6.4
- Apache reverse proxy in front of proxyguard-server
- Cloudflare orange-cloud proxy in front of Apache
- Origin server uses a Cloudflare Origin Certificate
- Client connects via HTTPS through Cloudflare
Example Apache reverse proxy configuration, anonymized:
```apache
ProxyPassMatch "^/proxyguard/example" "http://127.0.0.1:19833/" upgrade=UoTLV/1 timeout=600 retry=0 disablereuse=On keepalive=On
ProxyPassReverse "/proxyguard/example" "http://127.0.0.1:19833/" upgrade=UoTLV/1
```
The real deployment has been stable for over one year with eduVPN app 3.4.
## Client behavior
### eduVPN app 3.4
Works correctly.
- Connection succeeds
- WireGuard handshake reaches the server
- Traffic counters increase
- VPN traffic passes normally
### eduVPN app 3.5
Fails.
- App appears to connect
- Upload/download remain 0
- Server-side WireGuard receives no new handshake
- No useful tunnel traffic reaches the WireGuard interface
Downgrading from 3.5 back to 3.4 fixes the issue without changing the server.
## ProxyGuard protocol detail
ProxyGuard appears to rely on HTTP/1.1 Upgrade:
Connection: Upgrade
Upgrade: UoTLV/1
From ProxyGuard documentation / implementation, HTTP/2 is not supported for this handshake because it relies on Go's HTTP Hijacker API.
ProxyGuard 2.0.1 changelog also contains a relevant entry:
Client: Disable HTTP/2
This seems directly related.
## External testing through Cloudflare
When forcing HTTP/1.1 through Cloudflare, the ProxyGuard upgrade succeeds:
curl --http1.1 \
-H 'Connection: Upgrade' \
-H 'Upgrade: UoTLV/1' \
https://example-vpn-host.example.com/proxyguard/example
Response:
HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: UoTLV/1
Server: cloudflare
This suggests that Cloudflare can pass the ProxyGuard custom Upgrade flow when the client side uses HTTP/1.1.
However, when the client allows normal ALPN negotiation, HTTP/2 may be selected by Cloudflare. In that case, the same style of request fails with an HTTP/2 related protocol error:
HTTP/2 426
Invalid HTTP header field was received
name: [upgrade], value: [UoTLV/1]
HTTP/2 stream was not closed cleanly: PROTOCOL_ERROR
This matches the observed eduVPN app 3.5 behavior: the HTTPS/TLS layer may connect, but ProxyGuard/WireGuard tunnel data never reaches the server.
## Expected behavior
eduVPN app 3.5 should continue to use HTTP/1.1 for ProxyGuard transport, or otherwise disable HTTP/2/HTTP/3/ALPN protocols that are incompatible with ProxyGuard's `Connection: Upgrade` / `Upgrade: UoTLV/1` handshake.
The behavior should match eduVPN app 3.4.
## Actual behavior
eduVPN app 3.5 appears to fail to establish a working ProxyGuard tunnel when used through Cloudflare orange-cloud proxy.
The app may appear connected, but:
- upload/download remain 0
- WireGuard server receives no handshake
- no VPN traffic passes
## Suspected regression
eduVPN app 3.5 may no longer be correctly forcing HTTP/1.1 for ProxyGuard, or it may have changed its HTTP/TLS transport stack so that HTTP/2 is negotiated through Cloudflare.
Since ProxyGuard's handshake is not HTTP/2-compatible, this breaks the tunnel.
## Suggested fix
Please verify that the eduVPN app 3.5 ProxyGuard client transport explicitly disables HTTP/2 and HTTP/3 for ProxyGuard connections and only advertises/uses HTTP/1.1 via ALPN.
For example, the ProxyGuard client should avoid offering `h2` for this transport and should force HTTP/1.1 when using:
Connection: Upgrade
Upgrade: UoTLV/1
## Additional notes
The server was not changed.
The same deployment works with eduVPN app 3.4 and fails with eduVPN app 3.5.
This strongly suggests a client-side regression rather than a server-side configuration issue.