PROXMOX Backup - By VPN

[rec.br9]

Hello all.

I have an PROXMOX SERVER in a country A.

But the PROXMOX BACKUP is in a country B.

If I ping from country A to B i have this result:
PING countrB (192.168.X.X) 56(84) bytes of data.
64 bytes from countryB (192.168.X.X): icmp_seq=1 ttl=62 time=39.9 ms
64 bytes from countryB (192.168.X.X): icmp_seq=2 ttl=62 time=40.2 ms
64 bytes from countryB (192.168.X.X): icmp_seq=3 ttl=62 time=39.5 ms
64 bytes from countryB (192.168.X.X): icmp_seq=4 ttl=62 time=43.0 ms

The ping works, the VPN are configured correctly.

But when I tryed to add the PROXMOX BACKUP SERVER in my DATACENTER I have this error bellow.


Any idea?

Best regards

 

[Curt Hall]

Not an idea to help you exactly, but more of a be aware; I have a remote office that has a 4ms ping and I can't maintain a cluster. I had to create a remote cluster and watch all clusters with the new Datacenter manager from Proxmox. So connecting over your connection would be something I wouldn't even try, at least Proxmox-to-Proxmox. use a dedicated third party back up solution like Veeam if possible, yes I know its more money, but its all i can say unless someone else chimes in here and tells both of us how to maintain these shaky connections over WAN (backups, clusters, etc.).

 

[Onslow]

Have you verified that this connection is let through?
E.g. what does telnet 192.168.X.X 8007 return?

 

[rec.br9]

Você verificou se esta conexão está permitida?
Por exemplo, o que telnet 192.168.X.X 8007retorna?

telnet: Unable to connect to remote host: Connection timed out


Country A - PROXMOX SERVER: 172.22.X.X

Country B - PROXMOX BACKUP: 192.168.X.X


root@PROXMOXSERVER:~# ping 192.168.X.X
PING 192.168.X.X (192.168.250.208) 56(84) bytes of data.
64 bytes from 192.168.X.X: icmp_seq=1 ttl=62 time=40.3 ms
64 bytes from 192.168.X.X: icmp_seq=2 ttl=62 time=39.9 ms
64 bytes from 192.168.X.X: icmp_seq=3 ttl=62 time=40.5 ms
64 bytes from 192.168.X.X: icmp_seq=4 ttl=62 time=40.5 ms
64 bytes from 192.168.X.X: icmp_seq=5 ttl=62 time=41.4 ms
64 bytes from 192.168.X.X: icmp_seq=6 ttl=62 time=39.7 ms
^C
--- 192.168.X.X ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 39.658/40.366/41.417/0.560 ms
root@PROXMOXSERVER:~# telnet 192.168.X.X 8007
Trying 192.168.X.X...
telnet: Unable to connect to remote host: Connection timed out


Regards

 

[Johannes S]

Not an idea to help you exactly, but more of a be aware; I have a remote office that has a 4ms ping and I can't maintain a cluster. I had to create a remote cluster and watch all clusters with the new Datacenter manager from Proxmox. So connecting over your connection would be something I wouldn't even try, at least Proxmox-to-Proxmox. use a dedicated third party back up solution like Veeam if possible, yes I know its more money, but its all i can say unless someone else chimes in here and tells both of us how to maintain these shaky connections over WAN (backups, clusters, etc.).

The latency needs of a cluster have nothing to do with the connection from a ProxmoxVE Server to a ProxmoxBackupServer.
Why should a connection to a veeam Server be different than to a PBS?
The only requirement for it to work are a network connection, an allowed connection to Port 8007 on the PBS and a correctly configured https certificate.
For veeam you would also need to configure the network and Firewall.

Now I also think that OPs setup isn't optimal but more for a restore or ransomware scenario:
- Restore from a local PBS is way faster than from a remote
- A local attacker could also try to attack the remote PBS if the connection to it's port 8007 is allowed and open.

For this reason I would recommend setting up a local PBS and creating a pull-sync job on the remote PBS without opening the remote PBS port: The remite pbs can then pull the backups as offsitebackup while nobody on the local site can access it ( for restore you would allow access temporary):
https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery


Back to the OPs question: My bet is also an an issue with the network setup: How is the vpn configured? Which IP subnets are used? Is accessing Port 8007 on the PBS from the PVE allowed?

 

[Onslow]

Seems like some firewall is blocking the connections to port 8007.
This must be fixed first .

Edit: Johannes S' remarks to let and use the connection in the opposite direction are correct.

 

[Johannes S]

39.658/40.366/41.417/0.560 ms
root@PROXMOXSERVER:~# telnet 192.168.X.X 8007
Trying 192.168.X.X...
telnet: Unable to connect to remote host: Connection timed out

This looks like you didn't allow a connection in the firewall on one of both sides to the PBS. Another culprit might be a failure in your vpn setup. Are you sure 192.168.x.x is vpn and not some local network? Which kind of vpn do you use and how it's configured?

 

[IsThisThingOn]

Just a heads up, not sure if this applies to you too.
Today I setup a remote PBS and forgot to open up the new IPv6 WAN rule on the remote firewall.
Instead of a "could not connect to remote" or something like that error, I got a "permission denied" error.
So what I am trying to say is, don't trust these error messages.

Now to your setup, I think you should not use a VPN. It is more nobs and thous more insecure than a simple PBS connection (SSH).
Unless your ISP is very incompetent, you have a static IPv6 prefix. Create a rule on your firewall to allow the PVE GUA IPv6, to your PBS GUA IPv6.
Your connection will be encrypted by default, so there is no need to double encrypt it with a VPN.

 

[Johannes S]

Now to your setup, I think you should not use a VPN. It is more nobs and thous more insecure than a simple PBS connection (SSH).

PBS doesn't work with ssh though but with https (via Port 8007), ssh is only needed for administration on the command line. And imho it's a wide stretch to assume that wireguard or openvpn are more insecure than ssh, imho the security of ssh/wireguard or openvpn is comparable.

I agree with you that it might be worth a shot for debugging to try it out without vpn but vpn has one big advantage that it's another layer thus reducing the surface visiblility to an potential attacker.