Project 5: Network Lab (NAT vs Bridged)

Control FreeBSD networking in a VM, switching between NAT and bridged modes with static and DHCP configs.

Quick Reference

Attribute Value
Difficulty Level 2
Time Estimate 1-2 weekends
Main Programming Language Shell (sh) (Alternatives: csh, Python)
Alternative Programming Languages sh, csh, Python
Coolness Level Level 2
Business Potential Level 1
Prerequisites Projects 1-4 complete
Key Topics ifconfig, rc.conf, DNS, NAT vs bridged

1. Learning Objectives

By completing this project, you will:

  1. Identify the correct FreeBSD interface name for your VM.
  2. Configure DHCP and static IP settings persistently.
  3. Switch between NAT and bridged modes and validate reachability.
  4. Diagnose DNS and routing failures with a repeatable checklist.

2. All Theory Needed (Per-Concept Breakdown)

Concept 1: IP Configuration and Routing on FreeBSD

Fundamentals FreeBSD configures network interfaces with ifconfig for immediate changes and /etc/rc.conf for persistent configuration. A working network configuration requires an IP address, a netmask, a default route, and DNS resolvers. DHCP automates these, while static IPs must be declared explicitly. Routing can be inspected with netstat -rn. DNS resolution uses /etc/resolv.conf, which may be managed by DHCP or edited manually. For this project, you must be able to assign an IP, set a gateway, verify the route table, and test DNS separately from raw IP connectivity.

In practice, write a short checklist for IP configuration and routing and confirm it after each reboot. This keeps the concept concrete and prevents accidental drift between sessions.

Deep Dive into the concept A FreeBSD VM sees a virtual interface, often named em0, vtnet0, or hn0 depending on the hypervisor and driver. The first step in networking is identifying that interface and ensuring it is up. ifconfig -a lists interfaces and their link status. If the interface is down, you can bring it up with ifconfig em0 up. DHCP uses dhclient to request an IP, default gateway, and DNS settings. In rc.conf, you enable DHCP with ifconfig_em0="DHCP" and the rc system handles dhclient at boot. For static configuration, you specify the IP and netmask, and set defaultrouter for the gateway.

Routing is often the hidden source of errors. Even if an interface has an IP, without a correct default route the VM cannot reach the Internet. The route table should include a default route (0.0.0.0/0) pointing to your gateway. netstat -rn shows this clearly. DNS is another independent layer. If you can ping an IP but not a hostname, your routing is fine but resolver configuration is broken. /etc/resolv.conf is a simple file with nameserver lines, and it must point to a reachable DNS server.

When switching between DHCP and static configurations, you must manage conflicting settings. If rc.conf contains both DHCP and static entries for the same interface, the results can be unpredictable. The safe approach is to keep only one active and comment out the other. Also, if your VM is in bridged mode, your static IP must be in the same subnet as your LAN and must not conflict with an existing device. In NAT mode, your IP is in a private subnet created by the hypervisor, and inbound access from the LAN is blocked unless you set up port forwarding. These context differences are why this project requires testing both modes.

Ultimately, networking reliability comes from a clean configuration and a disciplined troubleshooting sequence: check link, check IP, check route, check DNS. Each layer has specific commands and expected outputs. Once you learn to isolate layers, you will debug networking faster than most administrators.

Operationally, IP configuration and routing is easiest to keep stable when you treat it as a small contract between configuration, tooling, and observable outputs. Write down the exact files that own the state and the commands that reveal the current truth. Then verify the contract at three points: immediately after you make the change, after a reboot, and after a deliberate disturbance such as restarting services or reloading modules. FreeBSD rewards this discipline because it rarely hides state; if something changes, it is usually in a file you control. Make a habit of collecting a before-and-after snapshot of commands and outputs so you can explain which change caused which effect.

At scale, IP configuration and routing is also about failure containment. Identify what must remain available when something breaks and design a safe escape hatch. For example, keep console access for firewall changes, keep a previous boot environment for upgrades, or keep a dataset snapshot before risky edits. The same pattern applies across domains: define invariants, define the rollback path, and then only proceed when you can trigger that rollback quickly. Finally, test the failure path while the system is healthy; you learn more from a controlled rollback than from an emergency. This perspective turns the lab exercise into an operational capability you can trust on production systems.

