Forum Discussion
CAX 80 injecting malformed TCP RSTs
I have a CAX80 that appears to be actively interfering with and terminating encrypted TLS connections by injecting malformed TCP Reset (RST) packets. This occurs even with the following disabled:
IPv4 Firewall
DoS Protection
SIP ALG
Protection Engine
Is there somewhere else I'm missing?
A little context:
I've noticed this happen on occasion when using OpenVPN AS web interface, as I admin my company's VPN at times. But it was only an occasional nuisance. Now I'm working with an AI agent, and I have to constantly retry due to this, upwards of 20-30 times sometimes, which also causes the agent to lose track of what is was in the middle of doing, but eventually the retry will work. However, if I create an SSH tunnel, and launch the agent that way, it works flawlessly (presumably because the tunnel is masking some signature from the router that causes it to insert these packets, i.e., it's not watching traffic over tcp:22, but is doing so over tcp:443).
tcpdumps taken from my laptop connected to the CAX80 show the following signature:
- A TCP RST (Reset) packet is received.
- The RST packet contains 6 bytes of zero-filled payload (00 00 00 00 00 00).
- Standard TCP RST packets should have a 0-byte payload.
The TTL (Time To Live) of these RST packets is 102, while the remote server (daily-cloudcode-pa.googleapis.com) packets arrive with TTL ~118. This proves the packets are generated locally by the CAX80, not the remote server.
Some of the behaviors I've observed through the tcpdumps:
With Protection Engine enabled: Connection is reset immediately.
With everything disabled: Connection hangs for a few seconds, then is flooded with the exact same 6-byte RST packets (TTL 102).
So is this just a firmware/hardware bug at this point? Or is there something else I'm missing that needs to be disabled for it to stop injecting these RSTs?
The only other thing I can think of is to put the thing in bridge mode, then go buy a different wi-fi router.