3

We have three campuses and two data centers.

We are considering assigning IP addresses to devices based on the department, so people can move between campuses and those campuses connect to DataCenters through WAN link.

How do we know where each client is based on the routing table from the DC WAN routers when reply happen the subnet IPs are distributed between campuses?

The only option I am thinking of is to define a default route from DCs WAN to the biggest Campus, and if any IP assigned to other campus users, a route to the specific IP will be advertised that it should go from this interface (from DC WAN routers perspective).

I am not sure how individual IP addresses assigned to end-users be advertised that they are behind Router X or Router Y.

13
  • 7
    Why do you think that is a good idea and justifies the effort?
    – Zac67
    Commented Jul 8 at 8:06
  • 1
    And why not per department and campus?
    – vidarlo
    Commented Jul 8 at 8:30
  • 2
    Probably want to have an address follow a device to compensate for some other policy or technology shortcomings or failure. This will not work. If it does somehow, it will be incoherent and unsupportable.
    – Greg Askew
    Commented Jul 8 at 9:04
  • 4
    If they're in the same VLAN there's no routing.
    – vidarlo
    Commented Jul 8 at 9:19
  • 1
    Have you looked into solutions such as zScaler?
    – vidarlo
    Commented Jul 8 at 9:57

2 Answers 2

9

I see a big problem looming behind your question:

Using ACLs on subnets and static IP addresses is a common and simple mechanism for defining access privileges. Subnets are (usually) organized by routing, and if static IPs are enforced by DHCP snooping etc. then those criteria can be considered fairly secure.

However, if you begin moving your addresses around at will - roaming users with static addresses - then those criteria are considerably weakened - you put all your trust in a client's MAC address (instead of MAC & location). Also, you'd need to handle a zoo of virtual routers with proxy ARP and distributed VLANs. While that should be doable, it's definitely not a small feat and encumbered by security compromise. Most likely, the result isn't worth the effort.

Imho, this is exactly the right moment to reconsider your security concept.

One possible approach would be to enable your network to identify users instead of machines or just addresses. In extreme, that results in a zero trust concept where each service is sufficiently hardened to withstand attacks, so that security on the network side becomes expendable.

A more traditional approach is to use IEEE 802.1X port security in combination with VLAN-based security zones. That requires you to define each VLAN in each location, but as long as that can be handled it's quite secure (and the logical evolution of your current concept).

Another possibility is an overlay network. All clients need to connect to your network via VPN, regardless of location. Within that VPN, each client can be identified by its unique address where you can then anchor your trust.

2

Possible approaches will vary depending on the number of departments and/or users.

  • One possible approach (when the sites are quite close together, usually, and the number of users per department remains relatively low) is simply to have network-wide VLANs, one for each department. You set up 802.1X on all switches and APs. When a user connects, they are assigned to the relevant VLAN, and you have one DHCP pool per VLAN. But that means pretty large broadcast domains, and inefficient use of WAN links.

    This of course requires a way of bridging each VLAN between the various sites, which means either that you have a pure L2 network, or that you tunnel Ethernet over IP or any other tech you have between the sites.

  • Another approach is similar, but instead of having a single VLAN spanning the whole network for each department, who have one VLAN per department and per site. Like before, you use 802.1X to authenticate users and assign them to the VLAN for their department on that specific site. DHCP pools are specific to each VLAN, so users will change IP when they switch from one site to another, but that reduces the size of the broadcast domain, and avoids broadcasts over the WAN links.

    The question then is if you split the total IP range by site and then by department or the other way around.

  • If you really want to keep the same IP from one site to another but don't want network-wide VLANs, then you'll probably have to resort to some form of tunnelling (PPPoE, L2TP, GRE, IPSec, whatever is trendy these days). This would be similar to how people can connect to your network remotely (with a VPN client), but on the internal network. I believe some switches are capable of doing that for you (i.e. instead of requiring a VPN client on each computer), again based on 802.1X credentials, but in the worst case you can ask them to use a VPN client.

    An alternative (depending on how users are split on the various sites) is that they don't need the VPN on their "home" site, but need it when they move somewhere else, like when they're on the go. But that means educating users.

There are probably other possibilities.

Note however that relying on MAC or IP addresses for filtering and security is probably not the best idea. Real authentication (https and other SSL/TLS-based protocols, ssh...) is a much better idea, backed by a good directory with appropriate permissions per user or group.

3
  • Re network-wide VLANs - not necessarily. L2 over WAN is cumbersome and what you really need is not the VLAN but the security zone, which you can happily route between (or not).
    – Zac67
    Commented Jul 9 at 9:04
  • @Zac67 That would be the second option, wouldn’t it?
    – jcaron
    Commented Jul 9 at 9:32
  • Yes, pretty much so!
    – Zac67
    Commented Jul 9 at 14:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .