Hi all, I'm stuck on this and hoping someone has faced it before.
Setup: On-prem VBR 12.3.2 (10.91.5.243). In Azure there's a Veeam Backup for Azure appliance v6 with private IP only (no public IP allowed by the customer). Connected via IPSec site-to-site VPN. I need to register the appliance in the VBR console to do a failback of an Azure VM back to on-prem vSphere.
What I've tried:
- Add Server wizard -> Veeam cloud-native backup appliance -> connect to existing appliance, using the appliance private IP -> fails
- Test-NetConnection to the appliance IP on 443 shows True, but I later noticed the latency is <1ms and there's an ARP entry for it on our LAN. So I think my tests were reaching some local device, not the appliance in Azure
- Browser from the VBR server to the appliance IP gets redirected to :4343 and refused (Veeam support told me 4343 is not even a Veeam port)
- Checked proxy on the VBR server (winhttp, IE settings, env variables). All clean, no interception
- Veeam support confirmed v6 is compatible with VBR 12.3.2, and that the connection must come from the VBR's real IP (SNAT gets rejected)
The complication: our on-prem LAN and the appliance's Azure subnet use the same range (10.91.5.0/24) and this is intentional, so failover VMs keep their original IPs. I suspect this is why the traffic never reaches Azure: the VBR server thinks the appliance IP is on its own local network.
My question: how do people handle this? Would moving the appliance to a different subnet in the same VNET (e.g. 10.3.5.x) and routing that through the tunnel work or is there a better/proper way to connect VBR to the appliance in this kind of overlapping-subnet design? Anything I should watch out for if the appliance's IP changes?
Any advice appreciated, thanks!
