How to safely test your own router: a practical guide

The router is one of the least frequently updated yet most exposed elements of network infrastructure. Firmware vulnerabilities in the OpenWrt ecosystem show that even widely deployed open-source solutions are not free from critical RCE-class flaws that may remain active for months without the administrator's knowledge. If you manage a corporate or lab network and have never run an active audit of your router, you are most likely operating on assumptions, not facts. This guide walks through the entire process: from preparing the environment, through systematic auditing, to retesting and vulnerability analysis.

Table of contents

• What to prepare before testing the router

• Stage 1: Attack surface and baseline settings audit

• Zero Trust and segmentation as the foundation of safe testing

• Retesting and vulnerability analysis: verifying real security

• Typical test scenarios: services, interfaces and pitfalls

• Why router testing is harder than it looks: a practical perspective

• Tools and support for router pentesting

• Frequently asked questions

Key Takeaways

What to prepare before testing the router

For the test itself to be effective and not damage the device, properly preparing the environment is critical. Unprepared tests are one of the most common causes of incorrect results or accidentally locking yourself out of the management console.

Following good practices, a router security audit should start with verifying the attack surface and baseline settings of the device. This means that before you launch any scanner, you need a full picture of the current configuration state.

Checklist for preparing the test environment

• Configuration documentation: screenshot or settings export, list of active firewall rules, inventory of connected hosts

• Router settings backup: configuration file saved locally and on external media, not in the cloud

• Firmware currency: check the firmware version in the admin panel and compare with the latest version from the vendor

• Admin password verification: whether the vendor's default credentials have been changed

• List of testing tools: Nmap, Wireshark, Aircrack-ng, Metasploit (if testing known CVEs)

• Isolated network: if possible, run tests on a network detached from production

The choice of pentest hardware matters here in practice. For a Wi-Fi layer audit it is worth reaching for dedicated cards with monitor and injection mode - wireless network testing equipment gives full control over management frames and lets you reproduce attack scenarios under conditions close to production.

Comparison of popular router audit tools

Pro tip: Never run penetration tests without backing up the router configuration first. Aggressive fuzzing or a failed DoS test can lead to a factory reset. The backup takes 30 seconds, manual restoration takes hours.

Stage 1: Attack surface and baseline settings audit

After preparing the environment you can move on to the key stage: a systematic audit. This is not a one-off click on the "check for updates" button, but a structured process of verifying more than a dozen items.

The audit of the attack surface and verification of baseline settings is the starting point of every professional router security test. Below is the sequence of steps in order from highest risk.

Audit order step by step

1. Firmware version verification. Open the admin panel and compare the version with the vendor's official changelog. Check whether the vendor has released a security advisory for your model.

2. Change of default credentials. Every router ships with factory login and password. They are publicly available in vendor documentation and the first target of credential stuffing.

3. Wi-Fi encryption verification. The minimum acceptable encryption is WPA2-AES. If the router supports WPA3, enable WPA2/WPA3 mixed mode. WEP and WPA-TKIP should be treated as no protection.

4. Disable UPnP (Universal Plug and Play). UPnP automatically opens ports on demand from internal applications and devices, without additional authorisation. It is one of the most common vectors for exposing the device to the internet.

5. Disable WPS. The WPS PIN is vulnerable to brute force and allows recovery of the Wi-Fi password in time ranging from a few minutes to a few hours.

6. Disable remote management. If the service is not strictly required, the router's web interface should not be accessible from the WAN.

7. Device log review. Access and authentication logs reveal failed login attempts, unknown hosts and traffic anomalies. These are often the only traces of an earlier incident.

8. Inventory of connected hosts. The DHCP list and ARP table show which devices actually communicate through the router. Unknown hosts are a red flag.

For field testing of the Wi-Fi layer, dedicated Wi-Fi security testing tools are useful - they enable simulation of deauthentication attacks and verification of the network's resilience to such interference. For more advanced scenarios (rogue AP, evil twin, captive portal) the WiFi Pineapple Mark VII works well - a dedicated wireless auditing platform with ready-made modules.

Router settings evaluation table

Pro tip: Port scanning with Nmap from outside the network (e.g. via a mobile hotspot) shows exactly what a potential attacker sees. Use nmap -sV -p- [router WAN IP] and compare the results with what you configured. Discrepancies are the first leads for further investigation.

Zero Trust and segmentation as the foundation of safe testing

