08-02-2025, 01:11 PM
Here are the key things I’d recommend checking:
⸻
1. Force HBS to Use the VPN Interface:
Even though OpenVPN is connected and routing is in place, HBS by default chooses the “Default Route” interface — which can cause it to bypass the VPN tunnel altogether if it detects a public IP for the DDNS target.
• In HBS 3, under the Backup Job > Edit > Network Interface section, try explicitly assigning the VPN adapter instead of leaving it on “Auto” (you may need to set the route manually if it doesn’t appear).
• If HBS doesn’t show the VPN interface, double-check in Network & Virtual Switch > Interfaces to confirm the OpenVPN tunnel is registered as a valid interface, and it has a route to the remote subnet.
⸻
2. QuDedup Compatibility Error:
This error typically shows up when:
• The remote NAS is running an older version of HBS (must be at least 3.x for QuDedup support).
• Or when you attempt to run a QuDedup job against a NAS that doesn’t support it, over the network.
Solutions:
• Make sure both NAS units have the latest version of HBS 3 installed from the App Center.
• If the TS-453D doesn’t support QuDedup (older model or older firmware), you’ll need to disable QuDedup entirely on the backup job. Unfortunately, this can’t be edited once a job is created, so you’ll need to recreate the job from scratch with QuDedup off.
⸻
3. IP/Subnet & Static Route Validity:
You’ve done well by separating the subnets, but also verify:
• The static route on the local NAS sends all 192.168.y.x traffic through the OpenVPN tunnel.
• That the remote NAS sees the traffic as coming from inside the VPN subnet, not from WAN.
• If both sides are QNAP and using client-server VPN setups, also confirm that the OpenVPN connection is active on the NAS, and not just on your router or another device.
⸻
4. Temporary Diagnostic Tip:
Try running an rsync or plain file transfer job over the VPN tunnel outside of HBS, e.g. using:
rsync -avz -e 'ssh -p 22' /source_folder admin@remote-ip:/destination_folder
⸻
1. Force HBS to Use the VPN Interface:
Even though OpenVPN is connected and routing is in place, HBS by default chooses the “Default Route” interface — which can cause it to bypass the VPN tunnel altogether if it detects a public IP for the DDNS target.
• In HBS 3, under the Backup Job > Edit > Network Interface section, try explicitly assigning the VPN adapter instead of leaving it on “Auto” (you may need to set the route manually if it doesn’t appear).
• If HBS doesn’t show the VPN interface, double-check in Network & Virtual Switch > Interfaces to confirm the OpenVPN tunnel is registered as a valid interface, and it has a route to the remote subnet.
⸻
2. QuDedup Compatibility Error:
This error typically shows up when:
• The remote NAS is running an older version of HBS (must be at least 3.x for QuDedup support).
• Or when you attempt to run a QuDedup job against a NAS that doesn’t support it, over the network.
Solutions:
• Make sure both NAS units have the latest version of HBS 3 installed from the App Center.
• If the TS-453D doesn’t support QuDedup (older model or older firmware), you’ll need to disable QuDedup entirely on the backup job. Unfortunately, this can’t be edited once a job is created, so you’ll need to recreate the job from scratch with QuDedup off.
⸻
3. IP/Subnet & Static Route Validity:
You’ve done well by separating the subnets, but also verify:
• The static route on the local NAS sends all 192.168.y.x traffic through the OpenVPN tunnel.
• That the remote NAS sees the traffic as coming from inside the VPN subnet, not from WAN.
• If both sides are QNAP and using client-server VPN setups, also confirm that the OpenVPN connection is active on the NAS, and not just on your router or another device.
⸻
4. Temporary Diagnostic Tip:
Try running an rsync or plain file transfer job over the VPN tunnel outside of HBS, e.g. using:
rsync -avz -e 'ssh -p 22' /source_folder admin@remote-ip:/destination_folder