Penetration Test Your Home Network

Scan, segment, and lock down your home network using Kali Linux and Nmap.

Introduction

30 Second Summary

You changed your passwords, disabled remote management, and locked down your router. But how do you actually know it worked?

In this project, you will use Kali Linux to run professional-grade penetration tests against your own home network. You will prove exactly which doors are locked and which ones you missed.

What You'll Build

Imagine showing an employer a real scan report of a network you hardened yourself, with proof that your defenses blocked the same attacks a professional pen tester would run.

By the end of this project, you'll have:

A live Nmap port scan proving your router's attack surface is reduced, with ports confirmed as closed or filtered.
A working guest network that provably blocks devices from reaching your main machine (a ping test that fails between segments).
MAC address filtering that rejects unauthorized devices even if they know your Wi-Fi password.
Secret Mission: Deploy a DNS sinkhole with NextDNS to monitor every domain your devices secretly contact.

Are there any prerequisites?

This project assumes you have already completed a home network hardening project (secured your router, changed default passwords, disabled remote management). You also need a Kali Linux VM running in Oracle VirtualBox, admin access to your router and extender, and a secondary device like a phone for testing.

Before We Start

Before We Start...

Before we fire up any scanning tools, let's lock in exactly what you're about to test and why it matters.

Set Up Your Attack Machine

Your Kali Linux VM is currently walled off from your home network. VirtualBox's default NAT mode lets Kali reach the internet, but hides it behind your host's IP address. Your router and extender have no idea the VM exists.

To act as an attacker on your LAN, Kali needs its own IP address on your home subnet. In this step, you'll switch VirtualBox to bridged networking so your router sees Kali as a real device sitting directly on the network.

In this step, get ready to:

Reconfigure VirtualBox to bridge Kali onto your home LAN.
Verify Kali can reach your router over the network.
Note your router gateway IP and Windows machine IP for scanning later.

Configure VirtualBox bridged networking

VirtualBox's NAT adapter gives Kali internet access by sharing your Windows host's connection. Devices on your LAN cannot see or reach the VM through NAT. Switching to a Bridged Adapter connects Kali directly to your physical network, so your router assigns it its own IP.

Shut down your Kali VM if it is currently running.
In VirtualBox Manager, right-click your Kali VM and select Settings.
Click Network in the left panel.
In the Attached to dropdown for Adapter 1, select Bridged Adapter.
In the Name dropdown below it, select your Windows host's network interface (your Wi-Fi adapter or Ethernet adapter).
Click OK to save the changes.

How do I know which interface to pick?

Look for the adapter name that matches how your Windows machine connects to the internet. If you use Wi-Fi, it will be something like "Intel Wi-Fi 6" or "Wireless Network Adapter". If you use a cable, it will be your Ethernet adapter.

Pick the one that is currently active and connected to your home network.

Boot Kali and verify LAN connectivity

With bridged mode configured, Kali should receive its own IP from your router via DHCP when it boots.

Start your Kali VM in VirtualBox.
Once Kali boots to the desktop, open a terminal (right-click the desktop and select Open Terminal Here, or click the terminal icon in the taskbar).
Check your network interface and IP address by running this command:

ip addr show eth0

What should I see?

You should see an inet line showing an IP in your home subnet, something like 192.168.x.x/24. This confirms your router assigned Kali its own address on the LAN.

No IP address showing?

If you see no inet line under eth0, Kali did not receive an IP automatically. Request one manually by running sudo dhclient eth0 then check again with ip addr show eth0.

If your interface is named something other than eth0 (like enp0s3), run ip addr with no arguments to see all interfaces. Use whichever name shows your network adapter in subsequent commands.

If bridging over Wi-Fi fails entirely, try regenerating the VM's MAC address in VirtualBox network settings or temporarily connecting your Windows host via Ethernet cable. Wi-Fi bridging has known limitations in VirtualBox.

Help me troubleshoot why my Kali VM is not getting an IP address with bridged networking in VirtualBox.

Now confirm Kali can actually communicate with your router. Before you run the next command, think about what you expect to see. If bridged mode is working, will the ping succeed or fail?

Ping your router's gateway IP by running this command:

