docs: add remote LAN multi-path stress test validation
This commit is contained in:
1 parent
d704c1e131
commit
a6208ef330
1 file changed
+595
@@ -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**
|
||||||
Reference in new issue
Block a user