NETW-0014 — Course Outline | Assiniboine College

What this course is

NETW-0014 builds directly on the Linux foundation established in Operating Systems Fundamentals. Where NETW-0001 covered the operating system itself — filesystem, users, packages, scripting, and basic networking — this course moves into server infrastructure. Students configure the services that real networks depend on: remote access, packet analysis, firewalling, time synchronisation, centralised logging, DHCP, DNS, web serving, VPNs, and containerisation.

The lab environment scales up from NETW-0001. Students work with four Ubuntu 24.04 LTS virtual machines in Hyper-V — two internal servers, one acting as a gateway with NAT, and additional VMs introduced in later weeks for VPN testing. All services are built incrementally: the DNS zones configured in Week 3 are used by the web server in Week 4, and the Nginx reverse proxy in Week 6 sits in front of a Docker container. Nothing is isolated.

NETW-0014 runs 7 weeks rather than 8. Week 2 absorbs what were originally two separate weeks — network analysis/firewalling and time sync/centralised logging — into one condensed week; nothing was cut, only re-paced. Week 7 is the final assessment: a short structured review followed by a single-sitting exam.

By Week 7, students have built and operate a functional Linux server infrastructure from scratch — one they understand end-to-end because they built every piece of it themselves.

Phase 1 — Weeks 1–2 Access & Infrastructure

Week 1 — Secure Remote Access

VM environment, SSH keys & hardening

Re-establish the multi-VM Hyper-V lab environment, then configure SSH for secure key-based remote access. Covers key generation, agent forwarding, sshd_config hardening, port changes, login banners, and automated lockout using fail2ban.

Day 1Course intro, lab environment overview, VM build and network config · Lab 0: Hyper-V setup, three Ubuntu VMs, external/LAN1/LAN2 vSwitches, static IPs

Day 2VM network config continued, NAT routing, connectivity verification · Lab 0 continued: configure S1 as NAT gateway, verify internet from S2/S3

Day 3SSH theory: key cryptography, public/private pairs, the auth flow · Lab 1B Part 1–2: generate 4096-bit RSA keys on Windows host, copy to all VMs via SCP

Day 4SSH hardening: disable password auth, change port, login banners · Lab 1B Part 3–4: sshd_config edits, Windows Terminal sessions, motd penguin banner

Day 5fail2ban: automated lockout, jail configuration, log monitoring · Mini-Assessment 1: written SSH theory + practical key auth and hardening verification

ssh-keygenauthorized_keyssshd_configSCPfail2banWindows Terminal Assessment Day 5

Week 2 — Network Analysis, Firewalling & Infrastructure Services

tcpdump, Mausezahn, IPTables/NFTables/UFW, NTP & rsyslog

Absorbs what were originally two separate weeks — network analysis/firewalling and time sync/centralised logging — into one condensed week; nothing was cut, only re-paced. Capture and generate traffic with tcpdump and mz, write matching firewall rule sets in three tools, build an NTP time hierarchy, and configure rsyslog end-to-end including centralised log forwarding.

Day 1tcpdump capture/filters, then Mausezahn packet generation incl. spoofed sources · Lab 2A: BPF filters, .pcap files, ICMP/UDP/spoofed-TCP with mz

Day 2Firewalling — IPTables, NFTables & UFW rule syntax, NAT, persistence · Lab 2B: matching rule sets across all three tools, UFW masquerade NAT, iptables-persistent

Day 3NTP: stratum hierarchy, server config on S1, clients on S2/S3, restrict ACLs · Lab 2C: ntp.conf on S1, timesyncd clients, verified with ntpq -p and tcpdump

Day 4rsyslog: facilities/severities, custom template, local & centralised logging, logrotate · Lab 2D: template + redirection on S1, S2→S1 forwarding, log rotation via cron

Day 5Packet, firewall, NTP, and logging review · Mini-Assessment 2: written theory + practical — firewall implementation, log diagnosis, rsyslog repair

tcpdumpMausezahn / mzIPTables / NFTables / UFWNAT / masqueradeNTP / ntpqrsysloglogrotate Condensed: 2 weeks → 1 Assessment Day 5

Phase 2 — Weeks 3–4 Network & Web Services

Week 3 — DHCP & DNS

ISC DHCP server, BIND9 zones & secondary DNS

Stand up two fundamental network services from scratch. DHCP covers the full lease lifecycle, scope configuration, and reservations. DNS builds a complete BIND9 installation with forward and reverse zones, a secondary server for redundancy, and ends ready for the split-horizon extension in Week 4.