ping -c 3 [[GATEWAY_IP="your router gateway IP (e.g. 192.168.254.254)"]]

You should see three replies with response times in milliseconds. This proves Kali is on your LAN and can reach your router directly.

Seeing 'Destination Host Unreachable'?

Double-check the IP address matches your actual router gateway. Make sure you replaced the placeholder with the IP you use to access your router admin panel (the same one from your hardening project).

If the IP is correct but pings still fail, go back to VirtualBox settings and confirm you selected the correct host network interface in the Name dropdown.

Why is my Kali VM unable to ping my router even though bridged mode is configured?

Note your target IPs from Windows

You now know Kali can reach your network. Next, formally note down the IPs you will scan from Kali in the upcoming steps.

Switch to your Windows host machine.
Press the Windows key, type cmd, and press Enter to open Command Prompt.
View your network details by running this command:

ipconfig

What should I look for?

Find the section for your active adapter (Wi-Fi or Ethernet). Note two values:

Default Gateway is your router's IP (e.g. 192.168.254.254 or 192.168.1.1). This is the first target you will scan.
IPv4 Address is your Windows machine's IP on the LAN. You will use this later to test network segmentation.

Write down both the Default Gateway IP and your Windows IPv4 Address. You will need them in the next steps.

Keep a notes file open

Open a text file on your desktop or a note-taking app. Paste in both IPs now. You will collect scan results and comparison notes throughout this project, and having them in one place makes your final report easier to assemble.

Your attack machine is live on the network. Next up, you'll use Nmap to discover every device on your LAN and scan your router for open ports.

Run Your First Network Scan

Your Kali VM is now sitting on your home network like an attacker with a foothold on the LAN. Before you can tell whether your previous hardening actually closed anything, you need hard evidence.

A port scan answers the question: what is actually exposed on your router right now? In this step, you will discover every device on your network and probe your router's ports to see which are open, closed, or filtered.

In this step, get ready to:

Discover all live devices on your home subnet.
Scan your router for open ports and running services.
Save the scan results to a portfolio-ready report file.

Discover all live devices on your subnet

Before targeting your router specifically, you need to know what else is on the network. A host discovery scan pings every IP in your subnet and reports which ones respond.

Run a host discovery scan against your entire subnet by running this command:

sudo nmap -sn [[SUBNET="your subnet, e.g. 192.168.254.0/24"]]

What does this command do?

`sudo` gives Nmap root privileges so it can send raw packets.
`-sn` tells Nmap to do host discovery only, with no port scan. It sends ICMP echo requests and TCP pings to find live hosts.
The `/24` suffix means "scan all 256 addresses in this subnet" (e.g. 192.168.254.0 through 192.168.254.255).

Nmap prints a line for each live device it finds, ending with a summary like Nmap done: 256 IP addresses (X hosts up).

Note the number of hosts that are up and their IP addresses.
Look for your router gateway IP, your Windows machine IP, and any other devices (phones, smart home gadgets, extenders) in the list.

Seeing 0 hosts up?

Double check that your subnet matches what you see in Kali's IP address. If your Kali IP is 192.168.254.105, your subnet is 192.168.254.0/24.
Confirm that bridged networking is still active. Run ip addr show eth0 and verify you have a LAN IP.
Some routers block ICMP. If you confirmed your IP is correct but hosts show as down, try sudo nmap -sn -PS 192.168.x.0/24 to use TCP SYN pings instead.

help me troubleshoot my Nmap host discovery scan returning 0 hosts up on my home network

Scan your router's ports and services

Now that you know which devices are alive, it is time to probe your router directly. A SYN stealth scan sends half-open TCP connections to the 1,000 most common ports and records which ones respond.

Before you run this, think: based on your previous hardening (disabling remote management, closing unnecessary services), do you expect ports 22 (SSH) and 23 (Telnet) to show as open or closed?

Run a SYN stealth scan with version detection against your router by running this command:

sudo nmap -sS -sV -T4 [[ROUTER_GATEWAY_IP="your router gateway IP, e.g. 192.168.254.254"]]

What do these flags mean?