The next stage is to apply advanced methods of network partitioning and access control. Securing a single device alone is not enough if the network architecture assumes default trust in internal traffic.

The Zero Trust model in the context of the router means that no device or service is granted access just because it is "in the network". A Zero Trust approach to access control requires limiting management access and verifying identity for every request, regardless of source.

In practice for the router this means:

• Restricting access to the admin panel exclusively to one dedicated VLAN or a specific MAC address

• Disabling management access over Wi-Fi and limiting it to a LAN port or cable

• Enabling two-factor authentication where the firmware supports it (e.g. OpenWrt with the oath-toolkit package)

• Whitelist-based firewall policies, not default-allow on internal traffic

Network segmentation is not just an organisational technique, it is a method of testing the security boundary. If a rule is meant to block traffic between segments, the only proof of its effectiveness is attempting that traffic.

For practical VLAN and separate-SSID tests, network segmentation step by step for IoT environments consists in assigning IoT devices to a separate SSID with its own VLAN, and then actively testing whether a host from the IoT segment can communicate with a host in the main segment.

Methods for testing segmentation are:

• Cross-VLAN ping: running a simple ping from one segment to another and verifying that packets are actually blocked

• Cross-VLAN Nmap scan: nmap -sn [target network] from a host in the IoT segment

• Firewall traversal test: attempting to establish a TCP/UDP connection on a specific port between segments

• Firewall log analysis: verifying that blocked packets actually generate log entries and that monitoring is active

The growing number of IoT cyberthreats in home networks shows that compromise of a single IoT device without segmentation gives the attacker direct access to the entire internal network. Segmentation tests are therefore verification of the real security boundary, not just configuration documentation.

Retesting and vulnerability analysis: verifying real security

After deploying segmentation and Zero Trust, regular retesting and reactivity to new threats become key. A configuration verified three months ago may be outdated today if the vendor published a new CVE or updated recommendations.

Repeatable tests after configuration changes are a key element of verifying VPN tunnels and security policies. This applies both to IPSec site-to-site configurations and remote-user VPN connections.

Retesting process step by step

1. Define a baseline: after the first audit, document the results as a reference point. Compare every subsequent test against that state.

2. Test after every configuration change: firmware update, firewall rule change, addition of a new device to the network - each of those changes requires re-verification.

3. CVE scanning: use vulnerability databases (NVD, CVE Details) filtered by router model. New entries appear regularly and reaction time matters.

4. VPN tunnel validation: after every change to the IPSec or OpenVPN configuration verify not only that the connection is established, but also routing, encryption and behaviour during session loss.

5. Log analysis for anomalies: distinguishing false positives from real incidents requires knowing the normal traffic pattern. Keep logs for at least 30 days.

6. Scanning automation: tools like OpenVAS or Greenbone allow recurring vulnerability scanning without manual launching every time.

Router vulnerabilities in OpenWrt firmware are real examples of how a popular platform can contain critical flaws for a long time. CVE scanning without knowledge of the exact firmware version and hardware variant is poorly effective.

Pro tip: Set an alert in the NVD (National Vulnerability Database) on the vendor name and router model. Email notifications about new CVEs let you react in hours, not weeks.

For advanced radio-layer testing, Alfa AWUS1900 or Alfa AWUS036ACM cards are useful - both with monitor and injection mode support, for full 2.4/5 GHz band scanning and capturing management frames. For rogue AP, evil twin and captive portal scenarios use the WiFi Pineapple Mark VII. A full overview of network audit equipment is in the Network category.

Typical test scenarios: services, interfaces and pitfalls

With awareness of repeatability and vulnerability analysis, you can move to everyday, hands-on test scenarios. This is the stage where theory turns into specific tool invocations and result interpretation.

Pentest of a TP-Link router shows that approaching the router as an embedded system requires test scenarios for each exposed service separately: UPnP, the web interface, the management API and diagnostic services.

Typical test scenarios include:

• UPnP test: use a tool like Miranda or Miranda Python to enumerate UPnP services and check whether it is possible to add an external port mapping without authorisation

• Web UI test: Nikto scans the interface for known vulnerabilities, exposed paths and unauthorised endpoints

• Port scan from the WAN: Nmap from an external IP identifies services actually reachable from the internet, regardless of the configuration assumed by the administrator

• Login form fuzzing: tools like Burp Suite allow analysis of the interface's behaviour under invalid or specifically crafted input

