Posting this because I found nothing on it and it took a full packet

capture to figure out.

SETUP

AutomationDirect C-more panel at 192.168.1.200, UniFi gateway, remote

access via UniFi Teleport VPN.

Panel model: EA9-T10WCL

Firmware: 2.0 (Displayed on panel) or 6.80.0.0 (Displayed on internal web page)

Panel IP: 192.168.1.200 / 255.255.255.0, gateway 192.168.1.1

SYMPTOM

Onsite: panel works perfectly. Over VPN: web interface takes ~30-60s per

page and the C-more Remote HMI app won't connect at all. But ping works,

the port scan shows 80 and 11102 open, and latency is a healthy 35ms.

Everything that normally indicates "the network is fine" said the network

was fine.

WHAT IT ACTUALLY IS

The panel does not transmit the leading segment of its HTTP response when

the client is outside its own subnet. The client SACKs the missing bytes,

the panel's TCP stack ignores the SACK and never fast-retransmits, so it

waits out a full ~2.9s retransmission timeout before resending. Every

connection, 100% of the time.

Because the panel also closes the connection after every single request,

a page with 20 assets costs 20 x 3 seconds. The app fails outright since

its handshake timeout is shorter than the stall.

Onsite you're on the same subnet, so it never happens -- which is why this

looks like a VPN problem when it isn't.

tcpdump at the client, GET / returning a 292-byte 401:

 t+0.165s panel -> client seq 1421242891:1421243168 len 277

 t+3.027s panel -> client seq 1421242876:1421243168 len 292

The first packet starts 15 bytes into the stream. The status line simply

isn't sent until the retransmission.

HOW I RULED OUT THE NETWORK

This is the part worth stealing: I hit five other hosts on the same

subnet, through the same tunnel, in the same test run.

 192.168.1.1   88 ms  first segment intact

 192.168.1.167  92 ms  first segment intact (1282 bytes)

 192.168.1.218  142 ms  first segment intact

 192.168.1.200 3030 ms  FIRST SEGMENT MISSING

All clean but the panel. Also 0/30 ICMP loss and DF pings passing at the

full 1420-byte tunnel MTU. I burned time on MTU and on UniFi's IPS/DPI

before doing this -- comparing against a known-good host on the same path

would have saved me an hour.

THE FIX

Source-NAT the VPN traffic at the gateway so the panel sees an on-subnet

source. In UniFi Network (Settings -> Policy Engine -> NAT):

 Type:      Src. NAT   (not Masquerade)

 Interface:   your LAN network, NOT WAN1

 Translated IP: 192.168.1.1  (gateway's LAN address)

 Protocol:    All

 Source:     Any (or your Teleport network)

 Destination:  IP -> 192.168.1.200, port Any

The Interface field is the trap. It defaults to WAN1, and left that way the

rule silently matches nothing -- your traffic egresses toward the LAN, not

the WAN. I "tested the fix," saw no change, and nearly discarded the right

answer because of it.

Result: 3.11s -> 0.12s TTFB, all segments arriving in order, zero

retransmissions. App connects fine.

BONUS GOTCHA

After fixing this, the app still failed from my phone -- because my home

WiFi is also 192.168.1.0/24, so 192.168.1.x never entered the tunnel and

192.168.1.1 was reaching my own home router. Worked instantly on cellular.

Reported to AutomationDirect support. Will update if there's a firmware fix.