`-sS` performs a TCP SYN stealth scan. It sends a SYN packet and reads the response without completing the handshake, making it harder for the target to log the connection.
`-sV` enables service and version detection. Nmap probes open ports to identify what software is running behind them.
`-T4` sets aggressive timing. On a fast LAN like yours, this speeds up the scan without losing accuracy.

Nmap scans the 1,000 most popular ports by default. The scan typically completes in under 30 seconds on a LAN, though version detection may extend it to 1-2 minutes.

Nmap displays a port table showing each port's state: open (a service is listening), closed (nothing listening but reachable), or filtered (a firewall is blocking the probe).

Look at the port table and find ports 22, 23, 80, and 443.
If your hardening worked, ports 22 (SSH) and 23 (Telnet) should show as closed or filtered. Port 80 or 443 may still be open for the router's local admin panel.

Scan seems to hang or takes very long?

Version detection on filtered ports can take time while Nmap waits for timeouts. Wait up to 2 minutes before cancelling.
If it exceeds 5 minutes, press Ctrl+C to cancel, then re-run without -sV to skip version detection and get the port states faster.

help me figure out why my Nmap SYN scan against my router is taking a very long time

Save the scan results to a file

You have seen the results in your terminal, but you need a saved copy for documentation and comparison in the next step. The -oN flag writes Nmap's normal output to a file.

Re-run the same scan and save it to a file by running this command:

sudo nmap -sS -sV -T4 -oN router-scan.txt [[ROUTER_GATEWAY_IP="your router gateway IP, e.g. 192.168.254.254"]]

Why re-run the scan?

The -oN flag saves output to a file in normal human-readable format. Nmap includes a comment header with the command, start time, and version, making it a self-documenting report. You need this file for the side-by-side comparison with your extender scan in the next step.

The scan runs identically to before. Once it finishes, verify the file was created.

Open the saved report by running:

cat router-scan.txt

You should see the full Nmap report including the port table, version info, and a closing summary line showing how many hosts were scanned.

File is empty or missing?

Make sure you included -oN router-scan.txt before the target IP in the command, not after it.
Check your current directory with pwd and list files with ls to confirm the file exists.
If the scan was interrupted (Ctrl+C), the file may be incomplete. Re-run the full command and let it finish.

help me troubleshoot why my Nmap scan did not save to router-scan.txt

You now have a documented port scan proving which services your router exposes. Ports 22 and 23 should be closed or filtered if your hardening is working. Next up, you will scan your extender and compare it against this baseline to find the weaker link.

Scan Your Extender and Find the Gap

Your router scan from the last step might show a locked-down port table. That is great news for your hardening work.

But your Xiaomi extender is a completely separate device with its own firmware and its own open ports. If it exposes services your router does not, that is a security gap your hardening missed entirely.

In this step, get ready to:

Scan your Xiaomi extender for open ports and running services.
Compare the extender results against your router scan to identify differences.
Run vulnerability detection scripts to assess the extender's risk level.

Scan your Xiaomi extender's ports and services

Your host discovery scan from Step 2 revealed the IP address of every live device on your subnet, including the Xiaomi extender. Now you will point the same SYN stealth scan at the extender to see what it exposes.

Run a SYN stealth scan with version detection against your extender and save the results by running this command:

sudo nmap -sS -sV -T4 -oN extender-scan.txt [[EXTENDER_IP="your extender IP from the discovery scan"]]

What does this command do?

This is the same scan type you ran against your router in Step 2.

-sS performs a TCP SYN stealth scan that does not complete the full handshake.
-sV probes open ports to identify what service and version is running.
-oN extender-scan.txt saves the results in normal output format so you can compare later.

Wait for the scan to complete. This typically takes 1-2 minutes with version detection enabled.
Confirm the results saved by running:

cat extender-scan.txt

You should see a port table listing each scanned port's state (open, closed, or filtered) and detected service versions for the extender.

Scan shows "Host seems down"?

Double-check the extender IP from your host discovery scan in Step 2. Run sudo nmap -sn 192.168.x.0/24 again to confirm it is still online.
Make sure your Kali VM is still connected to the same subnet as the extender. Run ip addr show eth0 to verify your IP is in the same range.

Why is my Nmap scan reporting the extender as down even though it is connected to the network?

Compare the router and extender scans