• Simulated DoS test: checking how the router behaves under a high number of connection requests, e.g. with hping3 or flooding-resilience tools

One of the typical test pitfalls is "fake success": the server returns 403 Forbidden or 302 Redirect, which looks like proper access blocking but in reality the endpoint itself is reachable after a small modification of the header or HTTP method. Always verify not just the response code, but also the response body.

Distinguishing false positives from real exploitation requires comparing scanner output with manual verification. A scanner may report a vulnerability based on a version banner alone, not a real exploit. Manual verification consists in attempting the action that the vulnerability enables, in a controlled environment.

For detecting attacks on the Wi-Fi layer, especially deauthentication attacks that are a precursor to a full test session, dedicated hardware such as a Wi-Fi DoS attack detector is worth using. It provides both the option to test network resilience and to monitor it during tests.

Planning fuzzing for a router API requires knowledge of which endpoints are available. Many consumer routers expose a REST API or a CGI-based API that is not required for daily use. Disabling unused endpoints reduces the attack surface at zero functional cost.

Why router testing is harder than it looks: a practical perspective

Although the methods seem simple, practice requires more. Experience with various router models shows that the most frequent problems do not lie in the lack of tools, but in flawed assumptions about what the test actually verifies.

First problem: market routers almost always contain undocumented functions and hidden services that do not appear in official documentation. Vendors implement remote support, diagnostic or update mechanisms that operate independently of administrator settings. Exposure verification and post-fix validation of edge router vulnerabilities show that vendor declarations of closing a flaw alone do not replace evidence-based confirmation that the attack path is no longer active.

Second problem, perhaps even more serious: many specialists run tests under laboratory conditions and skip edge scenarios. Remote management disabled in the lab may be enabled in production by another administrator. A firewall rule working correctly for IPv4 traffic may be bypassed by IPv6 traffic if the router supports dual-stack and the rules have not been defined for both protocol versions.

Third problem is a false sense of security after a patch. After a firmware update many organisations close the ticket and do not return to the topic. Meanwhile the new firmware may introduce new vulnerabilities, change defaults or reset selected configurations. Every update requires going through the full audit checklist, not just confirming the version number.

Fourth aspect, rarely discussed: documentation of test results has operational value only when it is detailed enough to enable retesting by another specialist. "Router tested, no issues" is a useless record. Valuable documentation contains the exact firmware version, tool versions, commands, results and interpretation. Only such a record allows meaningful comparison of results after a subsequent configuration change.

When using network pentest tools it is worth remembering that hardware is just one piece of the puzzle. Methodology, documentation and test repeatability decide whether the audit result is operationally useful.

Tools and support for router pentesting

If you want to use the knowledge gained and start your own tests, reach for proven tools and specialist support.

Sapsan Shop offers hardware dedicated to router security audits - from home devices to enterprise and edge class. In the Network category you will find Alfa AWUS1900 and AWUS036ACM adapters with monitor/injection mode, the WiFi Pineapple Mark VII for full rogue AP scenarios, and deauthers for testing resilience against DoS attacks on the Wi-Fi layer.

For LAN segmentation tests and passive eavesdropping of traffic between VLANs, the Packet Squirrel Mark II or LAN Turtle are useful - both allow silent interposition on an Ethernet cable and inline traffic analysis. Sapsan ships worldwide and the offering is updated to match the current needs of pentesters and ethical hackers working in B2B and B2C environments.

Frequently asked questions

Can testing your own router damage it?

Using the audit methods from this guide and having a configuration backup made first, the risk of damage is minimal, because the audit starts with passive verification of settings and only then moves to active tests.

How often to repeat router security tests?

Tests should be performed after every significant configuration change or firmware update, and repeatable tests after changes are particularly important for verifying VPN tunnels and access policies. The minimum is once per quarter for stable environments.

Ethical rules: may I test a work or someone else's router?

You are only allowed to test equipment to which you have formal rights and written consent of the owner or system administrator. Lack of consent means acting illegally, regardless of intent.

Is every router suitable for self-pentesting?

Most home models allow auditing baseline settings and port scanning, but tests of embedded subsystems such as UPnP and the web UI may be limited by closed firmware that blocks access to the system shell or full logging.

How to tell a real vulnerability from a false alarm in tests?

Verification requires manual confirmation: a scanner may report a vulnerability based on a version banner, but distinguishing false positives from real exploitation requires attempting the actual attack action in a controlled environment and comparing the results with the device logs.