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(a)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