You now have two scan reports on disk. The real insight comes from comparing them side by side to see which device exposes more services to the network.

Compare the two scan files by running:

diff router-scan.txt extender-scan.txt

The output highlights lines that differ between the two files. Look at the port table sections specifically.

What should I look for in the diff?

Focus on ports that show as open on the extender but closed or filtered on the router. The extender will likely have port 80 open for its web admin panel.

Every open port is a potential entry point. If your router locked down port 80 but your extender still exposes it, an attacker on your LAN could target the extender instead.

Note which device exposes more open ports. Write down the specific differences you see between the two port tables.

If diff output is hard to read

You can also open both files manually and compare the port tables visually. Run cat router-scan.txt in one terminal and cat extender-scan.txt in another. Look at the "PORT" column and compare states line by line.

Run a vulnerability scan against the extender

Knowing which ports are open tells you the attack surface. But Nmap can go further by running vulnerability detection scripts against those open services to check for known security issues.

Run the NSE vulnerability scripts against your extender by running this command:

sudo nmap -sV --script vuln [[EXTENDER_IP="your extender IP from the discovery scan"]]

What does --script vuln do?

The --script vuln flag tells Nmap to run its NSE (Nmap Scripting Engine) vulnerability detection scripts against open ports. These scripts check for known CVEs and common misconfigurations.

This scan takes longer than a basic port scan. Expect 3-5 minutes depending on how many open ports the extender has.

Wait for the vulnerability scan to complete. Review the output carefully for any lines marked as VULNERABLE or flagged CVE numbers.

Before you review your findings, think about this: based on what you saw in the port comparison, do you expect the vulnerability scan to find issues on the extender?

The vulnerability scan output lists each open port followed by any detected issues. Even if no specific CVEs are flagged, the fact that the extender has open ports your router does not proves it is the weaker link in your network.

Why does this matter?

This is your "before" evidence. You have now documented that the extender is the weakest point in your network. A compromised device on the same network segment could target these open services to move laterally toward your main machine.

The next step addresses this by segmenting your network so that even if the extender is compromised, the attacker cannot reach your primary machine.

Vulnerability scan hanging or taking too long?

The --script vuln scan can take 3-5 minutes per host. If it exceeds 10 minutes, press Ctrl+C to cancel and try with fewer scripts. The port scan results from extender-scan.txt already demonstrate the security gap.
If you see "No results" for all ports, the extender may be rate-limiting scan requests. Wait a minute and try again.

Why is my Nmap vulnerability scan taking so long or returning no results against my extender?

You have now documented the security gap in your network. The extender is the weaker point, exposing services your hardened router does not. Next up, you will fix this gap by segmenting your network so devices on one side cannot reach your main machine.

Segment Your Network

Your Nmap scans proved that the Xiaomi extender exposes more services than your hardened router. That gap confirmed the extender is the weakest point on your network.

The deeper problem is that every device sharing the same network segment can freely communicate with every other device. A compromised extender or IoT gadget could reach your Windows machine directly because nothing separates them at the network level.

In this step, get ready to:

Enable a guest network on your Globe router with AP Isolation.
Connect your phone to the guest network while keeping your Windows machine on the primary network.
Verify segmentation by pinging your Windows machine from the guest network and confirming it fails.

Enable the guest network on your Globe router

Your Globe router can broadcast a separate Wi-Fi network (a guest SSID) that is logically isolated from your primary network. Devices connected to this guest network will be unable to communicate with devices on your main network.

On your Windows machine, open a browser.
Navigate to your Globe router admin panel by entering its gateway IP in the address bar (typically 192.168.254.254 or 192.168.1.1).
Log in with your router admin credentials.
Navigate to the Wireless or Guest Network settings section.
Enable the Guest Network toggle (or create a new SSID if the option says "Add Network").
Give the guest network a recognizable name like Home-Guest so you can identify it on your phone.
Set a password for the guest network.
Look for an option labelled AP Isolation, Client Isolation, or Access Intranet (set to Disable). Enable isolation so guest devices cannot reach the main network.
Click Save or Apply to commit the changes.

What is network segmentation?

Network segmentation splits a single physical network into separate logical zones. Devices in one zone cannot send traffic to devices in another zone.