How this fits on projects

  • This concept is applied in Section 3.2, Section 5.4, and Section 6.
  • It is essential for P09 Jail Lab where virtual interfaces multiply.

Definitions & key terms

  • ifconfig -> Configure and view interfaces.
  • defaultrouter -> rc.conf variable for default gateway.
  • resolv.conf -> DNS resolver config file.
  • route table -> Kernel map of how packets leave the system.

Mental model diagram

Link -> IP -> Route -> DNS

How it works (step-by-step, with invariants and failure modes)

  1. Interface is detected by the kernel.
  2. IP assigned via DHCP or static config.
  3. Default route is set.
  4. DNS resolvers are configured.

Invariants:

  • Interface name must match rc.conf.
  • Default route must be on the same subnet.

Failure modes:

  • Wrong interface name -> no IP.
  • Missing default route -> no Internet.
  • Missing resolv.conf -> no DNS.

Minimal concrete example

ifconfig em0
netstat -rn
cat /etc/resolv.conf

Common misconceptions

  • “If ping by hostname fails, networking is down.” -> It may be DNS only.
  • “Static IP is always safer.” -> It is safer only if you manage conflicts.

Check-your-understanding questions

  1. Which command shows your default route?
  2. What file defines DNS resolvers?
  3. Why must your static IP match the LAN subnet in bridged mode?

Check-your-understanding answers

  1. netstat -rn.
  2. /etc/resolv.conf.
  3. Because bridged mode puts the VM directly on the LAN.

Real-world applications

  • Static IP configuration for servers.
  • Diagnosing DNS outages quickly.

Where you’ll apply it

  • Section 3.2 Functional Requirements
  • Section 5.10 Phase 2
  • Also used in: P09 Jail Lab

References

  • “Absolute FreeBSD, 3rd Edition” (Ch. 7-8)
  • FreeBSD Handbook: Networking Basics

Key insights Networking is layered; test each layer independently.

Summary Correct IP, routes, and DNS are equally required for reliable networking.

Homework/Exercises to practice the concept

  1. Switch between DHCP and static IP twice.
  2. Break the default route and observe effects.
  3. Replace resolv.conf and test DNS.

Solutions to the homework/exercises

  1. DHCP picks an address; static requires rc.conf updates.
  2. Ping by IP fails without route.
  3. DNS fails until resolv.conf is restored.

Concept 2: NAT vs Bridged Modes in Virtual Networks

Fundamentals In a VM, the hypervisor defines the network mode. NAT provides outbound Internet access but hides the VM from the LAN. Bridged mode places the VM directly on the LAN with its own MAC address and IP. NAT is safer for initial installs; bridged is required for inbound access like SSH from another machine. You must understand the implications of each mode because the same FreeBSD configuration behaves differently depending on the hypervisor’s choice.

In practice, write a short checklist for NAT versus bridged networking and confirm it after each reboot. This keeps the concept concrete and prevents accidental drift between sessions.

Deep Dive into the concept NAT works by mapping the VM’s private IP to the host’s IP. This gives outbound connectivity but blocks inbound connections unless port forwarding is configured. This is why a VM in NAT mode can reach the Internet but cannot be reached from your laptop without explicit rules. Bridged mode attaches the VM to the same layer-2 network as the host. The VM appears as a separate device on the LAN, so it can receive inbound connections directly. The trade-off is that bridged mode depends on your LAN policies: some Wi-Fi networks block unknown MAC addresses, and some corporate networks require registration.

From the guest perspective, NAT and bridged look identical: you still configure an IP, gateway, and DNS. The difference is outside the guest: the path to the gateway and the ability for external hosts to reach the VM. This is why it is easy to misdiagnose connectivity issues; if you are in NAT mode but attempt inbound SSH, you will see timeouts even if FreeBSD is configured correctly. The correct fix is to switch to bridged or add port forwarding, not to change rc.conf.

