# 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**