Table of Contents
Scenario Overview
In this capstone, you design and describe a secure network that connects multiple sites, such as two or three offices in different cities and possibly a data center or cloud environment. The goal is to bring together your knowledge of addressing, routing, VPNs, security controls, and high availability into a coherent design, without implementing every technology in detail.
A secure multi site network must let users at each location access shared resources as if they were in one building, while protecting internal systems from the public internet, limiting the blast radius of any breach, and remaining available when individual links or devices fail. Your project should show that you can think about security, scalability, and operations at the same time.
Business and Security Requirements
Before you touch any technical details, you define the requirements. In a real project, this step drives every design choice that follows. For this capstone, you can invent a simple fictional company, for example a small enterprise with a headquarters, a branch office, and workloads in the public cloud.
Typical business requirements include user access between sites, access to shared applications such as email and file servers, and some kind of remote access for users working from home. You can also assume that certain applications are more critical than others, for instance an internal ERP system vs. guest Wi Fi. This criticality will matter when you decide what to protect most and where to invest redundancy.
Security requirements often include isolation between internal corporate traffic and guest or public traffic, encryption for traffic across untrusted networks, controlled access to sensitive servers such as databases or HR systems, and monitoring for malicious activity. You should also consider compliance style requirements such as keeping logs for a defined period and limiting who can administer network devices.
In your project description, state these requirements in clear language, then refer back to them later when explaining design choices. The key is to show that every important part of your design exists for a reason, not just because you know a technology name.
High Level Multi Site Architecture
Once requirements are clear, you create a high level picture of how the sites relate to each other. At this stage, you do not dive into every VLAN or routing detail. You outline which locations exist, what roles they play, and how they connect over the internet or private links.
A common pattern for a small secure multi site network is a hub and spoke architecture. The headquarters, or a main data center, plays the role of hub. Branch offices and perhaps some remote facilities are spokes. Each spoke builds a secure tunnel to the hub. Traffic between two spokes usually passes through the hub, which simplifies security policy but may add latency.
An alternative is partial or full mesh between sites, where each site connects directly to others. This reduces hops and sometimes latency, but configuration complexity grows quickly as you add sites. For a beginner level capstone, a hub and spoke design is typically more realistic and easier to explain.
In your chapter, you can describe the logical architecture in text and support it with a table that summarises connections.
| Site role | Example location | Primary link | Backup link | Connection pattern |
|---|---|---|---|---|
| Hub | Headquarters | Business fiber to ISP | 4G or second ISP | Hub for all VPNs |
| Spoke | Branch A | Business cable to ISP | Optional 4G backup | VPN to hub |
| Spoke | Branch B | Business DSL to ISP | None | VPN to hub |
| Cloud region | Public cloud VPC | Cloud provider uplink | Provider managed | Site to site VPN |
Describe which services live where, for example central authentication servers in the hub, file and database servers in the data center, and local printers and Wi Fi at each branch. This will later guide your routing and security rules.
Site Connectivity and WAN Choices
Between sites you typically rely on untrusted networks like the public internet. Your job is to design a secure overlay on top of these unreliable and potentially hostile underlays. For a capstone, you usually assume internet access at each site and do not need to simulate the exact provider network.
You can explain why you choose a particular wide area connectivity pattern. For a basic scenario, each site uses a single ISP connection. For higher resilience, some sites have dual ISPs or a cellular backup. Clearly state which sites are more critical and therefore get redundant links.
The WAN design should also mention expected bandwidth and approximate latency, at least qualitatively. For example, you might note that headquarters has a higher bandwidth fiber link because it aggregates traffic from branches, while smaller branches have lower bandwidth connections. This gives context when you later prioritise some applications with quality of service features.
In this chapter, avoid explaining every possible WAN technology. Instead, focus on how your design uses the WAN as a shared, untrusted medium that must be protected with encryption and well planned routing.
Secure Inter Site VPN Design
To secure traffic between sites that use the internet, your design uses virtual private networks. In this capstone, you decide where VPN endpoints live, what traffic they protect, and how they scale as you add more sites.
A straightforward pattern is a set of site to site tunnels that terminate on security appliances or firewalls at each site edge. The hub device at headquarters terminates multiple tunnels, one per branch or remote site. Each branch device has a single tunnel up to the hub. This fits naturally into a hub and spoke architecture.
You should explain how these tunnels are used. For example, all traffic that is destined for the IP subnets of another site is sent inside the VPN. Other traffic, like general web browsing, may go directly to the internet from each site rather than hairpinning through the hub. This is often called local breakout. You can decide which approach your fictional company prefers and justify it based on performance and security considerations.
Your design can mention that the VPN protects the confidentiality and integrity of inter site traffic, and that authentication of endpoints ensures that only authorised sites can join the network. You do not need to go deep into key exchange mechanics, because those belong to more detailed protocol studies, but you should be clear that encryption is mandatory for all site to site traffic traversing the public internet.
IP Addressing and Routing Between Sites
A secure multi site network needs a carefully planned IP addressing scheme. You choose non overlapping private IP ranges for each site and for each type of segment within a site. Since this capstone focuses on design, you can pick a consistent block and subdivide it.
You might, for example, allocate a large private block to the whole organisation, then assign smaller ranges per site. Within each site you reserve separate networks for user devices, servers, printers, and management interfaces. The exact subnet sizes matter less than the fact that they do not conflict between sites and that you can aggregate them for simpler routing.
Your routing design defines how traffic learns to reach remote subnets. In a small hub and spoke layout, static routes can be enough. The hub router has a route for each branch subnet via the relevant VPN tunnel, and each branch has a default or summary route pointing to the hub for other sites. In a more advanced scenario you might introduce a dynamic routing protocol between VPN endpoints in order to handle changes more gracefully, but for a beginner level capstone, static routing is acceptable if you clearly explain it.
Presenting a simple addressing table makes the plan easier to read.
| Site | Role | Example subnet | Purpose |
|---|---|---|---|
| HQ | Hub | 10.0.0.0/24 | HQ user devices |
| HQ | Hub | 10.0.1.0/24 | HQ server segment |
| Branch A | Spoke | 10.1.0.0/24 | Branch A user devices |
| Branch B | Spoke | 10.2.0.0/24 | Branch B user devices |
| Cloud VPC | Data center | 10.100.0.0/24 | Cloud application tier |
This structure will later tie into network security policies, because you will write rules based on these subnets.
Segmentation Within Each Site
Security for a multi site network is not only about protecting site to site links. It also depends on how you segment networks inside each location. The same principles appear at every site, but the exact number of segments can vary with size and criticality.
Each site typically separates at least the following kinds of traffic. User endpoints, such as employee laptops and desktops, live in their own segments. Server infrastructure, whether at headquarters or in a data center, uses dedicated segments. Guest Wi Fi, if present, should be fully isolated from internal resources and often only permitted to reach the public internet. Management planes for switches, routers, and firewalls can use a restricted segment with tight access control from specific administrator workstations.
Segmentation lets you implement different policies per zone. For instance, a user network can reach certain application ports on the server network but not directly access internal databases. Guest Wi Fi cannot access servers at all. Only the management segment can reach device administration interfaces. Your project should show an awareness that not all segments are equal and that segmentation is a primary defensive tool.
To keep the capstone focused, you do not need to detail all switching or tagging mechanics. Instead, you describe the segments conceptually and explain how they contribute to limiting the spread of attacks across the network.
Perimeter Security and Firewalls
Every site that connects to the internet needs a secure perimeter. In your design, this perimeter is usually enforced by a firewall placed at the edge, between the local internal networks and the external ISP connection. For a multi site design, these firewalls also often terminate VPN tunnels and enforce inter site policies.
Your chapter should explain that all inbound traffic from the internet to internal services is controlled by explicit rules. Only the specific services that must be available from outside, such as a public web server in a demilitarised zone, are allowed. All other unsolicited inbound connections from the internet are denied by default.
Likewise, outbound access from internal networks to the internet is filtered according to policy. You can decide whether to allow all outbound connections except known bad destinations, or to restrict outbound to a defined set of ports and services. This is part of your overall security stance and you should justify your choice in the context of the fictional company.
For traffic between sites, the firewall can apply granular rules based on source site, destination site, segment, and port. For example, printers in a branch should not initiate connections to database servers in the data center. Even though the VPN creates a private, encrypted path, the firewall still decides which flows are acceptable.
In your project write up, describe the role of these firewalls and clarify that they are central points where security policy is enforced.
Zero Trust Principles Across Sites
A multi site network often tempts designers to think of the whole internal network as a single trusted zone. A more modern approach, which you can incorporate conceptually in this capstone, is to avoid trust by default between sites or even between segments.
Zero trust style thinking at this level means that just because traffic comes from an internal IP range or from another branch over a VPN, it is not automatically allowed to access everything. Instead, you explicitly allow certain flows based on authenticated identity, device posture, or at least tight IP based rules, while denying others by default.
In your multi site design, you can apply this by stating that each site is its own security zone and that communication among zones is whitelisted. For example, the branch user network is allowed to access only certain application ports on HQ servers, not to scan the whole HQ network. Cloud hosted workloads are only reachable from specific on premises subnets that need them.
You do not need to implement every advanced control, but you should demonstrate that you recognise that a VPN does not eliminate the need for internal security checks, and that lateral movement between sites should be carefully constrained.
Identity, Access Control, and VPN Users
Beyond site to site connectivity, your secure multi site network also requires secure access for roaming or home based employees. These users join the network from untrusted locations, and your design needs to explain how they reach required resources without weakening security.
One common solution is a remote access VPN that terminates at the hub site or at a dedicated security gateway. Remote users authenticate with strong credentials and, ideally, multi factor methods. Once authenticated, they are placed into a specific logical network from which policies control the internal resources they can reach.
Your chapter should distinguish between site to site VPNs, which connect entire networks, and remote access VPNs, which connect individual users. The policies for remote access are usually more restrictive. For example, a remote user might reach a subset of corporate applications but not be allowed to discover or connect to every subnet inside the enterprise.
Identity and access control are also relevant for administrative access. Routing and security devices across all sites should only be manageable from specific administrator accounts and stations. In your design you can note that management access is limited to a secure management network and that all administrative sessions are logged.
Logging, Monitoring, and Incident Response
A secure multi site design is incomplete without a plan for visibility. You must be able to detect and investigate suspicious activity that occurs in any site, over any tunnel, or at any edge. For this capstone, you do not need to implement logging systems, but you should describe what is logged and where.
At a minimum, firewalls at each site log denied and allowed connections, VPN gateways log tunnel establishments and failures, and important servers log authentication events. These logs are preferably forwarded to a central location at the hub or in a cloud based log system. Centralisation is important so that you can correlate events from different sites when investigating issues.
Monitoring should also include health checks, such as link status to each ISP, VPN tunnel state, and basic reachability tests between sites. Your plan can mention simple threshold based alerts for link failures or excessive denied connections, which might indicate an attack or misconfiguration.
You should also outline how an incident is handled conceptually. For instance, if suspicious traffic is detected from a branch, you can isolate that branch by tightening VPN policies or shutting down specific segments while investigation proceeds. Even if this process is not automated, showing that you have considered it demonstrates a practical security mindset.
Redundancy and High Availability Across Sites
Security is not only about preventing breaches, but also about ensuring that legitimate users can reach resources when expected. In a multi site context, availability becomes more complex because it depends on multiple links, devices, and tunnels.
Your design should identify which pieces are single points of failure and how you mitigate them for critical paths. For example, the hub site might have two firewalls in a failover pair, two routers towards two different ISPs, and redundant switches. Branches may have simpler setups, perhaps with a single firewall and single ISP if they are less critical.
You can describe how VPN tunnels behave in failover scenarios. If the primary ISP at a site goes down, a secondary link should establish a backup tunnel to the hub. Alternatively, the hub could maintain redundant tunnels terminated on different devices, with routing preferring the primary and switching to the backup when needed.
The key idea is that the most valuable services, such as core authentication, key application servers, and central security controls, should remain reachable even when individual components fail. For a capstone, you do not need to model every failure condition, but you should clearly state what level of resilience is intended and how it is achieved logically.
Putting It All Together
The secure multi site network capstone brings together the main threads of the course. You gather business and security requirements, choose an overall architecture that matches them, secure inter site communication with VPNs, plan non overlapping IP spaces and routing, implement segmentation within and across sites, and protect perimeters with clearly defined policies. You further think about identity, remote access, logging and monitoring, and high level redundancy.
Your final project deliverable typically includes a narrative description of this design, supporting diagrams and tables, and a short explanation of how the design could evolve as the company grows. The focus remains on clarity of thought and alignment with security needs, not on memorising every technology acronym.
In a secure multi site network, treat every link between sites as untrusted, encrypt all inter site traffic, and apply least privilege access controls between all segments and sites by default.
By following these principles in your capstone, you demonstrate that you can think beyond a single local network and design a coherent, secure environment that spans multiple locations and supports real organisational needs.