In lab workflows, a common pattern is to install using NAT, then switch to bridged after you verify basic connectivity. This avoids LAN conflicts during install and ensures that your VM is safe from inbound access until you are ready. The key is to document when you switch modes and to update your tests accordingly. In NAT mode, your success criteria is outbound connectivity; in bridged mode, it includes inbound reachability.

Finally, different hypervisors implement NAT and bridging differently. VirtualBox and VMware expose slightly different device drivers, while UTM and QEMU may default to virtio devices. This can influence interface names in the guest (em0 vs vtnet0). The only reliable way to avoid confusion is to check ifconfig -a after each network mode change. When you do, you will see link status changes and possibly new interface names. Keep this in your lab notes to prevent future errors.

Operationally, NAT versus bridged networking is easiest to keep stable when you treat it as a small contract between configuration, tooling, and observable outputs. Write down the exact files that own the state and the commands that reveal the current truth. Then verify the contract at three points: immediately after you make the change, after a reboot, and after a deliberate disturbance such as restarting services or reloading modules. FreeBSD rewards this discipline because it rarely hides state; if something changes, it is usually in a file you control. Make a habit of collecting a before-and-after snapshot of commands and outputs so you can explain which change caused which effect.

At scale, NAT versus bridged networking is also about failure containment. Identify what must remain available when something breaks and design a safe escape hatch. For example, keep console access for firewall changes, keep a previous boot environment for upgrades, or keep a dataset snapshot before risky edits. The same pattern applies across domains: define invariants, define the rollback path, and then only proceed when you can trigger that rollback quickly. Finally, test the failure path while the system is healthy; you learn more from a controlled rollback than from an emergency. This perspective turns the lab exercise into an operational capability you can trust on production systems.

How this fits on projects

Definitions & key terms

  • NAT -> Outbound access, inbound blocked by default.
  • Bridged -> VM is a peer device on the LAN.
  • Port forwarding -> NAT rule that maps host ports to the VM.

Mental model diagram

NAT: VM -> Host -> Internet (inbound blocked)
Bridged: VM -> LAN -> Internet (inbound allowed)

How it works (step-by-step, with invariants and failure modes)

  1. Hypervisor sets VM NIC to NAT or bridged.
  2. Guest gets IP via DHCP or static config.
  3. Outbound connectivity is tested.
  4. Inbound connectivity is tested only in bridged mode.

Invariants:

  • NAT blocks inbound unless forwarding exists.
  • Bridged requires LAN policies to allow the VM.

Failure modes:

  • Bridged blocked by Wi-Fi security -> no inbound access.
  • Expecting inbound on NAT -> timeouts.

Minimal concrete example

ping -c 1 freebsd.org
ssh admin@192.168.1.50

Common misconceptions

  • “Bridged always works on Wi-Fi.” -> Many Wi-Fi networks block it.
  • “NAT is broken because SSH fails.” -> NAT blocks inbound by default.

Check-your-understanding questions

  1. Why can’t you SSH into a NAT VM from your LAN?
  2. When is bridged required?
  3. What is the most reliable way to identify your VM interface?

Check-your-understanding answers

  1. NAT does not map inbound traffic without forwarding.
  2. When you need inbound access from another host.
  3. Run ifconfig -a inside the VM.

Real-world applications

  • Isolated labs with NAT for safe testing.
  • Realistic server testing with bridged networking.

Where you’ll apply it

References

  • “Absolute FreeBSD, 3rd Edition” (Ch. 7-8)
  • Hypervisor documentation for networking modes

Key insights Hypervisor mode determines reachability; FreeBSD config determines addressing.

Summary Switching NAT and bridged changes reachability, not the guest configuration fundamentals.

Homework/Exercises to practice the concept

  1. Document IP changes when switching NAT -> bridged.
  2. Set up port forwarding and test SSH in NAT mode.
  3. Attempt bridged on Wi-Fi and note any restrictions.

Solutions to the homework/exercises

  1. NAT uses a private subnet, bridged uses LAN subnet.
  2. Port forwarding enables inbound access on NAT.
  3. Wi-Fi restrictions may block bridged mode.

3. Project Specification

3.1 What You Will Build

