Designing the Company Network

In the previous chapter, we translated the business requirements of Fetched & Far into a high-level architecture.

Before deploying identity services, applications or monitoring systems, however, those components need a secure way to communicate.

That makes the network the next logical step.

A company network isn't just a collection of switches and cables.
It defines which systems can communicate, where trust boundaries exist and how much damage a compromised device can cause.

Our goal is therefore not simply to connect everything.
Our goal is to connect everything that needs to communicate while keeping everything else separated.

Network Requirements

The network design must support several of the requirements we defined earlier in this series.

These requirements describe what the network must achieve.

They don't yet tell us which firewall, switch or VPN technology to use.
That distinction is important. We first design the network.

Technology will be selected afterwards based on that design.

Network Context

Fetched & Far currently operates two offices in Stuttgart and Zurich.

Zurich will serve as the primary infrastructure site. Most internal applications and platform services will initially run there.

Stuttgart remains the secondary site, but it shouldn't depend entirely on Zurich for basic operation.

Both locations therefore receive:

• An independent internet connection
• A local firewall and internet gateway
• Local DHCP services
• Local identity and DNS availability
• An encrypted connection between both offices

Customer-facing production systems are hosted in a separate cloud environment.

They aren't part of the corporate network and don't receive an automatic trust relationship simply because they belong to the same company.

This design gives both offices direct internet access while still allowing internal systems to communicate securely between locations.

It also avoids routing all Stuttgart internet traffic through Zurich.

That would create unnecessary dependencies on Zurich and the inter-site connection for normal internet access.

A Network Is Not a Trust Boundary

A common small-network design places every device into one large internal network.

Once a device is connected, it can communicate with almost everything else.

This is simple to build, but it creates a dangerous assumption:

Internal doesn't automatically mean trusted.

A managed employee laptop, a printer, a test server and a backup repository have completely different security requirements.
If all of them share the same unrestricted network, compromising one device may provide a path to every other system.

Fetched & Far will therefore divide its network into several security zones.

Traffic between those zones is denied by default and must be explicitly permitted by the firewalls.

Trust Zones

Corporate Clients

The corporate-client zone contains managed employee laptops and workstations.

These devices may access the internet, identity services and approved internal applications. They must not directly access infrastructure management interfaces, application databases or backup repositories.

Employees should access applications, not the infrastructure underneath them.

Engineering Lab

Fetched & Far is a software company.

Developers need environments in which they can test applications, containers and temporary systems.
These workloads change frequently and may run software that hasn't passed the same security checks as normal business applications.

The engineering lab is therefore separated from both corporate clients and production systems.

Developers can still reach the environment through controlled access paths, but experimental workloads cannot freely initiate connections into the rest of the company network.

Application Servers

The server zone contains normal internal applications.

Corporate clients may access the published application interfaces, usually through HTTPS or another explicitly approved protocol.

They don't receive direct access to every port on every server.

Connections between application servers must also be documented instead of being automatically trusted.

Core Services

Identity, DNS and the internal PKI form the foundation of the infrastructure.

Compromising these services could affect almost every other system.
They are therefore placed in a dedicated core-services zone rather than mixed with normal application servers.

Access to this zone is limited to required authentication, name-resolution and certificate services.

Administrative access follows a separate management path.

Management

The management zone contains firewalls, switches, hypervisors and administrative interfaces.

It cannot be reached from ordinary employee devices.
Administrators use separate privileged accounts and a controlled administrative workstation or jump host to enter this zone.

This doesn't make administrator accounts impossible to compromise.

It does, however, prevent an attacker who compromises an ordinary employee account from immediately reaching the most sensitive management interfaces.

Backup

Backups are only useful while they remain recoverable.

If an attacker can compromise an application server and then delete its backups using the same access path, the backup system has failed its main purpose.

Backup servers and repositories therefore receive their own isolated zone.

Only the traffic required for backup, monitoring and controlled administration is permitted.

