UDP relay fails with "Operation not permitted (os error 1)" when sending response back to client

UDP relay fails with "Operation not permitted (os error 1)" when sending response back to client

Describe the Bug

TCP works normally, but UDP relay does not.

The server successfully receives UDP packets from clients and also receives responses from upstream servers (for example DNS responses from 1.0.0.1:53), but fails when sending the UDP response back to the client.

The log repeatedly shows:

WARN udp failed to send back 43 bytes to client [::ffff:122.96.37.88]:40906, from target 1.0.0.1:53, error: Operation not permitted (os error 1)

From the log, it appears that:

1. Client → Server UDP traffic succeeds.
2. Server → Upstream UDP traffic succeeds.
3. Upstream → Server UDP response succeeds.
4. Server → Client UDP response fails with EPERM.

TCP traffic works normally.

Steps to reproduce

1. Start ssserver with UDP enabled.
2. Connect using a Shadowsocks client with UDP enabled.
3. Send DNS queries or any UDP traffic through the proxy.
4. Observe server logs.

Expected behavior

UDP relay should work normally.

The server should forward UDP responses back to the client instead of reporting:

Operation not permitted (os error 1)

Actual behavior

The server receives upstream responses successfully but fails to send them back to the client.

Logs

INFO shadowsocks server 1.24.0

INFO shadowsocks tcp server listening on [::]:9999
INFO shadowsocks udp server listening on [::]:9999

WARN udp failed to send back 43 bytes to client [::ffff:122.96.37.88]:40906, from target 1.0.0.1:53, error: Operation not permitted (os error 1)

WARN udp failed to send back 43 bytes to client [::ffff:122.96.37.88]:13104, from target 1.0.0.1:53, error: Operation not permitted (os error 1)

WARN udp failed to send back 43 bytes to client [::ffff:122.96.37.88]:13105, from target 1.0.0.1:53, error: Operation not permitted (os error 1)

Environment

• shadowsocks-rust 1.24.0
• Linux 6.6.110
• OpenWrt / ImmortalWrt 24.10.4
• Server mode: TCP + UDP
• Cipher: chacha20-ietf-poly1305

Configuration:

{
  "server": "::",
  "server_port": 9999,
  "mode": "tcp_and_udp",
  "method": "chacha20-ietf-poly1305"
}

Also tested with:

{
  "server": "0.0.0.0"
}

but the issue remains.

Additional Information

Verified:

• TCP works correctly.
• UDP requests reach the server.
• Upstream DNS responses are received successfully.
• The process has full capabilities (CAP_NET_ADMIN present).
• Changing listen address from :: to 0.0.0.0 does not help.
• Restarting the service does not help.

The issue seems to happen only when ssserver attempts to send the UDP response back to the client.

Is this a known issue with UDP relay on Linux/OpenWrt, or could additional debugging information help identify the cause?

No source file or test is named. Start by reproducing the UDP relay failure with the provided ssserver configuration on Linux/OpenWrt, then trace the relay path from the upstream response to the client send and inspect the IPv4-mapped client address; done means UDP responses reach the client without EPERM and the behavior is covered by a regression test.