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

[deluxetiky]

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

---

Summary

When configuring restrictions to allow reverse Unix socket tunnels using protocol: [Unix], the server still rejects connections with "not allowed destination" error, even though the protocol is explicitly specified as allowed.

Environment

• wstunnel version: v10.5.0
• Server OS: Docker (Ubuntu-based image)
• Client OS: Linux
• Deployment: Docker Compose with reverse proxy

Current Behavior

With the following restriction configuration, reverse Unix socket tunnels are rejected:

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

Server logs:

WARN: Rejecting connection with not allowed destination: RemoteAddr { 
  protocol: ReverseUnix { path: "/tmp/sockets/device-abc123.sock" }, 
  host: Ipv6(::), 
  port: 0 
}

Client command:

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

Expected Behavior

The reverse Unix socket tunnel should be accepted when protocol: [Unix] is explicitly specified in the restrictions.

Workaround

Removing the --restrict-config flag entirely allows the connection to work:

# Without restrictions - works fine
command: |
  wstunnel server \
    --tls-certificate /certs/server.crt \
    --tls-private-key /certs/server.key \
    --tls-client-ca-certs /certs/ca.crt \
    wss://0.0.0.0:4433

Server logs (working):

INFO: Tunnel accepted due to matched restriction: Allow All
INFO: Starting Unix socket server listening cnx on "/tmp/sockets/device-abc123.sock"

Attempted Solutions

1. Empty protocol array (to allow all):

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

Result: Still rejected

2. Explicit Unix protocol:

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

Result: Still rejected

3. Both Tunnel and ReverseTunnel:

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

Result: Still rejected

4. Path-based matching:

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

Result: Still rejected

Questions

1. Is Unix the correct enum value for Unix sockets in the protocol array?
2. Should Unix socket paths be validated differently in restrictions?
3. Is there a different restriction syntax required for reverse Unix socket tunnels?
4. Could this be related to the host: Ipv6(::) field in the rejection message?

Additional Context

Configuration structure:

services:
  wstunnel-server:
    image: ghcr.io/erebe/wstunnel:v10.5.0
    command: >
      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
    volumes:
      - ./certs:/certs:ro
      - ./sockets:/tmp/sockets:rw
      - ./config:/config:ro

Use case:
Managing multiple remote clients where each client needs to:

• Create reverse SSH tunnels through WebSocket
• Be restricted to creating sockets only with specific path patterns
• Use mTLS for mutual authentication
• Prevent unauthorized access to other client resources

Documentation Request

If this is the intended behavior, could the documentation be updated to clarify:

• Valid protocol enum values for the restrictions configuration
• How to properly configure restrictions for Unix socket tunnels
• Example configurations for reverse Unix socket use cases
• Whether Unix sockets require special handling in the restrictions system

It works great without restrictions, just trying to understand the proper configuration for access control.

[github-actions]

Hello @deluxetiky 👋

This issue is being automatically closed because it does not follow the issue template.