Ian Smith wrote:
That's pretty well described under keep-state and elsewhere. Good ol' ipfw(8) has yet to let me down, and like Ivan I recall keep-state rules (albeit only for UDP) without any check-state working just fine.Not that any of that helps solve Ivan's problem ..
Thanks for verifying this. I've reread what I posted and I think I wasn't clear about one thing: it's not exactly a "hard" problem - as I said, connections do get established and apparently they get processed (the effects of those HTTPS messages are present). What troubles me is that I wouldn't expect that to happen, considering the ipfw log messages I've posted. In short, either:
a) The senders (or something in between like a broken router; but note that the 7.x machine behind the same infrastructure isn't generating the symptomatic log records) keeps sending spurious packets long after the TCP session (communication) is actually completed. Someone with better knowledge of TCP flows could maybe verify that. HTTPS messages are sent every 15 minutes and I'd expect various timers to timeout the connection if the ACKs aren't processed.
b) The receiving side somehow bounces the packets around, reinserting them after the TCP session is done. This would be weird. The server from which the posted logs and traces come from isn't running anything special like netgraph, bpf applications, routed. It's basically a web server.
signature.asc
Description: OpenPGP digital signature
