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 -- Brian Hatch The sum of intelligence on Systems and the planet is a constant. Security Engineer The population is growing. http://www.ifokr.org/bri/ Do the math. Every message PGP signed