Capstone: designing and addressing a small business network

Rosa has signed a lease on a second cafe downtown, opening in the spring, and she wants both locations on a network that is secure, documented and easy for the next person to support. Sam and Jordan are asked to produce a complete design: the requirements, the VLANs and subnets for both sites, the IPv6 plan, DHCP scopes and reservations, the core services, the Wi-Fi plan, the firewall policy between networks, the link between the two cafes, and the documentation and tests that prove it all works. This capstone walks through that design from start to finish, drawing on every lesson in the course, and checks the plan with short Python scripts so that mistakes are caught on paper rather than on opening day.

Step 1: gather the requirements

A design starts with what the business needs, not with equipment. Sam interviews Rosa, Theo, Mei, Kai and Anita and lists the devices, the services they use and the rules that must apply. The payments industry's security standard, PCI DSS, sets one firm requirement: card terminals and the systems that handle card data must be separated from everything else and protected by firewall rules that allow only what they need. Guests must have internet access and nothing more. The roastery equipment talks to its manufacturer's cloud service and to the office for roast logs. Staff need the office file share, the printer and the internet. Network devices must be managed from a separate network that only Sam's and the contractor's laptops can reach.

Growth allowances are generous on purpose. Private address space costs nothing, and readdressing a live network later costs a weekend. Sam also notes three non-network requirements that shape the design: the payment terminals' supplier must be able to support them remotely, the network must keep taking card payments if the link between the cafes fails, and everything must be documented well enough that an outside technician could take over.

Step 2: the addressing plan

Sam gives each site its own /16 from the 10.0.0.0/8 private range: 10.20.0.0/16 for the main site and 10.21.0.0/16 for downtown. Inside each site, every VLAN gets a /24 whose third octet matches the VLAN number. That uses far more space than the device counts need, but it means an address tells you its site and its network at a glance: 10.21.20.31 is downtown, payments, and the gateway of every network is always .1. Lesson 5's VLSM techniques would pack the same networks into a single /22, which is the right choice when address space is scarce, as it is with public addresses; here readability wins. Every /24 also comfortably exceeds the growth allowances.

The IPv6 plan follows Lesson 6. The provider supplies a /48 for each site, 2001:db8:5a00::/48 for the main site and 2001:db8:5a01::/48 downtown, and each VLAN gets the /64 whose subnet ID matches its number. Within each /24, addresses are divided the same way everywhere: .1 is the gateway on the firewall, .2 to .49 are reserved for static devices and DHCP reservations, .50 to .249 are the DHCP pool, and .250 to .254 are spare for temporary use. Consistency is the point: anyone who has learned one network has learned all ten.

import ipaddress

sites = {'main': 20, 'downtown': 21}
vlans = {10: 'office', 20: 'payments', 30: 'guest', 40: 'equipment', 99: 'management'}

plan = []
for site, second in sites.items():
    for vlan, name in vlans.items():
        net = ipaddress.ip_network('10.%d.%d.0/24' % (second, vlan))
        plan.append((site, vlan, name, net))

for site, vlan, name, net in plan[:6]:
    hosts = list(net.hosts())
    print(site.ljust(9), str(vlan).rjust(2), name.ljust(10), str(net).ljust(15), 'gateway', hosts[0])
print('...', len(plan), 'networks in total')

nets = [p[3] for p in plan]
clashes = [(a, b) for i, a in enumerate(nets) for b in nets[i + 1:] if a.overlaps(b)]
print('overlapping networks:', clashes or 'none')
print('all inside 10.0.0.0/8:', all(n.subnet_of(ipaddress.ip_network('10.0.0.0/8')) for n in nets))

main      10 office     10.20.10.0/24   gateway 10.20.10.1
main      20 payments   10.20.20.0/24   gateway 10.20.20.1
main      30 guest      10.20.30.0/24   gateway 10.20.30.1
main      40 equipment  10.20.40.0/24   gateway 10.20.40.1
main      99 management 10.20.99.0/24   gateway 10.20.99.1
downtown  10 office     10.21.10.0/24   gateway 10.21.10.1
... 10 networks in total
overlapping networks: none
all inside 10.0.0.0/8: True

