Investigating on the problem I discover that the pop3 client reuse the
tcp source port when it make the connection causing pf to drop the sync
packets due to a BAD state error.
Solution: change pop3 client or lower the timeout tcp.closed value (in
the normal optimization mode the value is 90s).
I hope that may contribute to global know-how...
Paolo
Paolo Perrucci ha scritto:
It seems that today it's not a good day...
I have a pop3 server in the LAN protected by the firewalls and today
some users reported that they can't connect to the server. Debugging
the problem with one of this user I noticed that sometimes the user
syn packets doesn't reach the internal server. I always see the packet
on the external interface of the firewall (xl0) but, sometimes, I
don't see the packets on the internal interface (xl1). pf logs all
blocked packets and checking the pf logs I can't see any evidence of
this packets. It seems that they doesn't get forwarded to the internal
interface.
Is there another way to debug the problem ?
Thanks
Paolo
Paolo Perrucci ha scritto:
Hi all,
I'm trying to setup an ha firewall using carp and pfsync.
I tried 3.6 and 3.7 version but both test fails with different kernel
panic.
In my last attempt I used the 3.7 version (-stable) on both the
firewall but after some hours the primary box fails with this kernel
panic:
panic: kernel diagnostic assertion "state->timeout < PFTM_MAX"
failed: file "/usr/src/sys/net/pf.c", line 887
Stopped at Debugger+0x4: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb> Debugger(e388eed8,d06d2000,d06d3df4,d5e22000,d5e22000) at
Debugger+0x4
panic(d04dea80,d04affb7,d04d5c83,d04d5c9d,377) at panic+0x63
tablefull(d04affb7,d04d5c9d,377,d04d5c83,d05ab760) at tablefull
pf_purge_expired_src_nodes(d5e22000,ffffffff,d0563170,d06d3e30,20) at
pf_purge_expired_src_nodes
pf_purge_expired_states(30,d01feb16,d0b68a80,d06d3e54,d01021b1) at
pf_purge_expired_states+0x33
pf_purge_timeout(d05ab72c,5305,3,0,0) at pf_purge_timeout+0x15
... (the ddb log stop here)
Is there someone that used OpenBSD in a similar configuration ?
Paolo