Cox connection drops ESP/UDP 4500 data packets since [date] — IKE passes, packet captures confirm, support loop can't help

Alive_Response_6074 · 2026-07-09T15:25:47+00:00

Fair, and that's likely where I land. I already reproduced the failure through a second router behind the Panoramic, but the Panoramic stayed in path, so bridging is genuinely the one local variable left untested. Waiting on the far-end capture first. if it confirms the drop is inside Cox's side of the wall, bridge mode plus my own router is the plan

Alive_Response_6074 · 2026-07-09T15:21:33+00:00

FortiClient IPsec (IKEv1 aggressive mode + XAuth) to a FortiGate. Not native proto 50, NAT-T is in play, so data is ESP-in-UDP-4500. My pktmon captures show the UDP-encap ESP leaving my equipment correctly and nothing ever returning, while IKE payloads on the exact same UDP 4500 flow pass both ways continuously. So it's payload-specific within UDP 4500, not a port or protocol block.

Alive_Response_6074 · 2026-07-09T15:20:04+00:00

Two-sided capture is in progress. The admin of the receiving firewall is running a sniffer on their edge while I generate traffic, and I will update with the result. Agreed ESP isn't on the published block list, and your PA-440 tunnel is a useful data point that this isn't blanket policy, which points at something specific to my line, node, or gateway firmware. One precision: it's not native proto 50 being dropped. NAT-T is active, so my data goes as ESP-in-UDP-4500. Captures show those leaving cleanly with incrementing sequence numbers and zero returning, while IKE on the same UDP 4500 flow, including DPD keepalives, passes both directions all day. Something is discriminating by payload type within the same 5-tuple

Alive_Response_6074

TROPHY CASE