thakares/nx9-wg
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
nx9-wg/docs/STRESS_TEST.md
T

13 KiB
Raw Permalink Blame History

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

192.168.1.0/24

Representative hosts:

192.168.1.1      Airtel AirFiber / Nokia AAP321NK
192.168.1.200    Debian server / Thakares IoT Hub

NX9-WG peer

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

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

wlan0: 10.137.106.48/24
WireGuard: 10.100.0.6/32

Validation

Internet

ping google.com

Result:

0% packet loss

LAN host

ping 192.168.1.200

Result:

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

                 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

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

ping nx9.in

Observed:

5 packets transmitted
5 received
0% packet loss

min/avg/max/mdev:
82.653 / 93.637 / 101.691 / 7.049 ms

Public Internet validation

ping google.com

Observed:

5 packets transmitted
5 received
0% packet loss

min/avg/max/mdev:
87.633 / 118.502 / 165.108 / 30.034 ms

Airtel gateway validation

ping 192.168.1.1

Observed:

2 packets transmitted
2 received
0% packet loss

min/avg/max/mdev:
98.975 / 99.509 / 100.043 / 0.534 ms

LAN server validation

ping 192.168.1.200

Observed:

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:

nmap -sP 192.168.1.0/24

The following 17 hosts were discovered:

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:

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:

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:

192.168.1.200
/home/sunil

SSH

The strongest application-level validation was:

ssh 192.168.1.200

which produced a normal interactive login:

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:

10.100.0.6/32

successfully accessed:

192.168.1.0/24

while its underlying client network changed.

Examples included:

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:

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:

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

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

Reference in new issue View Git Blame Copy Permalink