Lab 4 — Firewall, VLANs & VPN

Goal: build a genuinely segmented network, put a firewall in front of it, configure a VPN, and then break it. Time: ~3 hours.

Part 1 — Add a second network segment

In Hyper-V, create an internal switch for a separate VLAN:

New-VMSwitch -Name "InternalSegment" -SwitchType Internal

Attach FW01 (pfSense) to both switches:

Connect-VMNetworkAdapter -VMName "FW01" -SwitchName "External"
Add-VMNetworkAdapter -VMName "FW01" -SwitchName "InternalSegment"

pfSense needs two interfaces. Install pfSense and assign:

Interface	Hyper-V switch	Address
WAN	External	DHCP or your real LAN
LAN	InternalSegment	192.168.10.1/24

Your DC and servers stay on the internal segment.

Part 2 — Add a second VLAN

pfSense → Interfaces → Other Types → VLAN, parent LAN, tag 20, address 192.168.20.1/24.

Create a new Hyper-V switch for it and attach a client VM:

New-VMSwitch -Name "VLAN20" -SwitchType Internal
Add-VMNetworkAdapter -VMName "CLI02" -SwitchName "VLAN20"

Tag the pfSense vNIC for VLAN 20, then on the switch set the access port to VLAN 20 with the correct PVID.

★In practice

If you do not have managed switches, use Cisco Packet Tracer or GNS3 for the VLAN exercise — they are free, and they teach the switch commands that a physical lab cannot easily show you. Practice show vlan brief.

Part 3 — Firewall rules

Start with deny by default, then permit what you need.

Block VLAN20 → LAN (all)
Block VLAN20 → LAN 445, 3389   (implied by the above)
Allow LAN → VLAN20 443
Allow LAN → WAN 443, 80
Allow VLAN20 → DNS 53 to the DC

✖The support lesson

A user in VLAN 20 can ping nothing in VLAN 10. Before touching their machine, check whether a firewall rule is deliberately denying it — "I can't reach the file server" may be the network working exactly as designed.

Part 4 — Prove segmentation works

# From VLAN20 client
ping 192.168.10.10       # fails — blocked by design
Resolve-DnsName dc01.corp.local   # works — DNS allowed
Test-NetConnection 192.168.10.10 -Port 445   # times out, not refused

◆Refused vs timed out, again

Refused means something answered. Timed out means a packet was dropped — almost always a firewall. You will be asked to make this distinction.

Part 5 — Configure a VPN

Install WireGuard on pfSense, or use OpenVPN. Give it a tunnel network:

VPN clients: 10.10.0.0/24

Firewall rules for the tunnel interface:

Allow VPN → LAN : any        (or narrow it)
Allow LAN → VPN : 445, 3389

Then, from a client, connect and confirm:

ipconfig                        # see the tunnel adapter
Test-NetConnection 192.168.10.10 -Port 445
ping 192.168.10.10

★Break this deliberately

Add a tunnel network that overlaps your LAN — 192.168.10.0/24 instead of 10.10.0.0/24 — and reconnect. Traffic to your servers now has two possible paths and picks the wrong one. This is a genuine, common misconfiguration and it is why VPN address planning is a real support skill.

Part 6 — Break the DHCP relay path

# On the DC, restrict the DHCP server to the LAN interface only
Get-DhcpServerv4Scope -ScopeId 192.168.10.0 |
  Select-Object Name, InterfaceAlias, State

Detach the VLAN 20 interface from pfSense, then try to renew on the VLAN 20 client. It gets 169.254.x.x.

✖What you just proved

One floor has DHCP failure but full layer-3 connectivity. That points at the relay or the scope interface — not at the client, not at the switch. This is the reasoning behind "works on Wi-Fi but not on the LAN".

Part 7 — Read the firewall logs

# pfSense: Status → System Logs → Firewall

You will see the actual deny. This is how you answer "the firewall is blocking my application" without guessing — read the rule that matched.

Verification

☑Lab 4 verification

0 / 7 complete

• Two network segments created and genuinely isolated
• A VLAN created with a distinct subnet and gateway
• Default-deny firewall rules written and verified by a blocked ping
• VPN server configured and a client connected through it
• Reproduced an overlapping VPN subnet fault
• Reproduced a DHCP failure isolated to one VLAN
• Can read a firewall log and name the rule that matched

Hints

Details

pfSense has no WAN address

The Hyper-V switch is not passing traffic. Check Get-VMNetworkAdapter -VMName FW01 | Select-Object SwitchName and confirm the External switch points at your real NIC.

Details

Client can ping but not resolve

UDP 53 is not permitted from that VLAN. Add the rule and re-test — that is precisely the layered diagnosis you would perform in a real incident.

Solution

Show the diagnostic chain

For "one floor lost the network but the server is reachable":

# 1. Layer 1-2 — is the switch port up and in the right VLAN?
#    (switch CLI)
show interfaces status
show vlan brief

# 2. Layer 3 — do they have an address?
ipconfig /all

# 3. If 169.254.x.x, DHCP is the problem, not connectivity
Get-DhcpServerv4LeaseStatistics -ScopeId 192.168.10.0
# On the DC: is the scope bound to the right interface?
Get-DhcpServerv4Scope -ScopeId 192.168.10.0

# 4. Is a firewall dropping the DHCP relay?
#    pfSense → Status → System Logs → Firewall

That chain — port, address, DHCP, firewall — is the answer, and you have now built every layer of it.

Next

Lab 5 — Troubleshooting Drill.