tomasz dereszynski wrote: > Ciprian Marius Vizitiu wrote: > >> Hi listers, >> >> I have a strange firewall problem with Bacula 2.2.6 running on RHEL4 >> [...] >> >> 18:32:01.504760 IP server.gbif.org.9103 > client.gbif.org.32776: P >> 1560794395:1560794427(32) ack 1414218623 win 181 <nop,nop,timestamp >> 4070418385 22509939> >> 18:32:01.504801 IP client.gbif.org > server.gbif.org: icmp 92: host >> client.gbif.org unreachable - admin prohibited >> 18:32:01.505214 IP server.gbif.org.9103 > client.gbif.org.32776: . >> 32:1480(1448) ack 1 win 181 <nop,nop,timestamp 4070418386 22509939> >> 18:32:01.505231 IP client.gbif.org > server.gbif.org: icmp 556: host >> client.gbif.org unreachable - admin prohibited >> 18:32:01.505236 IP server.gbif.org.9103 > client.gbif.org.32776: . >> 1480:2928(1448) ack 1 win 181 <nop,nop,timestamp 4070418386 22509939> >> 18:32:01.505249 IP client.gbif.org > server.gbif.org: icmp 556: host >> client.gbif.org unreachable - admin prohibited >> >> To me it looks like the essence of the problem is the fact that the >> restore session has a long "network idle" period and somehow the RELATED >> mechanism of the firewall no longer works. WHY would this happen? And >> more important, isn't this what HeartBeat was supposed to prevent in the >> first place? One more detail: if the client is RHEL5 everything works >> perfectly. >> > not sure fo 100% but looks a bit like TCP TTL > dont think FW will wait that long and it has nothing to do with heartbeat. > will say/guess as your FW treat it as session closed or timed out cos of > idle time > > check if you can manage TTL for TCP on FW. Hi Tomasz,
First, there was an obvious mistake in my original message: things happen with the firewalls started. o:-) I'm confident that the problem is on the client RHEL4 firewall. A *silly* :-) workaround would be to add -A RH-Firewall-1-INPUT -p tcp -s 192.168.1.48 --sport 9101:9103 -j ACCEPT ... on the client; problem fixed so far. But again, this is not supposed to happen. And further more, stepping back (and closer to my original configuration), the following config works: CentOS5 Server ---> RHEL4 firewall with "RELATED" ---> RHEL5 client Which might mean the bug's not necessarily in the firewall code or the timeout would have shown up as a consequence of passing the traffic through a "buggy" firewall wouldn't it? Before anyone asks, I've also looked in the Cisco console for strange things happening to any of the interfaces implicated: "0 errors" ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users