Score:1

2 Remote Sites, 2 Different Subnets, with interconnectivity. How to create a single subnet for servers at both locations?

us flag

Current Environment:

We currently have 2 remote sites, both with their own LAN subnet and servers hosted at each site. Currently each site is using 1 subnet for the clients and servers. Both sites are directly connected to each other over an ISP provided LAN extension. There is connectivity between both sites and servers/clients can all communicate with each other.

Question:

When we migrate our virtual servers from one site to another, we have to change the IP address of each server that is moved to reflect the destination subnet. I know DHCP can handle this, but I would like to keep the IP addresses the same, regardless of which site the servers are in. This also adds steps to the migration process

Is it possible to create a VLAN on both sites with the same subnet information and have the servers in this VLAN? I know how to do this for a single site, but what if Server1 @ Site 1 (192.168.50.20) gets moved to Site 2? How will the router know where to route the traffic for Server1? Static routes just direct traffic to a gateway and if there are 2 subnets with the same network configuration, how will the router know where to route traffic if the IP it is trying to route traffic for doesn't exist in that gateways network?

We are using FortiGate 51E's at each site with FortiSwitch 248D's at each site. Both environments have ESXi 6.7 servers.

Below is a picture of the environment I'd like to have.

enter image description here

Score:1
ru flag

I would like to keep the IP addresses the same, regardless of which site the servers are in

That is a very, very bad idea unless you migrate the server subnet in whole.

You don't want your routing to be ambiguous, requiring cumbersome workarounds like NAT, proxy ARP and such. In your diagram, if 192.168.50.10 wanted to talk to 192.168.50.20 - assuming /24 subnets - it would assume to be talking to a direct neighbor and try to ARP 192.168.50.20. With both servers in different broadcast domains that simply fails.

You could bridge the server VLAN across the LAN extension but then again, it's bad practice to extend L2 segments across WAN/VPN (for manageability, scalability, resilience, ...).

Instead, make sure that your servers are always referred to by DNS name, then changing the IP address behind that name is a breeze.

us flag
Thanks for the input. I would love to use DNS names for everything, but there's quite a few configurations that require IP addresses such as our FortiGate VIP's for forwarding traffic, nagios is using IP addresses (I haven't looked into using DNS for this), our transport rules for Exchange uses IP address, so does our MTA rules for our email antispam, and a few other devices that only allow IP addresses. When we migrate servers we end up having to change a lot of these configurations and our scripts only get us so far in terms of automating this change. I'll try to use DNS as much as possible.
Zac67 avatar
ru flag
Migrating those ambiguous addresses over to another location requires even more work - just create a setup and then a plan for migration and you'll see. You should use address objects on the FGT, then they're quickly changed.
K-att- avatar
es flag
If you really want to use the IP, you can do it, if every server are in the different subnet. (example 10.23.<server number>.1/24) And you need just change the routing information when you change the server's location....
Zac67 avatar
ru flag
@K-att- Putting each server in its own subnet would also work but could be laborious to route (as it requires migrating the routes and router interfaces as well). However, a /30 or /31 subnet would be totally sufficient.
K-att- avatar
es flag
Ok, /30 or /31 subnet much better :).
us flag
Good points regarding the different subnets for each server, I didn't think about that!
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.