-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ciprian Marius Vizitiu wrote:
> 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:-)
guessed that.
>
> 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
>
what means you dont have/need TCP TTL
> ... 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?
timeout isnt a bug
>
> Before anyone asks, I've also looked in the Cisco console for strange
> things happening to any of the interfaces implicated: "0 errors"
>
i do not claim as i am 100% right but in such a scenario you will not
see any errors on firewall or router/anything as it isnt error in this
terms. just timeout.
- --
bEsT rEgArDs | "Confidence is what you have before you
tomasz dereszynski | understand the problem." -- Woody Allen
|
Spes confisa Deo | "In theory, theory and practice are much
numquam confusa recedit | the same. In practice they are very
| different." -- Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHnwuA5GTLLfVywbsRAg5VAKCZT1DkRnsZbQ+Eusq8X3VkhHmKuACfdksZ
/ToKBTYXFpiCkOpPM0PJYlY=
=8nYI
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
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
