Thank you Jochen and apologies for the delayed reply; I was out of the office for long time. When I received your reply, I immediately tried to follow your advice regarding socat. Unfortunately, however, it didn't work for me... At first, I thought the issue might be Windows-related, so I installed Cygwin, but that didn't help either. The problem most likely lay in the client-server communication and back within SPSS. Perhaps installing socat on both ends would have made it work. However, the instructions were not to install anything on the client side-ONLY on the server. I could modify the SPSS license software on the server (the communication part), but I couldn't make *any* changes on the client side...!!! ---- So, I settled on using a reverse proxy to handle the packet "translation" (I used a token for server authentication to get around the UDP issue, while keeping the client-side setup completely "dumb" - just using a DNS record to route traffic through the reverse proxy). It was a bit of a hack, but it worked... I would have preferred a more in-house solution, but I didn't have the time and needed to move forward. ---- Thanks again for your reply with socat proposal. It will definitely come in handy for another application that doesn't have the same software-imposed limitations. BR John NSS -----Original Message----- From: Jochen Bern via stunnel-users [mailto:stunnel-users@lists.stunnel.org] Sent: Κυριακή, 19 Απριλίου 2026 22:51 To: stunnel-users@lists.stunnel.org Subject: [stunnel-users] Re: client UDP 5093 -> TCP 5555 and vice versa in Server (TCP 5555 -> UDP 5093) Am 19.04.26 um 02:46 schrieb admin--- via stunnel-users:

So the question is of it is possible with stunnel to convert / wrap e.g. by users the UDP port 5093, to "convert" it to TCP e.g. 5555

stunnel does only TCP. socat *may* be able to do that conversion (it knows both UDP and TCP and the manpage doesn't seem to specifically rule the combo out, but I didn't try it), but I would expect the resulting packets to have subtle changes that the software might balk at. A *license* service *should* try to reject manipulated/simulated peers, after all. NATing UDP traffic to a different UDP port that the firewall lets pass would IMHO be preferable, followed by proper tunneling (which includes variants that are "not quite a VPN yet"). Kind regards, -- Jochen Bern Systemingenieur Binect GmbH