AP Isolation enforces this at the router level. Even though the guest network uses the same physical router hardware, the router drops any packets that try to cross from guest to primary. Think of it like a hotel hallway where each room's Wi-Fi cannot see any other room.

Router UI varies by model

Globe provides several router models with different admin interfaces. The exact labels for Guest Network and AP Isolation may differ on your router. Look in Wireless, WLAN, or Network sections if you do not see them immediately.

After saving, wait about 10 seconds for the router to apply the settings. The new guest SSID should now appear in your phone's available Wi-Fi list.

Connect your phone to the guest network

On your phone, open Settings and navigate to Wi-Fi.
Find the guest network SSID you just created (e.g. Home-Guest) in the available networks list.
Tap on it and enter the password you set.
Confirm your phone is connected to the guest network (you should see the SSID name under your Wi-Fi settings).

Your Windows machine should remain connected to the primary (main) network. You now have two devices on two separate network segments.

Verify segmentation with a ping test

The real proof of segmentation is whether a device on the guest network can reach a device on the primary network. You will ping your Windows machine's IP from your phone.

On your phone, download a free ping app from your app store. On Android, search for "Ping & Net" or "Termux". On iPhone, search for "Ping" or "iNetTools".
Open the ping app.
Enter your Windows machine's IP address (the one you noted from ipconfig earlier in Step 1).

Before you run the ping, what do you think will happen? Will the packets reach your Windows machine, or will they be blocked?

Run the ping test.

The ping should fail. You will see "Request timed out" or "Destination unreachable" messages with 100% packet loss. This proves that your guest network is fully isolated from your primary network.

What does a failed ping prove?

A failed ping means the router is actively dropping traffic between the two network segments. Even though both devices are connected to the same physical router, the AP Isolation setting prevents any cross-segment communication.

This is exactly what an attacker would experience. If a compromised IoT device is on the guest network, it cannot reach your primary machine no matter what it tries.

Ping succeeding when it should fail?

If the ping returns replies instead of timing out, check these common causes:

Verify your phone is actually connected to the guest SSID, not the primary network. Check the network name in your Wi-Fi settings.
Confirm that AP Isolation or Client Isolation is enabled in the router's guest network settings. Some routers have a separate "Allow access to local network" toggle that must be disabled.
Some routers require a reboot after changing isolation settings. Try restarting the router and reconnecting.

Still getting replies? Help me troubleshoot why my guest network can still reach my primary network.

Your network is now segmented. Guest and IoT devices are locked into their own zone with no path to your primary machine. Next up, you will add another layer of defense by enforcing MAC address filtering so only whitelisted devices can connect to your main network in the first place.

Enforce MAC Address Filtering

Your guest network segmentation blocks lateral movement between devices on different SSIDs. But there is still a gap: if an attacker cracks your primary Wi-Fi password, they can join your main network and access everything on it.

MAC address filtering adds a Layer 2 barrier to close this gap. Only devices whose hardware addresses you explicitly whitelist can connect, even with the correct password. In this step, you will set up and prove that this filter works.

In this step, get ready to:

Record the MAC addresses of your Windows PC and phone.
Configure MAC address whitelist filtering on your Globe router.
Prove the filter works by blocking and unblocking your phone.

Find your devices' MAC addresses

Every network interface has a unique hardware identifier called a MAC address. You need the MAC addresses of every device you want to allow on your primary network before you can build the whitelist.

On your Windows machine, open Command Prompt and run this command to display your full network adapter details:

ipconfig /all

Scroll through the output and find the adapter you use to connect to your primary Wi-Fi (look for Wireless LAN adapter Wi-Fi or similar).
Note the value next to Physical Address. It looks like A4-B1-C2-3D-4E-5F. Write this down. This is your Windows PC's MAC address.

What is a Physical Address?

Windows calls the MAC address a "Physical Address" because it is burned into the network adapter's hardware at the factory. Unlike your IP address (which changes depending on which network you join), the MAC address stays the same.

Now find your phone's MAC address using the instructions for your device type below.

Android

Open your phone's Settings app.
Tap About Phone (or About Device).
Tap Status or Hardware Information.
Find and note the Wi-Fi MAC address. Write it down.