A FreeBSD VM that can reliably switch between NAT and bridged networking, uses DHCP and static configurations, and resolves DNS correctly in each mode. You will document the interface name, IP plan, and test results.

3.2 Functional Requirements

  1. Interface identified: correct NIC name documented.
  2. DHCP configuration works in NAT mode.
  3. Static IP configuration works in bridged mode.
  4. DNS resolution works in both modes.
  5. Inbound SSH works in bridged mode.

3.3 Non-Functional Requirements

  • Performance: Network changes take effect within 30 seconds.
  • Reliability: Reboot preserves the chosen network mode configuration.
  • Usability: Documentation includes IP plan and interface name.

3.4 Example Usage / Output

$ ifconfig em0 | grep inet
inet 192.168.1.50 netmask 0xffffff00 broadcast 192.168.1.255

$ ping -c 1 freebsd.org
1 packets transmitted, 1 packets received

3.5 Data Formats / Schemas / Protocols

  • rc.conf DHCP 
    ifconfig_em0="DHCP"
  • rc.conf Static 
    ifconfig_em0="inet 192.168.1.50/24"
defaultrouter="192.168.1.1"
  • resolv.conf 
    search local
nameserver 192.168.1.1

3.6 Edge Cases

  • LAN DHCP assigns a different IP than expected.
  • Bridged mode blocked by Wi-Fi policy.
  • DNS server unreachable while routing works.

3.7 Real World Outcome

A VM that can be reached from your LAN when bridged, and a predictable outbound-only profile when NATed.

3.7.1 How to Run (Copy/Paste)

ifconfig -a
sysrc ifconfig_em0="DHCP"
service netif restart
ping -c 1 freebsd.org

3.7.2 Golden Path Demo (Deterministic)

  • Use TZ=UTC for stable timestamps.
  • Use a known LAN IP range for static configuration.

3.7.3 If CLI: provide an exact terminal transcript

$ TZ=UTC ifconfig em0 | grep inet
inet 192.168.1.50 netmask 0xffffff00 broadcast 192.168.1.255

$ TZ=UTC ping -c 1 freebsd.org
PING freebsd.org (96.47.72.84): 56 data bytes
64 bytes from 96.47.72.84: icmp_seq=0 ttl=49 time=30.1 ms

$ echo $?
0

Failure demo (deterministic)

$ TZ=UTC drill freebsd.org
;; connection timed out; no servers could be reached

$ echo $?
1

4. Solution Architecture

4.1 High-Level Design

Hypervisor mode -> Interface config -> Routes -> DNS -> Validation

4.2 Key Components

Component Responsibility Key Decisions
Hypervisor NIC mode Reachability NAT vs bridged
rc.conf network Persistent config DHCP vs static
DNS config Name resolution DHCP vs manual

4.3 Data Structures (No Full Code)

NetworkProfile
- mode: NAT|Bridged
- iface: "em0"
- ip: "192.168.1.50"
- gateway: "192.168.1.1"
- dns: ["192.168.1.1"]

4.4 Algorithm Overview

Key Algorithm: Network Mode Switch

  1. Change hypervisor NIC mode.
  2. Update rc.conf for DHCP or static.
  3. Restart netif and routing.
  4. Test DNS and reachability.

Complexity Analysis:

  • Time: O(restart + DHCP)
  • Space: O(config files)

5. Implementation Guide

5.1 Development Environment Setup

# Ensure console access in case of network misconfig

5.2 Project Structure

network-lab/
+-- rc.conf.dhcp
+-- rc.conf.static
+-- test-results.md

5.3 The Core Question You’re Answering

“Can I reliably control FreeBSD networking in a VM?”

5.4 Concepts You Must Understand First

Stop and research these before coding:

  1. IP configuration and routing
  2. NAT vs bridged networking

5.5 Questions to Guide Your Design

  1. What is your VM interface name?
  2. Which static IP will you use on the LAN?
  3. How will you verify DNS without relying on a browser?

5.6 Thinking Exercise

DNS Failure Drill

Break DNS resolution and trace the fix without rebooting.

