Dante UDP Reply Rules Reverse the from/to Direction
Apply Dante's reply rules in the external-to-internal direction instead of copying the outgoing client's address assumptions.
The client is authenticated and UDP association is allowed. Replies still fail. In Dante, examine the direction of the rule handling the return traffic.
Dante separates initiating commands from reply handling:
| Rule commands | from | to |
|---|---|---|
connect, bind, udpassociate | Internal client | External destination |
bindreply, udpreply | External host | Internal client |
Copying a client's subnet restriction unchanged into both directions can therefore match the wrong side on the reply rule. Review the intended external senders and internal recipients, not merely whether the word UDP appears in a pass rule.
Authentication has a related boundary. The external service replying to a UDP datagram is not a SOCKS client that can complete your username/password exchange. Dante's documentation explains that reply operations result from a client's earlier BIND or UDP association; authenticate that initiating operation and apply the appropriate associated-reply policy.
This does not justify unrestricted unsolicited inbound traffic. The UDP association, destination policy, relay address, and firewall path still matter. Nor does enabling bindreply turn UDP association into a general-purpose public port-forwarding service.
Keep the client-side SOCKS exchange and the actual UDP return path visible separately. A successful TCP login verifies neither the reply ACL's address direction nor the reachability of the UDP relay endpoint.