On Thu, Jan 16, 2014 at 8:26 PM, Stuart Henderson <s...@spacehopper.org> wrote: > This could be an MTU or RWIN-related issue. One common problem is if the > firewall state is created from an already-established connection rather > than a SYN packet, in this case the firewall can't keep track of the > RWIN value which is set by many modern OS, and needed in order for a > stateful firewall to track the conection
Makes sense but there are no other connections between said devices when the problem occurs. Connections only occur when I manually attempt to connect to the firewall itself (ssh), or an inside system, plus a cron job that runs at approx. 4am for an rsync backup. The manual attempts are only bothersome because such random failures don't happen with any other of my remote networks and I can easily re-try (which so far has always worked). The backup is another story as some data doesn't get backed up when the random failure occurs. The rsync cron job does attempt to backup two different directories and so connects twice; it's only the first attempt that fails (no matter which one I attempt to backup first) and so acts just like a failed ssh attempt to the firewall itself - a new attempt immediately after always works. > To avoid the risk of this I usually start pf rulesets with "block log" I do use a "block all" very near the beginning of the ruleset, although I generally put a 'pass in quick for ssh' before the "block all" to make sure I never make a change that prevents a remote shell in. I can see that the leading 'pass in' isn't all that necessary and have moved the "block all" to the beginning of the ruleset to see if it will make any difference. Thank you, Chris
