Hello everyone,
Thank you for reading. I wanted to provide a detailed update on my troubleshooting, as the problem has become more specific and perplexing.
Following the advice in some community guides (like the one for using WireGuard as a service qube), I abandoned the dokodemo-door
+ nftables
approach. Instead, I tried a method that seems more robust and better integrated: using sing-box
with a tun
interface to create a transparent gateway.
Here is a summary of the steps I took and the results:
1. The New Setup:
- I used a clean StandaloneVM (
sys-proxy
) based on the Debian 12 template.
- I downloaded the
sing-box
binary (v1.9.1) and placed it in the VM.
- I configured
sys-proxy
’s Net Qube to point directly to sys-net
to avoid any potential conflicts with an intermediary sys-firewall
, as recommended by the Qubes documentation for network service qubes.
- The
Provides network
flag is enabled for sys-proxy
.
2. The sing-box
Configuration: My sing-box-config.json
is set up to create a tun
interface and route all traffic through it to my VLESS/REALITY server. This is the exact configuration:
json
{
"log": { "level": "info", "timestamp": true },
"dns": {
"servers": [{ "tag": "dns-over-proxy", "address": "https://8.8.8.8/dns-query", "detour": "proxy" }],
"final": "dns-over-proxy",
"strategy": "ipv4_only"
},
"inbounds": [{
"type": "tun", "tag": "tun-in", "interface_name": "tun0", "inet4_address": "172.19.0.1/30",
"auto_route": true, "strict_route": true, "stack": "system", "sniff": true
}],
"outbounds": [
{
"type": "vless", "tag": "proxy", "server": "YOUR_SERVER_IP", "server_port": 443,
"uuid": "YOUR_UUID", "flow": "xtls-rprx-vision",
"tls": {
"enabled": true, "server_name": "www.microsoft.com",
"utls": { "enabled": true, "fingerprint": "chrome" },
"reality": { "enabled": true, "public_key": "YOUR_PUBLIC_KEY", "short_id": "YOUR_SHORT_ID" }
}
},
{ "type": "dns", "tag": "dns-out" }
],
"route": {
"rules": [{ "protocol": "dns", "outbound": "dns-out" }],
"final": "proxy"
}
}
3. The Result and The Paradox: When I start sing-box
with sudo
, an interface tun0
is created successfully. However, when I try to access the internet from sys-proxy
itself, I get a DNS resolution error: curl: (6) Could not resolve host: ipinfo.io
The sing-box
logs show the underlying problem very clearly: ERROR dns: exchange failed for ipinfo.io. IN A: dial tcp YOUR_SERVER_IP:443: i/o timeout
This log indicates that sing-box
is correctly trying to establish a VLESS connection to my server to resolve the DNS query, but the connection is timing out.
Here is the part that is completely confusing me: To rule out any network blocks, I stopped sing-box
and ran a simple connectivity test from within the same sys-proxy
VM: nc -vz YOUR_SERVER_IP 443
The result was an immediate success: Connection to YOUR_SERVER_IP 443 port [tcp/https] succeeded!
4. Conclusion and Question: This proves that my sys-proxy
VM has a clear, unblocked network path to my VPS on the required port. A simple TCP connection works perfectly. However, the moment sing-box
tries to establish its VLESS (TLS-based) connection to the exact same destination, it fails with a timeout.
My latest hypothesis is that the problem is not within Qubes OS, but on the server-side (e.g., a VPS firewall that drops complex TLS ClientHello packets but allows simple SYN packets). Unfortunately, I’ve been unable to verify this as I’ve run into SSH key issues (Permission denied (publickey)
) trying to access the VPS to check its firewall.
Has anyone encountered a situation like this? Where a simple tool like netcat
can connect, but a more complex Go application like sing-box
or xray
cannot? Could this still be a subtle Qubes-specific issue I am missing, or does this strongly point to a server-side firewall configuration?
Any insights would be greatly appreciated.