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

Reply via email to