Build your first company network
A consolidation course: turn a small company’s requirements into a working, secure network. You put courses 1–5 to work – three groups by trust (employees, servers, guests) and a plan, VLAN segmentation, subnets and gateways with a router (inter-VLAN) and NAT out, a firewall with inside/DMZ/outside zones (web on 443, guests out only, default-deny) and finally a path test and topology check that shrinks the blast radius.
Lesson 1: Requirements and plan
A small company: what it has and needs
Welcome to the course where you finally put together everything from courses 1 to 5. No new magic – you will just try, on one small company network, how segments, VLANs, addresses and the firewall fit together. Picture a customer: a small company, a few dozen people. What is in it? Employees at computers who need the internet and shared files. Servers: a web server that outsiders also look at, and a file server with internal data. And now and then visitors and guests you want to give Wi-Fi to the internet – but certainly not into company data. All of it hangs on one internet connection from the provider. The scene shows that network schematically: the internet (NET) on the left, a firewall (FW) and a router (R) behind it, and on the right three groups of devices – employees (PC), servers (WEB and FILE) and guests (HOST). For now it is just a picture. Over five lessons you will build it step by step: first separate the groups, then give them addresses, let them out and finally protect them with rules. The single goal of the course: to turn a company’s requirements into a working and secure topology – and to understand every decision.
Step by step
- Employees at computers need the internet and shared files. That is the largest group of people in the company.
- Servers: a web server that outsiders look at too, and a file server with the company’s internal data.
- Guests and visitors want Wi-Fi to the internet – but certainly not into company data. You will keep this group apart.
- All of it hangs on one internet connection through a firewall and router. Over the course you will build this network step by step.
Three groups, three risks
Before you wire anything, ask the question every network designer asks: who actually needs to talk to whom – and who does not? The company has three worlds with completely different needs. Employees are trusted, but there are many of them and their computers catch emails, attachments and downloads – malware included. Servers are the most valuable: the web must be reachable from outside too (so it is the most exposed to attack), while files must never leave. And guests are entirely unknown devices you have no control over – possibly an infected laptop. If you threw everyone onto one flat network (as course 3 warns), this happens: an infected guest laptop sees straight to the file server, an employee virus spreads to the servers, and one incident floods the whole company. That flooding is called the blast radius. The whole design you are about to build is really about one thing: shrinking the blast radius by separating groups of different trust and putting a controlled door between them. Remember this threefold split by trust level – it is the guiding thread of the whole course.
Step by step
- Three groups with different needs: employees (trusted but vulnerable), servers (most valuable) and guests (unknown).
- If everyone were on one flat network, an infected guest laptop would see straight to the file server. You don’t want that.
- The incident floods the whole company – that reach of damage is the blast radius. A flat network makes it needlessly large.
- The design goal: separate groups by trust level and put a controlled door between them – shrinking the blast radius.
Sketch the plan: groups → segments
A good network is born on paper before it is in cables. Before you touch the simulator, sketch a plan – a ‘group → segment → what it may do’ table. You have three groups; you turn them into three separate segments. Employees → their own segment; may reach the internet and shared files, may not reach server management. Servers → their own segment, watched extra closely because the web is exposed outward; files stay purely inside. Guests → an isolated segment; may reach only the internet, nowhere into the company. That is the whole plan – three segments and a few arrows between them. Notice the design goes top-down: first decide WHAT you want (who may talk to whom), only then work out WITH WHAT you do it (VLAN, router, firewall). That order guides the whole course and matches the lessons: you build the segments with VLANs (lesson 2), addresses and passage between them come from the router (lesson 3), the controlled door and outward protection are added by the firewall (lesson 4), and finally you test it all (lesson 5). Now you have the map. Let us build by it.
Step by step
- Plan, row one: employees get their own segment. May reach the internet and shared files, not server management.
- Row two: servers get their own, extra-watched segment. The web is exposed outward, the file server stays purely inside.
- Row three: guests get an isolated segment. May reach only the internet, nowhere into the company.
- You have a three-segment plan. You will build it in this order: VLANs (l. 2), router and addresses (l. 3), firewall (l. 4), test (l. 5).
Lesson 2: Segmentation into VLANs
Why one flat network isn’t enough
We start building – and the first decision is the most important: divide. The simplest network is ‘everyone on one switch’, a so-called flat network: one big space where everyone can see everyone. It works – but it carries three problems you know from course 3. Security: anyone sees anyone, so an infected guest or an employee virus reaches straight to the servers (last lesson’s large blast radius). Broadcast: some messages are sent to everyone at once on one network; the more devices, the more useless noise that burdens every computer. Unmanageability: in one bag you cannot say ‘this group may go there, that one may not’. You can fix it physically – buy each group its own switch and its own cabling – but that is expensive and rigid (a new guest arrives and you pull cables). You need to split one physical network into several separate ones without touching the cables. That is exactly what a VLAN does, which we look at in the next module. Remember: a flat network is not ‘simpler’ – it is just a postponed problem that blows up at your first security incident.
Step by step
- A flat network = everyone on one switch, each sees each. It looks simple but carries three problems.
- Security: an infected guest reaches straight to the file server. A large blast radius, exactly as lesson 1 warned.
- Broadcast: messages for everyone are sent to each at once on one network – the more devices, the more noise.
- You need to split one physical network into several without pulling cables. A VLAN does that – in the next module.
Split into VLANs: employees, servers, guests
Here is the tool from course 3: the VLAN (virtual LAN). It splits one physical switch into several separate networks, as if you raised invisible walls. Devices in one VLAN see each other; into another VLAN they cannot reach on their own – broadcast does not spill out of it and a security boundary appears without a single new cable. Following the plan from lesson 1 you make three VLANs: VLAN 10 employees, VLAN 20 servers, VLAN 30 guests. The number (VLAN ID) is just the group’s tag: the switch tracks it for each frame itself and really inserts it into the frame (the 802.1Q tag) only on a trunk – out of an access port the frame goes untagged, as you saw in the Switching and VLANs course; the port you plug the guest cable or AP into you set as an access port in VLAN 30 and that is it. What have you just gained? Isolation: a guest in VLAN 30 now physically has no way to ‘peek’ into VLAN 20 with the servers – that wall is simply there. And beware an important detail you will appreciate only in the next lesson: a VLAN separates groups so perfectly that even those that SHOULD talk cannot do so on their own. Employees cannot even reach the shared files this way. That is not a bug – it is exactly the wall. Who may cross it, and how, in a controlled way, we solve with the router in lesson 3. But first try the VLAN split in the simulator.
Step by step
- VLAN 10 – employees. The port with their computers you set as an access port in VLAN 10. The first separate network appears.
- VLAN 20 – servers. The web and file server go into their own VLAN, separated from users.
- VLAN 30 – guests. Visitor Wi-Fi goes into an isolated VLAN. The number (VLAN ID) is the group’s tag; it is inserted into the frame (the 802.1Q tag) only on a trunk.
- Isolation done: a guest in VLAN 30 can’t peek into VLAN 20. The wall is so perfect that even those that should can’t talk on their own – the router fixes that (lesson 3).
Isolating the guests
Let us pause at the most sensitive group – the guests – because they reveal whether you truly grasp segmentation. From the company’s view a guest laptop is a completely foreign device: you do not know who manages it, whether it is up to date, whether it is infected. The rule was: a guest may reach only the internet, nowhere into the company. VLAN 30 gave it separation from employees and servers – but that alone is not enough. You want one more thing: guests should not see each other either. Why? So that two strangers on the same visitor Wi-Fi cannot poke into each other’s laptops – if one is infected, it will not infect the other. This is called client isolation and is the standard choice for guest Wi-Fi (you met it in course 3 and it returns in the Wireless in practice course). Sum up the guest logic in one sentence: separate them from the company (VLAN) and from each other (client isolation), and let them out only outward. This, by the way, illustrates the principle that drives all network security: the less you trust someone, the less you allow them. A guest is at the very bottom of the trust spectrum – so it gets the absolute minimum. Servers, which you trust most, you will conversely protect most carefully. And that protection of servers is exactly what the firewall is about, after addresses.
Step by step
- A guest laptop is a foreign device to the company – you don’t know who manages it or whether it is infected.
- VLAN 30 separated the guest from the company. It may go out only to the internet – nowhere into employees or servers.
- Plus client isolation: two guests on the same Wi-Fi can’t see each other. An infected guest can’t infect the next one.
- The principle of all security: the less you trust, the less you allow. Guest at the bottom (minimum), servers at the top (best protection).
Lesson 3: Router and addresses
Give each VLAN a subnet and gateway
VLANs raised the walls – now you give each room an address. Recall course 4: devices talk via IP addresses and every separate network needs its own subnet (range of addresses). So you give each VLAN one subnet: VLAN 10 employees → 10.0.10.0/24, VLAN 20 servers → 10.0.20.0/24, VLAN 30 guests → 10.0.30.0/24. The ‘/24’ means the last number (0–255) distinguishes individual devices inside – in practice .1 to .254, because .0 is the network’s own address and .255 is broadcast. Still plenty of room for the whole group. Each subnet also gets a gateway (default gateway): the address a device sends everything that heads outside its subnet. By convention the gateway gets the first address, say 10.0.10.1 for employees. Who is that gateway? The router – a device standing with one foot in each subnet, translating traffic between them (exactly the role from courses 3 and 4). An employee computer gets an address like 10.0.10.42, a /24 mask and gateway 10.0.10.1 – usually automatically via DHCP, so you do not set it by hand on every machine. (That DHCP server need not be a separate box, by the way – it can run right on the router.) When the DHCP server sits in just one network, a DHCP relay on the gateway forwards requests from the other subnets; you can try both in the simulator’s advanced mode. Three subnets, three gateways, one router in the middle. How the router physically hangs off all three VLANs over a single trunk cable you tried in the Switching and VLANs course (router-on-a-stick) – here you just build on it. The addressing plan is done; in the next module we set it in motion so the VLANs can finally (in a controlled way) talk through that router.
Step by step
- Employees get subnet 10.0.10.0/24 and gateway 10.0.10.1. The last number distinguishes individual computers.
- Servers get 10.0.20.0/24 with gateway 10.0.20.1. Their own subnet for the web and file server.
- Guests get 10.0.30.0/24. Their address, mask and gateway are handed out by DHCP automatically on joining.
- That gateway is the router: one foot in each subnet. Three subnets, three gateways, one router in the middle.
DHCP in a bigger network
You have the subnets and gateways thought out – but who hands those addresses to the clients? You will not set them by hand: that is what DHCP is for (you know it from Course 1). In a bigger network, though, three things come with it that you never meet at home. 1) The DHCP server need not stand in every network. A newcomer’s DHCP request is a broadcast – and a broadcast does not cross a router. (How exactly a router forwards packets between networks is covered in the very next module – for now it is enough that it finds the way.) Yet you need not build a server into every VLAN: one central one is enough (on a server, a router, a firewall or an L3 switch), plus a DHCP relay on each remote network’s gateway – the gateway catches the broadcast and forwards it to the server as an ordinary packet, then delivers the answer back. The central server then keeps a separate range (scope) for each network: employees get addresses from 10.0.10.x, guests from 10.0.30.x. In the simulator (advanced mode): you find the ranges on a router, firewall or L3 switch on the DHCP tab, in the “DHCP ranges – which networks to serve” field, a network picks the server in its settings (“Network DHCP server”) and you add the gateway in the “DHCP relay (gateway)” field. 2) Reservations by MAC. A printer or a server must not get a different address every week – you write a reservation into the range: “always give this MAC address this IP”. The comfort of DHCP with the permanence of a static address – and the range will not hand that address to anyone else. 3) DHCP can also be drained. The server has a finite number of addresses – and an attacker abuses that: a DHCP starvation attack spews requests with made-up MAC addresses until it sucks the range dry. A new honest client then gets no address at all – the network “is down” for them even though everything runs. Note the kinship with rogue DHCP from The switch in depth course: there the attacker answers instead of the server, here it silences the server. The defense is the same as for most L2 mischief: port security on the access port – a port locked to one MAC simply will not pass thousands of made-up addresses. Try it right away in the task below.
Step by step
- A new PC in the employee VLAN broadcasts for an address. But no DHCP server stands in this network – and a broadcast does not cross a router.
- DHCP relay: the gateway catches the broadcast and forwards it to the central server as an ordinary packet. One server thus serves all the VLANs – with its own range (scope) for each.
- A reservation by MAC: the printer or file server gets the same address every time from DHCP – and the range will not hand it to anyone else.
- DHCP starvation: the attacker spews requests with made-up MACs until the range runs dry – new clients get no IP. The defense: port security on their port.
Traffic between VLANs through the router
Now we solve the ‘problem’ that arose in lesson 2: VLANs separated groups so perfectly that even those that should cannot talk. An employee (VLAN 10) needs the file server (VLAN 20) – but those are two different subnets with a wall between them. You know the solution from course 3 as inter-VLAN routing: the only one allowed through the wall is the router – and that is good, because it is precisely the place where traffic can be controlled. How it works step by step: the employee’s computer finds the target (10.0.20.5) is not in its subnet, so it sends the packet to its gateway (10.0.10.1 = the router). The router looks in its table, sees the target belongs to VLAN 20 and forwards the packet out its other foot. The reply returns the same way. Result: employees reach the files, but they must pass through the router – giving you one place to later allow only what you want. And a key detail: the router connects only what YOU tell it to. Guests (VLAN 30) also reach the gateway through it – but they head solely to the internet; into the company the router simply does not let them. Here the control is born that the firewall will tighten in lesson 4. VLANs make walls, the router makes doors. Try inter-VLAN routing in the simulator.
Step by step
- An employee (VLAN 10) wants the file server (VLAN 20). Two subnets, the wall from lesson 2 between them.
- The computer finds the target isn’t in its subnet and sends the packet to gateway 10.0.10.1 – the router.
- The router sees the target is in VLAN 20 and forwards the packet. The employee reaches the files – through the router.
- Key: the router connects only what you tell it. It sends guests to the internet, not into the company. Here control for the firewall is born.
NAT out to the internet
One last addressing piece remains: letting the company out to the internet. Here you hit a fact from course 4: your internal addresses (10.0.10.x, 10.0.20.x…) are private – valid only inside the company; on the public internet no one knows or routes them. Out you can go only via a public IP address, of which the company usually has just one from the provider. How can a hundred computers share one public address? The solution is NAT (network address translation), more precisely its variant PAT: on the way out the router rewrites the internal address to that one public one (and remembers by port numbers which reply belongs to whom). To the internet it looks like all the company’s traffic comes from a single address; when a reply returns, the router translates it by port back to the right internal computer. NAT has a pleasant security side effect too: from outside there is nowhere to ‘knock’ – internal computers have no public address, so an attacker on the internet does not see them directly (but it is no substitute for a firewall, just a side effect!). In the simulator you enable NAT on the router (outbound PAT on the public interface) and immediately see the private addresses ‘hide’ behind one public one. That completes the addressing layer: inside, three subnets joined by the router; outward, one public address via NAT. You have a working network – now let us protect it.
Step by step
- Internal addresses (10.0.10.x, 10.0.20.x…) are private – on the public internet no one knows or routes them.
- The company usually has one public address from the provider. On the way out the router rewrites the internal address to it – that is NAT/PAT.
- To the internet all company traffic seems to come from one address. By ports the router returns each reply to the right computer.
- NAT side effect: internal computers have no public address, an outside attacker can’t see them directly. No substitute for a firewall – we add that now.
Lesson 4: Firewall and zones
Insert the firewall: inside/DMZ/outside zones
The network works – now we make it secure. Into the path between the company and the internet you insert a firewall (course 5): a gatekeeper that decides pass / drop on every packet by rules. So the rules can be written sensibly, the firewall divides the world into trust zones. You know the three classic ones: outside (the internet – trust no one from here), inside (the internal company network – employees, trusted) and DMZ (the demilitarized zone – the place for servers that people look at from outside). Why a special zone for servers? Because a web server must be reachable from the internet, making it the most exposed to attack. If it sat in inside and someone hacked it, the attacker would have a foot straight in the company. So you put it in the DMZ: if it falls, the attacker is stuck in a separate zone and cannot reach inside (and the file server with sensitive data) through the firewall. Note that a VLAN and a zone are not the same: a VLAN is a boundary on the switch (L2), a zone is a firewall concept (by trust) – you just map them to each other by hand now. So map your VLANs to zones: employees = inside, web server = DMZ, guests = their own untrusted zone close to outside. The file server with internal data belongs to inside (or its own strict zone), because it has no business going out. Zones are just boxes by trust; only the rules between them (the next two modules) decide who may go where.
Step by step
- Into the path between company and internet you insert a firewall: on each packet it decides pass or drop.
- The inside zone: the internal network – employees and the file server with internal data. Most trusted.
- The DMZ zone: the web server must be reachable from the internet and is thus most exposed. If it falls, the attacker is stuck here.
- Guests get their own untrusted zone close to outside. Zones are boxes by trust – rules come next.
Servers into the DMZ (web out on 443)
Now we write rules for the most valuable and most exposed element – the web server in the DMZ. You want the web to work for internet visitors without throwing the company wide open. The key is to let in only and exactly what is necessary. A web page runs on port 443 (HTTPS, course 1). So you write a rule: ‘from outside to the DMZ web server, port 443 → allow’. Full stop. No other door leads into the server from outside: whoever tries SSH (22), the database or anything else hits a wall. This is called the minimal attack surface – the fewer open ports, the fewer places someone can attack you. And now the second, easily forgotten half: the DMZ must not itself initiate a connection into inside. Why? Because if an attacker did take over the web, they must not hop onward to the file server. So you allow no ‘from DMZ to inside’ rule (at most a narrow exception if the web genuinely needs, say, a database – and even that only to a specific port and server). Result: from outside anyone reaches the web on 443, but the web itself is in a cage – it cannot look out into the company. This is exactly the point of a DMZ in practice. Try publishing the web into the DMZ in the simulator and verify 443 passes and the rest does not.
Step by step
- A single rule: from the internet to the web server, port 443 (HTTPS) → allow. The web works for visitors.
- Everything else from outside (SSH, the database…) the firewall drops. This is the minimal attack surface.
- The other half: the DMZ must not initiate a connection into inside. A hijacked web thus can’t hop to the file server.
- Result: anyone reaches the web on 443, but it is caged – it can’t see into the company. That is the point of a DMZ.
Guests out only, default-deny
It remains to finish the rules for the other zones and, above all, to snap shut the single most important rule of all. First the guests: per the plan they may reach only the internet. So you write ‘from the guest zone to outside → allow’ and nothing else; ‘from guest to inside’ or ‘from guest to DMZ’ simply do not exist, so guests cannot reach the company. Employees (inside) may go out to the internet and to the file server – so you allow ‘inside → outside’ and ‘inside → file server on the relevant port’. And now the main thing: what happens to a packet that matches no allow rule? Default-deny must hold: whatever is not explicitly allowed is forbidden. This is the heart of the whole firewall philosophy from course 5. Without it you would write forever – enumerating everything you want to forbid is endless and one day you forget something. With default-deny the logic is inverted and safe: you allow a narrow list of the necessary and everything else drops by itself. Order matters (course 5, first-match): specific allows on top, default-deny as the last rule at the bottom. Now you have the complete set: web out on 443, employees to files and out, guests out only, and behind it all the closed door of default-deny. The network is built and protected. In the last lesson we test and harden it.
Step by step
- Guests: rule ‘guest → internet → allow’ and nothing more. No rule leads into inside or DMZ.
- Employees: you allow ‘inside → file server’ and ‘inside → internet’. A narrow list of what they truly need.
- The firewall’s heart: default-deny. Whatever matches no allow rule, the firewall drops. The last rule at the bottom.
- You have the complete set: web on 443, employees to files and out, guests out only, default-deny over all. Testing remains.
Lesson 5: Test and harden
Path test: what may and what may not
Building the network is half the work; the other half is to prove it does exactly what it should – and nothing more. On a finished topology never rely on the impression ‘looks fine’. Open the path test in the simulator (send a test packet from point A to point B) and go through your lesson-1 plan point by point – both what SHOULD pass and what MUST NOT. Verify the positive cases: an employee reaches the file server (inside → files ✓), employee and guest reach the internet (→ outside ✓), an internet visitor opens the web on 443 (outside → DMZ:443 ✓). And above all verify the negative cases, because they reveal holes: a guest must not reach the file server (guest → inside = dropped), a visitor from the internet must not reach the file server (outside → inside = dropped) nor the web on any port other than 443. When a test comes out other than you expect, you have a bug in the rules – and it is better to find it now in the simulator than in production. This habit of ‘test both: what should pass and what must not’ marks a good network engineer. Go through the whole list and make sure your company does exactly what you planned.
Step by step
- Verify what should pass: an employee reaches the file server. Inside → files works – correct.
- An internet visitor opens the web on port 443. Outside → DMZ:443 passes – exactly as intended.
- Now the important part – negative tests: a guest must not reach the file server. Guest → inside = dropped. Good.
- And an internet visitor must not reach the file server. Outside → inside = dropped. Testing both = a good engineer’s habit.
Topology check and blast radius
With the path test you verified individual paths. Now lift your view and look at the network as a whole – that is what the topology check in the simulator is for: it walks your network and flags weak spots easily missed in per-path tests. What does it typically find? A forgotten over-broad rule (say ‘inside → anywhere’ instead of a narrow list), a service needlessly exposed outward, a device without segmentation, or a path you did not intend. For each finding ask the lesson-1 question: what is the blast radius? If this element fell or this rule were abused, how far would the damage spread? This is how you tell whether your segmentation truly works: an infected guest should be able to take down at most itself and a few other guests – not the whole company. A hacked web in the DMZ should be stuck in the DMZ – not hop to the file server. In the simulator there is a Blast-radius button for exactly this: it computes where an attacker from a chosen source can reach, so you do not have to just imagine it. When the audit shows one hijacked element reaches further than you want, you have a candidate for hardening: add a rule, narrow an allow, split off another segment. Network security is not one-off – it is a loop: build, test paths, run the audit, shrink the blast radius, and after every change (a new server, a new app) repeat it. Your first company network now stands on solid ground.
Step by step
- The topology check lifts your view above single tests: it walks the network as a whole and flags weak spots.
- A typical finding: an over-broad rule or a service needlessly exposed. For each, ask the blast-radius question.
- Good segmentation: an infected guest downs a few guests at most, a hijacked web is stuck in the DMZ. The blast radius is small.
- Security is a loop: build, test paths, run the audit, shrink the blast radius – and repeat after every change.
Summary and what’s next
You did it: from a few sentences of requirements stands a finished working and secure company network. Retrace the path you walked. Requirements and plan: three groups by trust level (employees, servers, guests), the goal of shrinking the blast radius, the plan on paper before the cables. Segmentation: three VLANs raised invisible walls, with guests also isolated from each other. Addresses: each VLAN got a subnet and gateway, the router joined them in a controlled way (inter-VLAN) and NAT let the company out via one public address. Firewall: inside/DMZ/outside zones, the web published on 443, guests out only, and over it all default-deny. Test and audit: you verified what should pass and what must not, and shrank the blast radius by audit. Notice you used almost nothing new – you just assembled courses 1 to 5 into one meaningful whole. And that is the network engineer’s main skill: not to know ever more terms, but to compose the known ones into a network that works and holds. What next? This network still has one of everything – one router, one firewall, one link out. What happens when one of them fails? The next course in the track picks up exactly there: Redundancy and Spanning Tree – how to build a network that survives when something breaks. You have a great foundation. Go build on.
Step by step
- Plan and segmentation: three groups by trust, three VLANs as invisible walls, guests isolated even from each other.
- Addresses: each VLAN got a subnet and gateway, the router joined them in a controlled way, NAT let the company out.
- Firewall: inside/DMZ/outside zones, web published on 443, guests out only, default-deny over all. Then test and audit.
- You assembled courses 1–5 into a working, secure network. What next? It has one of everything → course Redundancy and Spanning Tree. Congratulations!