Pre-stunnel: Server 1 Sends syslog messages to UDP port 514 on Server 2.
Server1 and Server2 both then install stunnel: Server1: Syslog messages are redirected to localhost UDP port 514 (rather than Server2 UDP port 514). Server1: Stunnel listens on UDP port 514, and sends encrypted data to Server2 on TCP port 12345 Server2: Stunnel listens on TCP port 12345, decrypts the data, and sends to localhost UDP port 514.
This way, stunnel acts as the UDP to TCP (encrypted) to UDP gateway - in a similar way that it can currently act as a pure TCP -> TCP (encrypted) -> TCP gateway.
Could it be done? Sure. But it'd be a lot of coding.
If I send a UDP packet of 102 bytes, then stunnel needs to have some way to talk to stunnel on the other end and say "this is one 102 byte UDP packet". So you've got some "udp packet size" protocol to encode both Stunnel processes.
If you didn't, here's what would happen. You'd send two UDP packets, size 50 and size 52 bytes. It wouldn't know what to do with the data - was it one 102 byte packet? Was it a 100 byte packet and a 2 byte packet? How can you tell?
You'd need to have some new mechanism like this:
debug=7 cert=/path/to/stunnel.pem
client = yes
[syslog-ish] accept_udp = localhost:514 connect = remotehost:12345
and on the Stunnel server
debug=7 cert=/path/to/stunnel.pem
client = no
[syslog-ish] accept = 12345 connect_udp = remotehost:12345
The accept_udp and connect_udp settings would trigger Stunnel to do 'UDP packet byte counting' inside the SSL session so it could recreate the packets on the remote end correctly.
Yes, it could be possible. But today it's not. If you wanted to write the code, by all means do so. ;-)
right now