Randomized MAC addresses

Android 10+ uses randomized MAC addresses per network by default. The address shown in About Phone is your true hardware MAC. If your router rejects it, go to your Wi-Fi network settings, tap the gear icon next to your connected network, and set the privacy option to use the device MAC instead of a randomized one.

iPhone

Open Settings.
Tap General, then About.
Find and note the Wi-Fi Address. This is your iPhone's hardware MAC address. Write it down.

Private Wi-Fi Address on iPhone

iOS uses a private (randomized) MAC for each network by default. For MAC filtering to work reliably, go to Settings, then Wi-Fi, tap the info icon next to your network, and turn off Private Wi-Fi Address. This makes your phone present its true hardware MAC to the router.

You should now have two MAC addresses written down: one for your Windows PC and one for your phone.

Configure the MAC address whitelist on your router

With both MAC addresses in hand, you can now tell your router to reject any device that is not on your approved list.

Switch back to the Globe router admin panel in your browser.
Navigate to MAC Filtering or Access Control settings. This is usually found under the Wireless or Security section (the exact location varies by Globe router model).
Set the filtering mode to Whitelist (sometimes labelled Allow List). This means only devices you add will be permitted to connect.
Add your Windows PC's MAC address to the allowed list.
Add your phone's MAC address to the allowed list.
Click Save or Apply to activate the filter.

What does Whitelist mode do?

In Whitelist mode, the router maintains an explicit list of approved MAC addresses. Any device whose MAC is not on the list gets rejected at connection time, even if it sends the correct Wi-Fi password.

This is the opposite of Blacklist mode, which blocks specific devices and allows everyone else.

Your router's MAC Filtering page should now show both MAC addresses in the allowed list with the filter set to Whitelist mode.

Can't find MAC Filtering settings?

Globe routers vary by model. Try looking under Wireless > Advanced, Security > Access Control, or Network > Wireless MAC Filter. Some models place it under a Firewall section.

If your router's UI labels the feature differently, look for any setting that mentions "MAC", "Access Control", or "Allow/Deny list".

Help me find the MAC filtering settings on my Globe router.

Test the filter by blocking your phone

A security control you have not tested is a control you cannot trust. You will now deliberately remove your phone from the whitelist and prove that the router actually rejects it.

In the MAC Filtering page, remove your phone's MAC address from the whitelist (or uncheck it).
Click Save or Apply.
On your phone, disconnect from the primary Wi-Fi network (forget the network or toggle Wi-Fi off and on).

Before you try to reconnect, think about what you expect to happen. Your phone has the correct Wi-Fi password. Will it connect successfully, or will the router reject it?

On your phone, attempt to reconnect to the primary Wi-Fi using the correct password.

Your phone should fail to connect or receive no IP address, even though the password is correct. The router rejected the connection because your phone's MAC is no longer on the approved list. This is your proof that MAC filtering is working.

Why does this matter?

You just proved that knowing the Wi-Fi password alone is not enough to join your network. An attacker who somehow obtains your password would still be blocked at the MAC layer unless they also spoof an approved device's MAC address.

Now re-add your phone's MAC address to the whitelist in the router admin panel.
Click Save or Apply.
On your phone, try connecting to the primary Wi-Fi again. It should connect successfully this time.

Your phone is back online. You have confirmed that MAC filtering blocks unauthorized devices and that restoring the whitelist entry brings a device back.

Phone still connects after being removed?

Some routers cache existing connections. Make sure you fully disconnected your phone (forget the network, not just toggle Wi-Fi) before attempting to reconnect. Also confirm you clicked Save/Apply after removing the MAC entry.

If your phone uses a randomized MAC address, the address it presents to the router may differ from the one you removed. Check the tip in the earlier platform tabs about disabling private/randomized MAC for your network.

Help me troubleshoot why my phone still connects after MAC filtering.

Extra for Experts: Can MAC filtering be bypassed?

Yes. An attacker can sniff traffic to discover approved MAC addresses and then use a tool like macchanger on Kali to spoof one. MAC filtering is a "speed bump" in defense-in-depth. It stops casual intruders but not a determined attacker.

