On Sun, Jan 25, 2004 at 03:50:22PM -0800, Scott L. Burson wrote: > I repeat, this ruleset had been working fine with `synproxy state' for a > good 3 weeks, and I don't think this was even the first time I had rebooted > the firewall. Could I have changed something that made synproxy stop > working? Conceivably, but I have no idea what and don't recall changing > anything.
Something must have changed, try to find out what (even if it seems impossible that it is related). Either the system was updated (when, from/to what version?) or the ruleset has changed (what rules?). If you changed nat rules, that might be a reason. synproxy doesn't work with some nat translations (never did), for instance nat on $ext_if from 10.0.0.0/8 to any -> 62.65.145.30 pass in on $int_if from 10.0.0.0/8 to any synproxy state When 10.1.2.3 connects to 129.128.5.191, synproxy will first handshake with the client (which works), but then replay the handshake with 129.128.5.191 through $ext_if, without applying the nat translation. If this is what happens, it should be easy to spot with tcpdump -nvvvS running on all interfaces, capturing one failing TCP connection attempt. The handshake packets generated by synproxy are always passed unconditionally (without matching/creating state or getting translated further on subsequent interfaces). Without a tcpdump it's hard to tell. Daniel