The later backup and disaster-recovery chapter will define immutability, retention and off-site copies in more detail.

Printers and IoT

Printers, meeting-room displays and other embedded devices often have long update cycles and limited security controls.

They aren't trusted like managed employee devices.

Corporate clients may communicate with specific services such as printing, but IoT devices cannot initiate unrestricted connections to clients or servers.

Guest Network

The guest network contains visitor devices and personal employee devices.

Those devices aren't managed by Fetched & Far.

They receive internet access and nothing else.
They cannot access internal DNS, corporate clients, servers or management systems.

Why There Is No Corporate DMZ

Enterprise network diagrams often include a DMZ by default.

Fetched & Far doesn't currently need one.

Customer-facing applications run in a separate public-cloud production environment, while internal applications aren't directly published from either office.

Adding an empty DMZ would introduce another network and another set of firewall policies without solving a real problem.

If the company later publishes a service from the corporate environment, the requirement can be reviewed and a DMZ can be introduced for that workload.

Communication Between Zones

Creating VLANs isn't enough by itself.

Segmentation only becomes meaningful when communication between the networks is controlled.

Fetched & Far will follow a default-deny model.
A connection is permitted only when it supports a documented service.

A simplified traffic matrix looks like this:

The complete implementation will contain more rules.

The important principle is that every rule has a reason, an owner and a defined source and destination.

IP Addressing and Future Offices

The addressing structure should make a device's location and zone recognizable without becoming difficult to maintain.

Each office receives its own address block:

Equivalent zones use the same subnet identifiers at each site.

For example, the corporate-client network may begin at 10.10.10.0 in Zurich and 10.20.10.0 in Stuttgart, while management uses the same designated zone number at both locations.

The exact subnet sizes will depend on the expected number of devices.

Corporate-client networks can be larger than infrastructure networks, while management and core-service networks can remain comparatively small.

The important part isn't the specific number.
The important part is having a repeatable structure.

When a third office is opened, the IT team can reuse the same zones and firewall-policy template instead of designing another unique network.

Remote Access

Remote employees begin outside the corporate trust boundary.

Entering a username and password doesn't automatically make either the user or the device trustworthy.

Remote access will therefore require:

• A managed company device
• Multi-factor authentication
• An approved employee identity
• Access limited to the required applications or networks
• Central logging of important access events

Not every remote employee needs unrestricted network-level access.

Where possible, individual applications should be exposed through identity-aware access controls. Network-level remote access remains available for workloads that genuinely require it.

The exact remote-access technology will be selected in the next implementation phase.

Failure of the Primary Site

Zurich is the primary infrastructure location, but Stuttgart should continue basic operation if Zurich or the connection between both offices fails.

Because Stuttgart has its own internet gateway, DHCP, DNS and local identity availability, employees can continue authenticating and using internet and cloud services.

Internal applications hosted only in Zurich remain unavailable until Zurich is restored.

This is an intentional trade-off.

Duplicating every application across both offices would improve availability, but it would also increase cost and operational complexity.

At the current company size, that complexity isn't automatically justified.

The later disaster-recovery chapter will define recovery targets for individual services. Applications with sufficiently strict recovery requirements may then receive replication or failover capabilities.

Design Trade-offs

The network introduces more separation than a single flat network, but it deliberately avoids building two fully duplicated data centers.

This design doesn't attempt to eliminate every possible failure.

Instead, it creates clear security boundaries, removes avoidable dependencies and remains manageable by a small IT team.

Looking Ahead

We now know how the offices, remote employees, internal systems and cloud environment fit together.
We have also defined the trust zones and the communication principles between them.

The next step is turning this architecture into an implementation design.

That means selecting the firewall platform, defining the VLAN and subnet configuration, establishing the encrypted connection between Zurich and Stuttgart and choosing the remote-access approach.

As always, those technologies will be selected based on the requirements and architecture and not the other way around.