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

Reply via email to