Combined with WPA3, network segmentation, and strong passwords, it forces an attacker to clear multiple hurdles instead of just one.

Your home network now has three layers of defense you have personally tested: closed ports on your router, segmented traffic between guest and primary devices, and MAC address filtering that rejects unknown hardware. That is a real penetration testing report backed by evidence.

Ready for one more challenge? In the Secret Mission, you will deploy a DNS sinkhole that lets you watch every domain your devices secretly contact in real time.

Secret mission

Deploy a DNS Sinkhole with NextDNS

Your network is scanned, segmented, and MAC-filtered. But what are your devices saying behind your back at the DNS level? Deploy a cloud-based DNS sinkhole to monitor every domain query in real time and block trackers network-wide.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or revert them entirely. This project runs on your local network with free tools, so there are no ongoing costs.

Resources you used:

NextDNS DNS configuration on Globe router (free, reverts to standard DNS after 300,000 monthly queries).
Guest network SSID on Globe router (no cost, persists until disabled).
MAC filtering whitelist on Globe router (no cost, persists until disabled).
Nmap scan files on Kali VM (router-scan.txt and extender-scan.txt).
VirtualBox bridged adapter configuration on Kali VM.

Keep everything running

No action needed. Choose this if you want ongoing protection from your network hardening.

Guest network segmentation and MAC filtering continue providing layered security for your home network.
NextDNS continues filtering DNS queries until the 300,000 monthly query limit. After that, it reverts to standard non-blocking DNS resolution at no cost.
The VirtualBox bridged adapter keeps your Kali VM ready for future network scanning sessions.
Your NextDNS free account remains active at no ongoing cost. No action is needed to maintain it.
Your scan files (router-scan.txt and extender-scan.txt) are useful portfolio evidence of your penetration testing work.

Pause - I'll come back to this later

Disable MAC filtering to avoid friction when adding new devices. Keep guest network segmentation active for ongoing protection.

Log into your Globe router admin panel.
Navigate to MAC Filtering or Access Control settings.
Set the mode to Disabled (or remove all entries from the whitelist). Save and apply.
Leave the guest network SSID active for ongoing segmentation.
Leave the NextDNS DNS settings in place. They continue working within the free tier.
Optionally revert VirtualBox to NAT mode if you do not need Kali on your LAN. Power off the VM, open Settings > Network, and change Adapter 1 back to NAT.

Delete - I don't want to use this again

Remove all project configurations and return your network to its pre-project state.

Revert NextDNS DNS settings:

Log into your Globe router admin panel.
Navigate to WAN or Internet settings where you configured DNS.
Replace the two NextDNS IPv4 addresses with your ISP's default DNS servers, or set DNS to Automatic (DHCP). Save and apply.

Disable guest network:

In your Globe router admin panel, navigate to Wireless or Guest Network settings.
Disable the Guest Network SSID. Save and apply.

Disable MAC filtering:

In your Globe router admin panel, navigate to MAC Filtering or Access Control settings.
Set the mode to Disabled or remove all entries from the whitelist. Save and apply.

Delete scan files on Kali:

Open a terminal in your Kali VM and run:

rm router-scan.txt extender-scan.txt

Revert VirtualBox bridged adapter:

Power off your Kali VM.
In VirtualBox, open Settings for your Kali VM.
Go to Network. Change Adapter 1 from Bridged Adapter back to NAT. Click OK.

What about the NextDNS account?

Your NextDNS free account persists but costs nothing and becomes inert once you remove the DNS settings from your router. No network traffic flows through it after reverting.

Nice Work!

You just completed a full penetration test of your own home network. You acted as both attacker and defender, proving with real scan data that your hardening measures actually block the attacks they claim to stop.

You've learned how to:

Run professional-grade Nmap port scans from a Kali Linux VM that documented your router and extender's security posture with saved scan reports.
Segment your network with a guest SSID and prove with a live ping test that IoT and guest devices cannot reach your main machine.
Enforce MAC address filtering as a Layer 2 access control so only whitelisted devices can join your primary network, even with the correct password.
Secret Mission: Deployed NextDNS as a network-wide DNS sinkhole to monitor and filter all DNS queries from your devices in real time.

Ready to quiz yourself?