def address_plan(second_octet, vlans):
    plan = {}
    for vlan in vlans:
        plan[vlan] = {'network': '10.%d.0.0/16' % second_octet}
    return plan

print(address_plan(21, [20]))

Step 3: switching, VLANs and Wi-Fi

At each site, the firewall-router connects to the switch over a trunk carrying all five VLANs, with a sub-interface on the firewall for each VLAN acting as its gateway. Wired devices connect to access ports in their own VLAN: tills and card terminals in VLAN 20, the roast controller and cameras in VLAN 40, office computers in VLAN 10. Every unused port is disabled and placed in an unused VLAN, so plugging a stranger's laptop into a spare socket gives it nothing. The links to the access points are trunks carrying VLANs 10, 20, 30 and 99, the last for managing the access points themselves.

The Wi-Fi plan follows Lesson 10. The main site gets three access points, adding the one over the back tables; downtown gets two. Each broadcasts three SSIDs: Ridgeline-Staff, WPA3 Personal, mapped to VLAN 10; Ridgeline-Guest, open with Enhanced Open encryption and client isolation, mapped to VLAN 30; and a hidden payments SSID with its own long passphrase, mapped to VLAN 20, for the wireless card terminals. 2.4 GHz radios use channels 1, 6 and 11; 5 GHz radios use non-overlapping 40 MHz channels; transmit power is moderate, and a site survey after installation confirms -67 dBm or better at every table and at the counter.

Step 4: DHCP, DNS and NTP

The firewall-router at each site runs DHCP for its five VLANs, so each site keeps working on its own if the link between them fails. Each scope uses the pool .50 to .249 with the gateway .1 and the site's firewall as DNS and NTP server. Lease times differ by network: two hours for guests, where devices come and go; one day for the office; one week for payments and equipment, which rarely change. Every till, card terminal, printer, camera and controller gets a DHCP reservation between .10 and .49, recorded in the inventory, so its address never changes and firewall rules can refer to it. Network devices in VLAN 99 get static addresses, because they must work before DHCP does.

Each firewall runs a caching DNS resolver that forwards to the provider's resolvers, with a filtering resolver for the guest VLAN that blocks known malicious domains. Internal names such as nas.main.ridgeline.internal and printer.downtown.ridgeline.internal let staff find devices without memorizing addresses. Each firewall synchronizes its clock with public NTP pool servers and serves time to its site, so every till, terminal and log in both cafes agrees to the second.

def scopes(plan, leases):
    return ['vlan %d' % v for v in plan]

for line in scopes(PLAN, LEASES):
    print(line)

Step 5: the firewall policy

Traffic between VLANs, and between each site and the internet, passes through the firewall, which applies rules from the top down with the first match deciding. Sam writes the policy as a table first, with a reason for every rule, and only then configures it. The policy is the same at both sites apart from the site's addresses, and equivalent rules are applied to IPv6, so nothing slips past through the other protocol.

Order matters. Rule 4, which stops guests reaching internal networks, must come before rule 5, which allows guests the internet; the other way round, rule 5 would match internal destinations first, because 10.0.0.0/8 is part of any address. Testing a policy on paper, by running sample connections through it, catches exactly this kind of mistake before it reaches the firewall.

import ipaddress

RULES = [  # (source network, destination network, port or None for any, action)
    ('10.20.20.0/24', '198.51.100.0/24', 443, 'allow'),     # payments to the card processor
    ('10.20.20.0/24', '0.0.0.0/0', None, 'deny'),           # nothing else for payments
    ('10.20.30.0/24', '10.0.0.0/8', None, 'deny'),          # guests never reach inside
    ('10.20.30.0/24', '0.0.0.0/0', None, 'allow'),          # guests may use the internet
    ('10.20.10.0/24', '10.20.99.10/32', 445, 'allow'),      # office to the file share
    ('0.0.0.0/0', '0.0.0.0/0', None, 'deny'),               # default deny
]

