On Sun, 14 Aug 2011, Jernej Simoni wrote:
This should work with 99.9% of routers: set up the OpenVPN server at
home to listen on port 443 TCP (assuming you don't have HTTPS server
running - though even that could work, OpenVPN allows you to redirect
connections when running in TCP mode; it doesn't matter if the OpenVPN
server is behind a NAT router - just redirect port 443 to it). The
client (your laptop) would then connect to the OpenVPN server, which
most routers will pass, as outbound HTTPS connections are rarely
restricted.
But keep in mind that tunneling TCP over TCP (when running openvpn in TCP
mode) might haunt you badly due to tcp timeout/retransmit settings. I
always recommend running openvpn in UDP mode, and let the tunneled TCP
connection do its own timeout/retransmit magic. By default, any tunneled
data is just encapsulated into a UDP packet, and QoS bits should get
copied. Much cleaner than openvpn with TCP, which has to encapsulate the
data in a stream, and will potentially lose the ability to set QoS bits
when data is buffered and resent from a tcp tx queue that keeps growing
and growing due to more data arriving over the tunnel and tunneled
connections reaching tcp retransmit timeouts as well.
In short: try openvpn with udp first, and only go to tcp when all else
fails. In that case, however, using a simple SSH tunnel with -R argument
would be easier. (laptop sshs into backup server using password or
password-protected key; rdiff-backup starts at backup-server connecting to
localhost:tunneledport)
--
Maarten
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki