Hi all,
Today i googled a little and found someone saying that this problem
could be something related with exhaustion of mbuf's. Then i executed a
netstat -m im my test firewall, which was running with sticky-address,
and it was with it's mbuf's ok. Then i used the sticky-address in my
ma
Berk D. Demir wrote:
> Because source tracking entries lives with state entries. As soon as the
> state between the peers expire, your source tracking entry also
> disappears by default.
> Setting the time out "src.track" to any value other than zero (0) (whic
> is the default value) will tell the
Then you might tell me why, even with a source track entry set directing
traffic from one internal ip to one specific gateway, the packets
sometimes are redirected to the other gateway?
Because source tracking entries lives with state entries. As soon as the
state between the peers expire, your
Berk D. Demir wrote:
> Giancarlo Razzolini <[EMAIL PROTECTED]> wrote:
>> Hi all,
>> [.. cut ..]
>> Then, when i putted the sticky-address in the main firewall, strange
>> things happened. The source-tracking states were created, but the
>> machines, sometimes, were directed to the other link, n
Giancarlo Razzolini <[EMAIL PROTECTED]> wrote:
Hi all,
[.. cut ..]
Then, when i putted the sticky-address in the main firewall, strange
things happened. The source-tracking states were created, but the
machines, sometimes, were directed to the other link, not the one in the
source-track.
Hi all,
I've been having a headache using the round-robin with the
sticky-address option. I do have two exit links, and I'm doing load
balancing with the round-robin on the outgoing packets from the internal
net and from my other 2 dmz's. This setup works perfectly with some
exceptions. Th
6 matches
Mail list logo