def decide(src, dst, port):
    for number, (s, d, p, action) in enumerate(RULES, start=1):
        if (ipaddress.ip_address(src) in ipaddress.ip_network(s)
                and ipaddress.ip_address(dst) in ipaddress.ip_network(d)
                and (p is None or p == port)):
            return action + ' (rule ' + str(number) + ')'

tests = [('10.20.20.21', '198.51.100.25', 443), ('10.20.20.21', '10.20.10.37', 445),
         ('10.20.30.88', '10.20.20.21', 443), ('10.20.30.88', '203.0.113.200', 443),
         ('10.20.10.37', '10.20.99.10', 445), ('10.20.10.37', '10.20.99.10', 22)]
for src, dst, port in tests:
    print(src.ljust(12), '->', (dst + ':' + str(port)).ljust(20), decide(src, dst, port))

10.20.20.21  -> 198.51.100.25:443    allow (rule 1)
10.20.20.21  -> 10.20.10.37:445      deny (rule 2)
10.20.30.88  -> 10.20.20.21:443      deny (rule 3)
10.20.30.88  -> 203.0.113.200:443    allow (rule 4)
10.20.10.37  -> 10.20.99.10:445      allow (rule 5)
10.20.10.37  -> 10.20.99.10:22       deny (rule 6)

The last test shows the default deny doing its job: SSH from an office laptop to the storage box is blocked, because only the admin laptops may manage devices, under a rule left out of this short version. Running a list of expected and forbidden connections through the policy after every change is a cheap habit that prevents expensive surprises.

import ipaddress

def decide(rules, src, dst, port):
    return 'allow'

def audit(rules, cases):
    return []

print(audit(RULES, CASES))

Step 6: connecting the two sites

The cafes are joined by a site-to-site VPN: an encrypted IPsec tunnel between the two firewalls across the internet, with each firewall holding a static route to the other site's /16 through the tunnel, exactly as the routing table in Lesson 7 showed. Because each site has its own /16, one route covers everything at the other site, and the address plans never collide. The tunnel carries staff traffic, roast logs and the file share; card payments never use it, because each site's payment VLAN goes straight to the card processor over its own internet connection. If the tunnel or the downtown internet connection fails, downtown keeps selling: its tills and terminals need only their local firewall and the internet, and the shop's point-of-sale service stores sales locally until the connection returns.

A dedicated private circuit between the sites would be more predictable but costs far more; for two cafes, a VPN over business internet service is the usual choice. Sam documents the tunnel's settings, the pre-shared key's location in the password manager, and a test: from an office laptop at each site, ping the other site's firewall at 10.2x.99.1 and open the file share.

Step 7: documentation and testing

The design is only finished when it is written down and proven. Sam's documentation set covers: the requirements and the reasons for each design decision; the physical diagrams of both sites with rooms, cabinets, sockets and access points; the logical diagram with VLANs, subnets, gateways and the tunnel; the address plan and the reservations list; the device inventory with models, firmware and warranties; the firewall policy table with reasons; configuration backups of every network device; provider contacts and demarc locations; and a change log. All of it lives in the same repository as the shop's Python tools, so changes are reviewed and the inventory can be checked by script, as in Lesson 1.

Testing follows the layers and the policy. For each VLAN at each site: a device gets the right address, mask, gateway and DNS from DHCP; it can ping its gateway; names resolve; it can reach what the policy allows and cannot reach what it denies, checked from a laptop placed in each VLAN in turn. The guest network is tested from a phone: internet works, nothing internal answers, and other guests' devices are invisible. Card payments are tested with the processor's test transactions, then again with the site-to-site tunnel disabled. A Wi-Fi survey confirms coverage. Every result is recorded, so the next person can repeat the tests after any change.