--On Saturday, 9 December 2000 3:13 PM Manuel Bouyer wrote:
>> > How-To-Repeat:
>> see below "Fix to the problem if known" for more details.
>> > Fix:
>> "ipf -D" followed by "ipf -E -Fa -f /etc/ipf.conf" will fix the problem
>> a few times. Finally only a "ipf -D" will allow any traffic at all. A
>> reboot is then necessary to achieve the use of any filter rules.
>
> Do you use NAT in addition to IPF ? Did this work with 1.4.2 ?
> While the traffic is blocked, could you run tcpdump on both interfaces
> and see what traffic there is ?

I did not use 1.4.2 (problems with AppleTalk), I have upgraded from 1.4.1.

I do use NAT (1 rule, last minute patch not applied). Rule follows..

map ppp0 192.168.1.0/24 -> 203.43.154.193/32

My NAT & ipf config have not changed since 1.4.1 in reference to the 
services that fail.

I have compiled a seperate kernal that logged blocked packets. The ipmon 
log (local0) showed along with others (squid) that the return packets were 
being blocked (yes I have set the "keep state"). Sample ipmon log entry 
follows...

Dec  6 17:47:26 hermes ipmon[79]: 17:47:25.335973             ppp0 @0:15 b 
mail2.bigpond.com,25 -> mx.nemostar.com.au,65211 PR tcp len 20 65 -AFP IN

Rule 15 is the catch all "block all" rule.

At the moment I am not using ipf (ipf -D) and all packets are getting 
through fine. I have switched back to the GENERIC kernal.

The interface that is being blocked is the ppp interface (modem). Please 
advise the command that you wish me to run and I can forward the output.

It is curious that that it fails after quite an amount of traffic has 
passed through the interface.

Thanks in advance.

--
Stephen.