Day 1DHCP protocol: DORA process, lease lifecycle, isc-dhcp-server intro · Lab 3A: install isc-dhcp-server on S1, verify status, check boot behaviour

Day 2DHCP scope configuration, reservations, troubleshooting misconfigs · Lab 3B: configure dhcpd.conf, assign S2 a reservation, verify lease on client

Day 3DNS theory: hierarchy, record types (A, AAAA, MX, CNAME, PTR, SOA, NS) · Lab 3C: install BIND9, configure named.conf, build the forward zone

Day 4BIND9 zone configuration: forward zone, reverse zone, named-checkzone · Lab 3D: reverse zone, secondary DNS zone transfer, dig interrogation

Day 5Secondary DNS: zone transfer, notify, verify redundancy · Mini-Assessment 3: written DNS theory + practical — build a working zone from spec

isc-dhcp-serverdhcpd.confBIND9named.confA / PTR / SOA recordsZone transfer Assessment Day 5

Week 4 — Advanced DNS & Web Services

DNS views, Nginx, SSL/TLS & log-driven troubleshooting

Extend the DNS server with split-horizon views for internal and external responses, then build a production-style Nginx web server — virtual hosts, SSL/TLS with a self-signed certificate, and a dedicated troubleshooting module using Nginx access and error logs to diagnose real failures.

Day 1Split-horizon DNS: why views exist, internal vs. external resolution · Lab 4A: backup BIND9 config, define internal-view and external-view in named.conf.local

Day 2DNS views testing and verification, ACLs, forwarders per view · Lab 4B: test resolution from internal and external clients, verify split responses

Day 3Nginx architecture, virtual hosts, server blocks, reverse proxy intro · Lab 4C: install Nginx, create yourname.net virtual host, enable in sites-available

Day 4SSL/TLS: self-signed certificates, Diffie-Hellman, HTTPS redirect, cipher config · Lab 4D: generate self-signed cert, configure ssl-params.conf snippet, test HTTPS

Day 5Nginx log-driven troubleshooting: access.log, error.log, 4xx/5xx diagnosis · Mini-Assessment 4: written SSL/DNS theory + practical — diagnose a broken Nginx config using logs

BIND9 viewsnamed.conf.localNginxserver blocksSSL/TLSaccess.log / error.log Enhanced: log troubleshooting Assessment Day 5

Phase 3 — Weeks 5–6 VPN & Containerisation

Week 5 — VPN: IPSec & WireGuard

StrongSwan PSK, certificate-based auth & WireGuard

Build a full VPN solution in three stages: StrongSwan with a pre-shared key, then migrated to certificate-based authentication using a self-signed CA. Friday introduces WireGuard as a modern contrast — simpler configuration, modern cryptography, and a direct comparison of the two approaches.

Day 1VPN concepts: tunnelling, IPSec, IKE, ESP, AH — and when to use each · Lab 5A: topology setup, S3 as second gateway, verify isolation between LANs

Day 2StrongSwan PSK tunnel: ipsec.secrets, ipsec.conf, SA verification · Lab 5B: install strongswan, configure PSK tunnel S1↔S3, verify with ipsec status

Day 3PKI concepts: CA chains, x.509 certificates, trust anchors, openssl intro · Lab 5C: install strongswan-pki, generate root CA, issue server certs for S1 and S3

Day 4Certificate-based IPSec: issue server certs, distribute CA trust, reconfigure tunnel · Lab 5D: migrate PSK to RSA cert auth, verify SA, then WireGuard

Day 5WireGuard: key pairs, [Interface]/[Peer] config, routing, IPSec comparison · Mini-Assessment 5: written VPN/PKI theory + practical — bring up a WireGuard tunnel from spec

StrongSwanipsec.confipsec.secretsstrongswan-pkix.509 / CAWireGuard New: WireGuard Assessment Day 5

Week 6 — Containerisation with Docker

Docker, docker-compose & Nginx reverse proxy capstone

Introduce containers from first principles — what they are, how they differ from VMs, and why they matter. Students install Docker, work with images and containers, manage volumes and port bindings, and finish the week with a capstone that ties it all together: an Nginx reverse proxy sitting in front of a Dockerised application.

Day 1Container concepts: namespaces, cgroups, images vs. containers, VMs vs. containers · Lab 6A: install Docker via docker.io, verify with docker version and docker info

Day 2Docker images, containers, volumes, port mapping, docker hub · Lab 6B: pull images, run containers, inspect logs, map ports, persist data with volumes

Day 3docker-compose: multi-container services, YAML syntax, networks · Lab 6C: write a docker-compose.yml for a two-container stack, bring up and verify

