On Sun, 2002-12-08 at 19:14, Carlos E. R. wrote:
Yes, I mentioned that the other day. I'm thinking that it could be the same packet, allowed entry, and then dropped because ther is no handler for it (no daemon listening).
Dec 8 20:27:56 nimrodel kernel: SuSE-FW-ACCEPT IN=ppp0 OUT= MAC= SRC=193.152.43.8 DST=193.152.137.135 LEN=44 TOS=0x00 PREC=0x00 TTL=252 ID=48243 DF PROTO=TCP SPT=37021 DPT=5327 WINDOW=8760 RES=0x00 SYN URGP=0 OPT (020405B4) Dec 8 20:27:56 nimrodel kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC= SRC=193.152.43.8 DST=193.152.137.135 LEN=44 TOS=0x00 PREC=0x00 TTL=252 ID=48243 DF PROTO=TCP SPT=37021 DPT=5327 WINDOW=8760 RES=0x00 SYN URGP=0 OPT (020405B4)
Opps, I missed the original post on that thread. After seeing the original question that you posted with the firewall logs, that's pretty much exactly how mine are. However, if a packet gets past the SuSE firewall script and is dropped due to the port being closed, is that not handled by ippl? I noticed that some dropped packets have the "SuSE-FW" prefix, while others have the "ippl" prefix. So, in our case, ippl is not recording the passed package, but SuSE firewall script still has it. This is kind of bugging me, since I am wondering if I have to ditch the SuSE Firewall2 script altogether (because it is being flaky and unreliable, so it seems), and create an IPTables set of rules on my own (big pain to do so, too, I'd rather amend the SuSE Firewall one). Any further info on this much appreciated. -Jeric -- JericAtSbcglobalDotNetwork 9:13pm up 18 days, 13:01, 7 users, load average: 3.08, 3.15, 3.16