a lot has transpired in the last few hours. i tried to get my pivpn wireguard server to work in conjunction with my cloud servers and locally. what i mean, is to be able to access the vpn network from my lan network, but that was not feasible. so my next option was to test a local wireguard connection from a server. this was easy since the wireguard port was also exposed on the local ip address, so all i had to do was change the end point.

from there i needed to test connectivity between vpn clients, so i limited the allowed ips to the gateway and the client i needed. this is just done with the ip and a /32 subnet mask. after configuring the cloud server with wireguard and my server, they were able to talk to each other. the main point was to have ssh access to each other for rsync tasks for my minecraft backups.

i did not want to open port 22 or rather more ports than i need to from my public ip address. smartest option for me was to connect the two servers through a secure and fast vpn connection. i created an ansible automation playbook to deploy wireguard on the cloud server, and it worked flawlessly. it is posted in my ansible repo on github. i ensured connectivity and pinged my servers from my home network.

from there i deployed the wireguard configuration to my server, which was truenas scale. after some looking, truenas scale already comes with wireguard so all i had to do was paste in the wg0.conf file and start the interface. all the port forwarding rules were created automatically and the two servers were connected through the vpn. i limited the access between the two servers as i did not need to funnel all vpn and lan traffic to each other’s vpn interface. also creates better security as there is only traffic going in ‘one’ direction. this is great for split tunneling, where i have it setup on my cloud server.

if i had left the allowed list to quad zeros, it would have forwarded all the traffic to my home network. not ideal since i am still hosting services that are access through the server’s public ip address. once i figured out that the allow list changed the routing, i was set. pretty much ensure that the clients have at a minimum access to the gateway and the other server’s pivpn ip address.

once they can talk, you can create the proper settings and configurations in truenas to get rsync to work. in my case it was creating these items: user with ssh keys, ssh connection, ssh keypair, datastore, and setting permissions of the datastore to the same user as the cloud server.

take a look around truenas and you will find all of these options. also ensure to enable the ssh service as well. i have not gotten too far with rsync, but what i have done is setup the task to pull the working directory from the cloud server. i did run the task, but it failed since it timed out, i assume because i need to allow ssh access to this ip address. and right now in my oracle vcn, it is configured to my public ip address, so once i configure the right ip address, i will test the ssh connection locally, and then try the rsync task again.