Day 4Capstone: Nginx reverse proxy in front of a Docker container · Lab 6D — Capstone: run a web app in Docker, configure Nginx proxy_pass, update DNS, test end-to-end

Day 5Course review: cumulative Q&A, exam format walkthrough, lab catch-up · Open lab: students consolidate VMs and verify all services are running ahead of Week 7

Dockerdocker-composeImages / containersVolumesPort mappingproxy_pass New: docker-compose + capstone

Phase 4 — Week 7 Final Exam

Week 7 — Final Exam

Structured review & single-sitting exam

A four-day structured review across every topic in the course, followed by a single-sitting final exam on Friday — 20 minutes written, 100 minutes practical, using the student's own VM environment as the exam platform. Passing requires meeting the minimum threshold on both components independently.

Day 1Structured review — Weeks 1–2: SSH, packet analysis, firewalling, NTP, logging · Instructor-led command reference session; students may complete any outstanding labs

Day 2Structured review — Weeks 3–4: DHCP, DNS, Nginx, SSL · Scenario walk-throughs: diagnose a broken service using only logs and man pages

Day 3Structured review — Week 5: VPN, PKI, WireGuard · ipsec status / wg show interpretation drills, certificate-chain walkthrough

Day 4Structured review — Week 6 + exam format walkthrough · Docker review, capstone recap, VM health check — ensure all services start on boot

Day 5Final Exam — single sitting · 20 min written + 100 min practical · Scenario-based server tasks on the student's own VMs · No notes, no internet

Final Exam Day 5 20 min Written + 100 min Practical

Weekly assessments at a glance

Week	Assessment	Format	Key skills tested
1	Secure Remote Access	Written (30%) + Practical (70%)	SSH key generation, sshd_config hardening, fail2ban configuration, Windows Terminal sessions
2	Network Analysis, Firewalling & Infrastructure Services	Written + Practical	tcpdump/mz filter syntax and packet crafting, IPTables/NFTables/UFW rule sets, NAT masquerade, NTP server/client config, rsyslog rules and centralised log delivery, log analysis
3	DHCP & DNS	Written + Practical	dhcpd.conf scope and reservations, BIND9 forward/reverse zones, secondary DNS, named-checkzone
4	Advanced DNS & Web Services	Written + Practical	BIND9 split-horizon views, Nginx virtual hosts, SSL/TLS config, log-based fault diagnosis
5	VPN — IPSec & WireGuard	Written + Practical	StrongSwan PSK and cert-based tunnels, PKI/CA concepts, WireGuard peer config, SA verification
6	No formal assessment	Lab completion + capstone	Docker, docker-compose, Nginx reverse proxy — verified by instructor during capstone
7	Final Exam	Written (20 min) + Practical (100 min), single sitting	All topics — scenario-based server configuration and troubleshooting on student's own VMs

Passing requirements

Minimum grade requirementTo pass NETW-0014, students must achieve a minimum average grade of 50% on both the Written and Practical portions of the Final Exam independently. A strong practical result cannot compensate for a failing written score, and vice versa. Both components must meet the threshold.

Key design principles

Services build on each otherNothing in this course is a standalone exercise. The DNS zones built in Week 3 serve the Nginx virtual host in Week 4. The SSL certificates generated in Week 4 introduce the PKI concepts formalized in the VPN week (Week 5). The Nginx server configured in Week 4 acts as a reverse proxy to a Docker container in Week 6. Students who maintain their VMs throughout will arrive at the exam with a working infrastructure they understand completely.

Logs are the diagnostic toolFrom Week 2 onward, the answer to "why isn't this working?" is always "check the logs first." rsyslog in Week 2, Nginx access and error logs in Week 4, syslog output from ipsec in Week 5, and Docker logs in Week 6 all reinforce the same habit: when a service misbehaves, the log file tells you why. The Week 4 troubleshooting module makes this explicit, but the expectation is present from Week 2 onward.

Week 5 is the technical peakThe VPN week is the most conceptually dense of the course — IPSec protocol mechanics, IKE negotiation, PKI trust chains, certificate issuance, and then WireGuard as a contrast. The PKI lecture on Day 3 is the bridging piece: students have already generated self-signed certificates in the Nginx lab, so the concepts are not entirely new. The goal is to formalise what they already did intuitively and show how the same trust model applies to VPNs.

Week 2 is condensed, not cutCompressing two weeks into one meant re-pacing, not trimming. Every command, concept, and lab task from the original two-week sequence is still covered in class or moved to an optional take-home extension on the relevant lab handout — nothing a student needs for later weeks was removed.