We have site-to-site VPN connections using Azure VPN Gateway and various on-prem network appliances at respective client locations. We are trying to on-board a new connection, but have an IP range conflict with a network on the other end. The diagram below, albeit a loose interpretation on the client side as I don't have all the details on their end, explains it best probably, but here are the facts:
IP Range Conflict on either end of Azure VPN S2S tunnel
- Network A (192.168.1.0/24) sits behind our Azure VPN Gateway and is our
responsibility. - Network B (192.168.2.0/24) is a target network for packets originating from
Network A, is our client's responsibility, and is hosted in a private cloud. - Network C (192.168.1.0/24) is another network within the private cloud that is
not relevant for our traffic except that it represents an IP range conflict
within the client's private cloud.
Azure support has indicated the only remedy is to re-IP one of the conflicting networks as conflicting ranges are not supported at this time. According to them, NAT is not a viable solution on either end of the tunnel. Adding a new subnet behind the Azure VPN Gateway and forwarding/NAT'ing the traffic to Network A is also not supported.
Because of the fallout of re-IP'ing Network A, we don't want to re-IP it. Unsurprisingly, the client doesn't want to re-IP their network, Network C, either. Maybe I'm just in denial, but has anyone else run into this scenario and successfully worked-around it or resolved it without re-IP'ing? If so, any documentation or configs supporting the solution that could be referenced would be most appreciated.
Thanks in advance for any help.
Best Answer
You have wrote that you are interested in routing between A and B network which is not conflicting... In case SonicWall is routing between this "internal client networks" and it is possible to not use specific IPs on network C you can do routing through the network not for whole 192.168.1.0/24 but for specific IPs as /32. In routing decision "better match wins". In that case the specific traffic would be routed from B to A correctly while the rest would be passed to network C...
Depends on type of VPN it could be easier or harder (if possible) to configure on SonicWall but technically that could be the way without NAT. In the worst case you can have additional device terminate VPN to Azure and on SonicWall has static route rule to directing these IPs to this additional Node.
This way Azure side will be never reachable from C but it wouldn't be the issue based on what you have wrote.
As you have wrote Azure VPN GW doesn't offer this feature the only option could be to do that on other side of the tunnel - SonicWall Appliance. From the B,C side you can address "remote" site like any not used IP range (e.g. 172.16.0.0/24) and once it would reach SonicWall it could be routed to VPN while before leaving the node it would be dNATed / mapped to 192.168.1.0/24 while e.g. keeping last octet value or doing 1:1 map listing all needed IPs). This way for VPN traffic the remote IP on Azure side would be "proper" 192.168.0.0/24 and Azure side would have no idea about the NAT.
In case you can't do this on SonicWall for any reason the way could be place another device capable to do it / under own management which would terminate VPN tunnel and from local network would be destination for the 172.16.0.0/24 traffic (route on local router).
The only problematic things would be the cases you are using DNS answering with 192.168.1.0/24 addresses and certificates using IP for identification. In the case of DNS stuff you need local DNS zone with "updated" values so the clients are contacting "correct" endpoints.