ReverseTunnel` restriction with `protocol: [Unix]` rejects Unix socket connections

[deluxetiky]

Describe the bug

When configuring restrictions to allow reverse Unix socket tunnels using protocol: [Unix], the server rejects connections with "not allowed destination" error, even though the protocol is explicitly specified in the restrictions configuration. The connection works perfectly when restrictions are disabled.

To Reproduce

Steps to reproduce the behavior:

1. Create a restrictions.yaml file:

restrictions:
  - name: "allow-reverse-unix"
    match:
      - !Any
    allow:
      - !ReverseTunnel
        protocol: [Unix]
        port: []
        cidr: []

2. Start wstunnel server with restrictions:

wstunnel server \
  --tls-certificate /certs/server.crt \
  --tls-private-key /certs/server.key \
  --tls-client-ca-certs /certs/ca.crt \
  --restrict-config /config/restrictions.yaml \
  wss://0.0.0.0:4433

3. Connect with client:

wstunnel client \
  --tls-certificate client.crt \
  --tls-private-key client.key \
  --tls-verify-certificate \
  -R unix:///tmp/sockets/device-abc123.sock:localhost:22 \
  wss://server.example.com:443

4. Observe connection being rejected

Expected behavior

The reverse Unix socket tunnel should be accepted when protocol: [Unix] is explicitly specified in the restrictions. The connection should succeed and create the Unix socket at the specified path.

Your wstunnel setup

Server logs (with --log-lvl=DEBUG):

2025-11-23T19:45:29.620360Z  INFO wstunnel::protocols::tls::server: Loading tls certificate from "/certs/server.crt"
2025-11-23T19:45:29.620440Z  INFO wstunnel::protocols::tls::server: Loading tls private key from "/certs/server.key"
2025-11-23T19:45:29.620469Z  INFO wstunnel::protocols::tls::server: Loading tls certificate from "/certs/ca.crt"
2025-11-23T19:45:29.620770Z  INFO wstunnel: Starting wstunnel server v10.5.0 with config WsServerConfig { socket_so_mark: SoMark { inner: None }, bind: 0.0.0.0:4433, websocket_ping_frequency: Some(30s), timeout_connect: 10s, websocket_mask_frame: false, restriction_config: Some("/config/restrictions.yaml"), tls: true, remote_server_idle_timeout: 180s, mTLS: true }
2025-11-23T19:45:29.620787Z  INFO wstunnel::tunnel::server::server: Starting wstunnel server listening on 0.0.0.0:4433
2025-11-23T19:45:42.875002Z  INFO cnx{peer="172.18.0.2:47008"}: wstunnel::tunnel::server::server: Accepting connection
2025-11-23T19:45:42.875082Z  INFO cnx{peer="172.18.0.2:47008"}: wstunnel::tunnel::server::server: Doing TLS handshake
2025-11-23T19:45:43.100516Z  WARN cnx{peer="172.18.0.2:47008"}:tunnel{id="019ab240-70a1-7c31-a11d-a7e889210c68" remote="[::]:0"}: wstunnel::tunnel::server::server: Rejecting connection with not allowed destination: RemoteAddr { protocol: ReverseUnix { path: "/tmp/sockets/device-abc123.sock" }, host: Ipv6(::), port: 0 }

Server command line:

wstunnel server \
  --tls-certificate /certs/server.crt \
  --tls-private-key /certs/server.key \
  --tls-client-ca-certs /certs/ca.crt \
  --restrict-config /config/restrictions.yaml \
  wss://0.0.0.0:4433

Client logs:

2025-11-23T19:46:02.546292Z  INFO wstunnel::protocols::tcp::server: Opening TCP connection to server.example.com:443
2025-11-23T19:46:02.615485Z  INFO wstunnel::protocols::tls::server: Doing TLS handshake using SNI DnsName("server.example.com") with the server server.example.com:443
2025-11-23T19:46:02.776110Z ERROR tunnel{id="019ab240-7eb2-73d0-afd9-f0b2e077be4c" remote="[::]:0"}: wstunnel::tunnel::client::client: Retrying in 4s, cannot connect to remote server: failed to do websocket handshake with the server wss://server.example.com:443

Caused by:
    Invalid status code: 400

Client command line:

wstunnel client \
  --tls-certificate /etc/wstunnel/client.crt \
  --tls-private-key /etc/wstunnel/client.key \
  --tls-verify-certificate \
  --websocket-ping-frequency 90s \
  --dns-resolver-prefer-ipv4 \
  --connection-retry-max-backoff 10m \
  --reverse-tunnel-connection-retry-max-backoff 2m \
  -R unix:///tmp/sockets/device-abc123.sock:127.0.0.1:22 \
  wss://server.example.com:443

Working configuration (without restrictions):

When --restrict-config is removed, the connection succeeds:

2025-11-23T19:51:58.733734Z  INFO cnx{peer="172.18.0.2:59426"}:tunnel{id="019ab246-2bf0-73e0-85b8-9114727cede1" remote="[::]:0"}: wstunnel::tunnel::server::server: Tunnel accepted due to matched restriction: Allow All
2025-11-23T19:51:58.733769Z  INFO cnx{peer="172.18.0.2:59426"}:tunnel{id="019ab246-2bf0-73e0-85b8-9114727cede1" remote="[::]:0"}: wstunnel::protocols::unix_sock::server: Starting Unix socket server listening cnx on "/tmp/sockets/device-abc123.sock"

Desktop (please complete the following information):

• Server OS: Linux (Docker, ghcr.io/erebe/wstunnel:v10.5.0 image)
• Client OS: Linux (kernel 5.x)
• Version: wstunnel v10.5.0

Additional context

Other restriction configurations attempted (all rejected):

1. Empty protocol array:

allow:
  - !ReverseTunnel
    protocol: []
    port: []
    cidr: []

2. Both Tunnel and ReverseTunnel:

allow:
  - !ReverseTunnel
    protocol: [Unix]
    port: []
    cidr: []
  - !Tunnel
    protocol: [Unix]
    port: []
    cidr: []

3. Path-based matching:

restrictions:
  - name: "device-specific"
    match:
      - !PathPrefix "^/device-abc123/"
    allow:
      - !ReverseTunnel
        protocol: [Unix]
        port: []
        cidr: []

All configurations result in the same rejection error. The connection only works when restrictions are completely disabled.

Questions:

• Is Unix the correct protocol enum value for Unix sockets?
• Do Unix sockets require special handling in the restrictions system?
• Should the host: Ipv6(::) field be considered in the restriction matching?

It works perfectly without restrictions, just trying to understand the proper syntax for Unix socket access control.

[erebe]

Thank you for reporting,

I will try to take a look at it in the incomings days

[erebe]

Going to make a fix, but if you want to be unstuck, you just need to remove the cidr block.
And it should work

restrictions:
  - name: "allow-reverse-unix"
    match:
      - !Any
    allow:
      - !ReverseTunnel
        protocol: [Unix]

or include the cidr but set wildcard allowed network

restrictions:
  - name: "allow-reverse-unix"
    match:
      - !Any
    allow:
      - !ReverseTunnel
        protocol: [Unix]
        cidr: ["0.0.0.0/0", "::/0"]

[erebe]

Should be fixed in this release https://github.com/erebe/wstunnel/releases/tag/v10.5.1

You have also now a config to restrict the path
https://github.com/erebe/wstunnel/blob/main/restrictions.yaml#L127

[deluxetiky]

Thank you for the fix. I will check and confirm soon!