Encrypting data transferred from Publisher to Subscriber in Unidata Replication

I have been looking for ways to encrypt data sent from a publisher to a subscriber. That data is sent to unirpcd on the subscriber and I have confirmed that, at present, it is sent as plain text.

We have a lead interested in replication but want to ensure that the data transferred between the publisher and subscriber is encrypted (they're Unidata on AIX). I noted the existence of the "-s" option for unirpcd, but when I force unirpcd to start on pub and sub with this option, replication does not operate. I've been told that there is no "official" way to encrypt the replication data travelling between pub and sub(s), but that using a ssh tunnel may be an option.

I'm pretty decent at setting up tunnels - I do it all the time, but I have yet to work out how to get replication to go through a tunnel. Any suggestions? Or does anyone have any other suggestions about getting the data from the publisher to the subscriber to be encrypted (preferably without having to do file encryption for ever replicated file on the system!)?

I have been looking for ways to encrypt data sent from a publisher to a subscriber. That data is sent to unirpcd on the subscriber and I have confirmed that, at present, it is sent as plain text.

We have a lead interested in replication but want to ensure that the data transferred between the publisher and subscriber is encrypted (they're Unidata on AIX). I noted the existence of the "-s" option for unirpcd, but when I force unirpcd to start on pub and sub with this option, replication does not operate. I've been told that there is no "official" way to encrypt the replication data travelling between pub and sub(s), but that using a ssh tunnel may be an option.

I'm pretty decent at setting up tunnels - I do it all the time, but I have yet to work out how to get replication to go through a tunnel. Any suggestions? Or does anyone have any other suggestions about getting the data from the publisher to the subscriber to be encrypted (preferably without having to do file encryption for ever replicated file on the system!)?

I have been looking for ways to encrypt data sent from a publisher to a subscriber. That data is sent to unirpcd on the subscriber and I have confirmed that, at present, it is sent as plain text.

We have a lead interested in replication but want to ensure that the data transferred between the publisher and subscriber is encrypted (they're Unidata on AIX). I noted the existence of the "-s" option for unirpcd, but when I force unirpcd to start on pub and sub with this option, replication does not operate. I've been told that there is no "official" way to encrypt the replication data travelling between pub and sub(s), but that using a ssh tunnel may be an option.

I'm pretty decent at setting up tunnels - I do it all the time, but I have yet to work out how to get replication to go through a tunnel. Any suggestions? Or does anyone have any other suggestions about getting the data from the publisher to the subscriber to be encrypted (preferably without having to do file encryption for ever replicated file on the system!)?

Thanks for the suggestions/comments. I have worked it out and will offer a brief outline of the method.

And yes, file encryption is certainly a means to achieve this, but on a 24×7 system with lots of files it means spending some time encrypting all - or at least most - of the files. If it is possible to encrypt all the traffic in one go then that would seem to be a simpler solution. I'd very much encourage Rocket into looking at making this possible.

Peter, I did try the "-s" option. Unfortunately that prevents replication from working at all, so it didn't lead anywhere.

The fundamental step in getting this going is to set up a firewall rule (using iptables on Linux or ipsec on AIX) that intercepts outgoing traffic on port 31438 and redirects it to the localhost on a different port, a port where one end of the tunnel is waiting. To check it worked I added a firewall rule on the subscriber to block incoming traffic from the publisher on port 31438 and ran tcpdump to monitor the content of the traffic between the publisher and subscriber (something I did previously to prove that the content was not encrypted by default).