docs: add remote LAN multi-path stress test validation
This commit is contained in:
thakares committed
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