From a6208ef330a3b8007cbec7c7beb35a30bc21d658 Mon Sep 17 00:00:00 2001 From: Sunil Thakare Date: Wed, 19 Aug 2026 13:36:35 +0530 Subject: [PATCH] docs: add remote LAN multi-path stress test validation --- docs/STRESS_TEST.md | 595 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 595 insertions(+) create mode 100644 docs/STRESS_TEST.md diff --git a/docs/STRESS_TEST.md b/docs/STRESS_TEST.md new file mode 100644 index 0000000..25da484 --- /dev/null +++ b/docs/STRESS_TEST.md @@ -0,0 +1,595 @@ +# NX9-WG Stress Test --- Remote LAN Multi-Path Integration + +**Project:** NX9-WG\ +**Test Type:** Integration / Stress Test\ +**Status:** PASS\ +**Date:** 2026-08-19\ +**Purpose:** Validate robust remote access to a protected LAN through +NX9-WG across substantially different underlying network paths. + +------------------------------------------------------------------------ + +## 1. Executive Summary + +This test validates that `nx9-wg` can provide authenticated, routed +access to a remote `192.168.1.0/24` LAN while the WireGuard client uses +different and independent Internet/access-network paths. + +The test deliberately exercised NX9-WG through: + +1. Cellular 5G → mobile WAN AP → laptop. +2. Airtel Wi-Fi → Pixel Wi-Fi Station + Access Point concurrency → + laptop. +3. A separate Wi-Fi network → laptop. + +In all tested paths, the same NX9-WG peer successfully established the +VPN and reached hosts and services on the protected LAN. + +The strongest validation was successful interactive SSH access to +`192.168.1.200`, in addition to ICMP, HTTP, network filesystem access, +and LAN host discovery. + +**Overall result: PASS.** + +------------------------------------------------------------------------ + +## 2. Test Objective + +Validate that NX9-WG: + +- establishes a WireGuard tunnel independently of the client's + underlying access network; +- correctly routes traffic from a remote peer to the protected LAN; +- handles different upstream NAT/network topologies; +- provides access to multiple LAN hosts rather than only a single + endpoint; +- supports real application traffic over the tunnel; +- preserves connectivity when the client changes access-network + topology; +- does not require changes to the protected LAN or ISP router + configuration. + +This test is intended as an **integration and robustness validation**, +not as a throughput benchmark. + +------------------------------------------------------------------------ + +## 3. Network Topology + +### Protected LAN + +``` text +192.168.1.0/24 +``` + +Representative hosts: + +``` text +192.168.1.1 Airtel AirFiber / Nokia AAP321NK +192.168.1.200 Debian server / Thakares IoT Hub +``` + +### NX9-WG peer + +``` text +WireGuard interface: Office-Laptop +WireGuard address: 10.100.0.6/32 +MTU: 1280 +``` + +The important architectural property is that the client-side underlay +network can change while the WireGuard overlay identity and protected +LAN remain unchanged. + +------------------------------------------------------------------------ + +# 4. Test Scenario A --- Cellular 5G + +## Path + +``` text +5G Internet + │ + ▼ +Mobile phone + │ + │ WAN AP / hotspot + ▼ +Laptop + │ + │ NX9-WG + ▼ +NX9-WG server + │ + │ routed LAN access + ▼ +192.168.1.0/24 +``` + +## Procedure + +1. Mobile phone connected to cellular 5G. +2. Mobile phone provided WAN/AP connectivity. +3. Laptop connected to the mobile AP. +4. NX9-WG VPN was enabled. +5. Laptop received an Internet address on the mobile network. +6. Remote LAN routes became reachable through NX9-WG. + +## Observed client addressing + +``` text +wlan0: 10.137.106.48/24 +WireGuard: 10.100.0.6/32 +``` + +## Validation + +### Internet + +``` text +ping google.com +``` + +Result: + +``` text +0% packet loss +``` + +### LAN host + +``` text +ping 192.168.1.200 +``` + +Result: + +``` text +0% packet loss +``` + +### LAN discovery + +An initial ordinary `nmap -sP 192.168.1.0/24` did not discover hosts +while the LAN was only reachable through the routed WireGuard path. +Individual routed hosts were nevertheless reachable. + +This was subsequently validated more comprehensively in Scenario C using +`nmap` with the active routed path. + +------------------------------------------------------------------------ + +# 5. Test Scenario B --- Wi-Fi STA + AP Concurrency + +This was the more interesting underlay test. + +The Pixel device supports simultaneous Wi-Fi client (STA) and Access +Point operation. + +## Path + +``` text + Airtel Wi-Fi + │ + ▼ + Pixel Wi-Fi STA + │ + Pixel Wi-Fi AP + │ + ▼ + Laptop + │ + NX9-WG + │ + ▼ + NX9-WG server + │ + ▼ + 192.168.1.0/24 +``` + +## Procedure + +1. Pixel connected to Airtel Wi-Fi. +2. Pixel simultaneously enabled its Access Point. +3. Laptop connected to the Pixel AP. +4. Laptop enabled NX9-WG. +5. No cellular Internet was used. +6. Remote LAN access worked immediately. + +## Result + +**PASS** + +This demonstrates that NX9-WG remains functional when the client reaches +the Internet through a Wi-Fi STA/AP-concurrent intermediate device. + +No cellular fallback was required. + +------------------------------------------------------------------------ + +# 6. Test Scenario C --- Remote LAN Application and Host Validation + +A further test was performed from an external Wi-Fi network. + +## Client addressing + +``` text +wlan0: +10.24.3.48/24 + +WireGuard: +10.100.0.6/32 +``` + +The underlying Wi-Fi network therefore differed from the protected LAN. + +## Internet validation + +``` bash +ping nx9.in +``` + +Observed: + +``` text +5 packets transmitted +5 received +0% packet loss + +min/avg/max/mdev: +82.653 / 93.637 / 101.691 / 7.049 ms +``` + +## Public Internet validation + +``` bash +ping google.com +``` + +Observed: + +``` text +5 packets transmitted +5 received +0% packet loss + +min/avg/max/mdev: +87.633 / 118.502 / 165.108 / 30.034 ms +``` + +## Airtel gateway validation + +``` bash +ping 192.168.1.1 +``` + +Observed: + +``` text +2 packets transmitted +2 received +0% packet loss + +min/avg/max/mdev: +98.975 / 99.509 / 100.043 / 0.534 ms +``` + +## LAN server validation + +``` bash +ping 192.168.1.200 +``` + +Observed: + +``` text +3 packets transmitted +3 received +0% packet loss + +min/avg/max/mdev: +88.959 / 95.690 / 105.145 / 6.882 ms +``` + +------------------------------------------------------------------------ + +# 7. LAN Host Discovery + +The routed LAN was scanned using: + +``` bash +nmap -sP 192.168.1.0/24 +``` + +The following 17 hosts were discovered: + +``` text +192.168.1.1 +192.168.1.3 +192.168.1.4 +192.168.1.5 +192.168.1.6 +192.168.1.7 +192.168.1.8 +192.168.1.9 +192.168.1.10 +192.168.1.13 +192.168.1.18 +192.168.1.20 +192.168.1.60 +192.168.1.64 +192.168.1.100 +192.168.1.152 +192.168.1.200 +``` + +Result: + +``` text +17 hosts up +``` + +This is significant because it validates routed access to the LAN as a +network segment rather than connectivity to only one predefined host. + +------------------------------------------------------------------------ + +# 8. Application-Level Validation + +## HTTP + +The NX9-WG client successfully accessed: + +``` text +http://192.168.1.200:8008 +``` + +The Thakares IoT Hub web application loaded successfully. + +## Network filesystem + +The Linux desktop successfully accessed the remote Debian server: + +``` text +192.168.1.200 +/home/sunil +``` + +## SSH + +The strongest application-level validation was: + +``` bash +ssh 192.168.1.200 +``` + +which produced a normal interactive login: + +``` text +Linux thakares 6.12.101+deb13-rt-amd64 +Debian GNU/Linux +x86_64 +``` + +The remote shell was successfully entered and exited normally. + +This confirms: + +- TCP connectivity; +- routing; +- return-path routing; +- firewall/forwarding compatibility; +- SSH service accessibility; +- stable encrypted transport; +- real bidirectional application traffic. + +------------------------------------------------------------------------ + +# 9. Test Results + + Validation Result + ------------------------------------ -------- + WireGuard tunnel establishment PASS + External Internet through tunnel PASS + Cellular 5G underlay PASS + Wi-Fi underlay PASS + Wi-Fi STA + AP concurrent underlay PASS + Protected LAN reachability PASS + Airtel gateway `192.168.1.1` PASS + LAN server `192.168.1.200` PASS + ICMP PASS + LAN host discovery PASS + HTTP application PASS + Network filesystem access PASS + SSH PASS + Interactive remote shell PASS + Multiple LAN hosts PASS + No cellular dependency PASS + +------------------------------------------------------------------------ + +# 10. Key Finding + +The same NX9-WG peer: + +``` text +10.100.0.6/32 +``` + +successfully accessed: + +``` text +192.168.1.0/24 +``` + +while its underlying client network changed. + +Examples included: + +``` text +10.137.106.0/24 +10.24.3.0/24 +``` + +This demonstrates a clean separation between: + +- **underlay:** whatever network currently provides Internet + connectivity; +- **overlay:** the authenticated NX9-WG tunnel; +- **protected network:** the routed `192.168.1.0/24` LAN. + +The protected LAN required no modification for these tests. + +------------------------------------------------------------------------ + +# 11. Why This Is a Meaningful Stress Test + +This test does not attempt to measure maximum WireGuard throughput. + +Instead, it stresses the **network topology and routing assumptions** of +NX9-WG. + +The tested paths introduce: + +- different client networks; +- different NAT environments; +- mobile AP routing; +- Wi-Fi STA/AP concurrency; +- additional network hops; +- remote access to an entire private subnet; +- multiple simultaneous LAN destinations; +- multiple application protocols. + +The successful results indicate that NX9-WG is not dependent on a +particular client access network. + +------------------------------------------------------------------------ + +# 12. Airtel LAN Collision Use Case + +The test originated from a practical problem involving an Airtel +AirFiber Nokia AAP321NK using: + +``` text +192.168.1.1 +``` + +which overlaps with the existing home LAN addressing. + +Instead of modifying the ISP-controlled router configuration, NX9-WG +provided an independent routed management path: + +``` text +External network + │ + ▼ + NX9-WG + │ + ▼ +192.168.1.0/24 + │ + ├── 192.168.1.1 + ├── 192.168.1.200 + └── other LAN hosts +``` + +This demonstrates a practical operational benefit of the NX9-WG +architecture: remote authenticated access to infrastructure can remain +available without requiring ISP router reconfiguration. + +------------------------------------------------------------------------ + +# 13. What This Test Does Not Establish + +This test should **not** be interpreted as a performance benchmark. + +The following remain outside the scope of this test: + +- maximum throughput; +- sustained high-volume transfer; +- CPU utilisation; +- simultaneous high-volume traffic from many peers; +- large-scale concurrent peer testing; +- packet-loss recovery under severe loss; +- roaming during an active session; +- MTU/fragmentation testing under load; +- IPv6 routed-LAN testing; +- server restart/recovery testing; +- client sleep/resume testing; +- long-duration soak testing. + +These should be covered by separate tests if required. + +------------------------------------------------------------------------ + +# 14. Recommended Future Stress Tests + +Future NX9-WG validation can extend this matrix with: + +### Performance + +``` text +iperf3 +``` + +- TCP throughput; +- UDP throughput; +- bidirectional traffic; +- sustained transfers. + +### Reliability + +- 1-hour soak test; +- 24-hour soak test; +- repeated tunnel reconnects; +- server restart; +- client suspend/resume. + +### Mobility + +- Wi-Fi → 5G; +- 5G → Wi-Fi; +- AP changes while tunnel is active; +- changing NAT environments. + +### Scale + +- multiple simultaneous peers; +- multiple LAN destinations; +- concurrent HTTP/SSH/file traffic. + +### Network edge cases + +- MTU stress; +- fragmentation; +- packet loss; +- high latency; +- jitter; +- IPv6. + +------------------------------------------------------------------------ + +# 15. Final Assessment + +**NX9-WG Remote LAN Multi-Path Integration Test: PASS** + +The implementation successfully provided authenticated routed access +from externally connected clients to the protected `192.168.1.0/24` LAN +across multiple substantially different network paths. + +The successful SSH session to `192.168.1.200`, access to the IoT Hub, +network filesystem access, and discovery of 17 LAN hosts provide strong +practical evidence that the VPN is functioning as a complete remote-LAN +connectivity solution rather than merely establishing a WireGuard +handshake. + +------------------------------------------------------------------------ + +**Test conclusion:** + +> NX9-WG successfully maintained functional remote access to the +> protected LAN independently of the underlying client access network, +> including cellular, Wi-Fi, and Wi-Fi STA/AP concurrent paths. + +**Status: PASS**