- Looked like
- VPN / tunnel instability
- Actually
- LAN IP conflict
- Layer
- Network / Customer site
Field note
An edge device kept dropping in and out over remote access, so the tunnel was the obvious suspect. Swapping or restarting the remote access path made no lasting difference. Moving the search from the remote tooling down to the local network revealed two devices claiming the same IP address — the intermittent reachability was an address conflict on the customer LAN, not an unstable tunnel.
- Symptom
- An edge device was reachable intermittently through remote access.
- Misleading hypothesis
- The issue was initially attributed to VPN or tunnel instability.
- Boundary expansion
- The investigation moved from remote access tooling to LAN identity and address allocation.
- Root cause
- Two devices were competing for the same IP address inside the customer network.
- Signals
-
- Connectivity worked intermittently instead of failing consistently
- Remote access tooling appeared unstable, but the device identity was not stable locally
- The symptoms matched address conflict more than tunnel failure
- Checks
-
- Verified local network reachability
- Checked whether the same IP consistently mapped to the same device
- Confirmed the issue at the LAN/IP layer before changing remote access tooling
Evidence trail
Connectivity was intermittent, not consistently broken
Remote access appeared unstable, but local identity was suspicious
LAN reachability and IP ownership were checked first
IP conflict explained the unstable remote behavior
Reusable lesson
For intermittent connectivity, verify IP/MAC consistency and local network identity before replacing remote access tools.
Dealing with a failure that looks like one layer but might be another?