OpenVPN + Rsync
I am putting a backup file server in a remote location to backup my primary file server with Rsync. I am doing this with OpenVPN. Both file servers are FreeNAS boxes. I have my pfSense box configured as the OpenVPN server and the remote FreeNAS box configured as the OpenVPN client. Everything is on my local LAN at the moment before I move the remote box to it's permanent location. I am using a dynamic DNS service on the pfSense box for when my IP changes.
The pfSense OpenVPN server is set up for UDP and TUN with SSL/TLS. I have the remote box configured and it seems to be connecting sucessfully and the TUN interface has an IP of 10.0.8.6 (it also has a LAN IP). I am able to ping the 10.0.8.6 address from my LAN machines but the Rsync tasks keep failing. In my firewall logs I see that the traffic is being blocked. I thought the LAN net could connect to anywhere. Is there a reason this is happening (I assume a configuration issue). My OPT1 interface is IPv4 configuration is set to none.
Please let me know if you need more information about my configuration and I will post it. I can't think of what else might be useful at this point.
Perhaps this will be an asymmetric route problem, because the NAS box is sitting inside your LAN for testing. When a LAN client connects to the NAS at 10.0.8.6 that traffic goes to pfSense and through the VPN tunnel to the NAS. But the NAS also has an IP on the LAN, so the reply packet is delivered back directly to the LAN client. After a while, there will be no reply packets flowing back through pfSense and I guess it deletes the state/flow. Subsequent packets to the NAS are then dropped by pfSense.
If you can test it from outside it might just work.
Note: ping (ICMP) does not have the same "state" needs over time, so ping worked.
Okay, that is a good thought. I have tested with SSH though and I am able to SSH into the box via 10.0.8.6 from anywhere on the LAN. Would SSH have the same requirements as Rsync in this regard?
Hmmm - SSH runs over TCP, which is state-full, so I would have expected it to have problems after some seconds also.
It appears you are right. I am able to SSH into the box via 10.0.8.6 but after a moment the connection gets closed. Is there a way I can test this without moving the box to its final location? I'm just concerned that it will get there and something won't work and I would have to open an SSH port to the box to adjust the configurations. Opening ports to a file server isn't really my idea of a good time.
An added question: Does this configuration have any issues? I selected it because I wouldn't have to open ports for Rsync + SSH on the remote end. The only port I have to open is on the pfSense box for OpenVPN connections where I can watch what people are doing. The remote end just has a crappy ISP supplied box that I trust a lot less than pfSense.
If you can make a separate OPTn local subnet then you can put the NAS in that (and even use the actual subnet that the NAS will finally sit in at the remote end). That way the NAS should first see the route back to your LAN advertised through the tunnel and use that, rather than going locally straight to pfSense on OPTn.
You are going to have to change the NAS IP anyway when you send it, so this way you can change it and test that also.
When finished testing, cleanup your OPTn or you might run into some other confusion when the NAS really does connect from the remote site.
An added question: Does this configuration have any issues?
You are effectively putting the remote NAS as a device on your (logical) private internal network. It is just the same as having it in a different real subnet on an interface on your local pfSense. You can use firewall rules to restrict which local LAN IPs can even reach the remote NAS IP.
Of course, at the remote location the NAS is going to have a local IP there, which it uses to establish the OpenVPN tunnel back to you. I guess you can restrict local access to the FreeNAS box however you like from FreeNAS. But someone is going to have physical hardware/console access at the remote site and so you have all those things that require the remote site also be physically secure.