5.7 The Interview Questions They’ll Ask

  1. How do you set a static IP in FreeBSD?
  2. What is the role of resolv.conf?
  3. Why does NAT block inbound access?
  4. How do you restart networking?
  5. What is ifconfig used for?

5.8 Hints in Layers

Hint 1: Use DHCP first Get a working baseline before going static.

Hint 2: Separate layers Ping the gateway before testing DNS.

Hint 3: Keep two rc.conf snippets One for DHCP, one for static.

Hint 4: Document outputs Record ifconfig and netstat -rn outputs.

5.9 Books That Will Help

Topic Book Chapter
Networking “Absolute FreeBSD, 3rd Edition” Ch. 7-8

5.10 Implementation Phases

Phase 1: DHCP Baseline (2-3 hours)

Goals: Confirm NAT connectivity. Tasks:

  1. Enable DHCP in rc.conf.
  2. Verify IP and DNS. Checkpoint: ping and drill succeed.

Phase 2: Static Bridged (3-4 hours)

Goals: Enable bridged access. Tasks:

  1. Switch to bridged mode.
  2. Apply static IP and gateway. Checkpoint: another host pings the VM.

Phase 3: Troubleshooting Drill (2-3 hours)

Goals: Diagnose failures. Tasks:

  1. Break DNS and recover.
  2. Break route and recover. Checkpoint: documented fix steps.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Mode order NAT first, bridged first NAT first Safer initial setup
IP config DHCP, static Both Practice both workflows
DNS source DHCP, manual DHCP first Simpler baseline

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Interface Tests Verify NIC ifconfig -a
Routing Tests Default gateway netstat -rn
DNS Tests Resolver works drill freebsd.org

6.2 Critical Test Cases

  1. DHCP success: IP assigned and route set.
  2. Static success: correct IP persists after reboot.
  3. DNS success: hostname resolves in both modes.

6.3 Test Data

Hostnames: freebsd.org
Static IP: 192.168.1.50/24
Gateway: 192.168.1.1

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Wrong interface No IP Use ifconfig -a
Missing gateway No outbound access Set defaultrouter
DNS overwritten by DHCP Names fail Lock resolv.conf or configure DHCP

7.2 Debugging Strategies

  • Layered checks: link -> IP -> route -> DNS.
  • Console safety: keep console open for recovery.

7.3 Performance Traps

  • Bridged on Wi-Fi can add latency or block traffic.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add a second static IP alias.
  • Test IPv6 DHCP on your LAN.

8.2 Intermediate Extensions

  • Configure port forwarding for NAT SSH.
  • Set a dedicated DNS resolver inside the VM.

8.3 Advanced Extensions

  • Build a small DHCP server inside the VM for lab testing.
  • Capture traffic with tcpdump and interpret it.

9. Real-World Connections

9.1 Industry Applications

  • Server provisioning: static IPs and DNS configuration.
  • Incident response: quick root-cause isolation of network outages.
  • dhclient: DHCP client.
  • pf: firewall often paired with network config.

9.3 Interview Relevance

  • Practical networking troubleshooting steps.
  • Understanding NAT vs bridged environments.

10. Resources

10.1 Essential Reading

  • “Absolute FreeBSD, 3rd Edition” by Michael W. Lucas - Ch. 7-8
  • FreeBSD Handbook - Networking

10.2 Video Resources

  • “FreeBSD Networking Basics” - community training

10.3 Tools & Documentation

  • ifconfig(8): interface configuration manual
  • netstat(1): routing table inspection

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain DHCP vs static configuration.
  • I can explain NAT vs bridged behavior.
  • I can isolate DNS failures.

11.2 Implementation

  • NAT mode tested with DHCP.
  • Bridged mode tested with static IP.
  • DNS resolution verified.

11.3 Growth

  • I documented a troubleshooting checklist.
  • I can repeat the config from notes.
  • I can teach this workflow to someone else.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • DHCP works in NAT mode.
  • Static IP works in bridged mode.
  • DNS resolution succeeds in both modes.

Full Completion:

  • Inbound SSH reachable in bridged mode.
  • Troubleshooting checklist completed.

Excellence (Going Above & Beyond):

  • Port forwarding configured for NAT access.
  • IPv6 tested and documented.