Date: Wed, 04 Aug 2004 20:49:46 +0900 From: Srot BULL <pwd8jmr22w@me.point.ne.jp> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: freebsd-questions@freebsd.org Subject: Re: IPFW - Allowed but Denied is shown in my logs Message-ID: <4110CD5A.6090207@me.point.ne.jp> In-Reply-To: <20040804095511.GA54595@happy-idiot-talk.infracaninophile.co.uk> References: <41109ABF.4090904@me.point.ne.jp> <20040804095511.GA54595@happy-idiot-talk.infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Wed, Aug 04, 2004 at 05:13:51PM +0900, Srot BULL wrote: >>I have been seeing these logs since I started using my firewall but >>since I am not having problems in my incoming-outgoing emails and access >>to websites I did not bother to change anything...But, Looking at my >>firewall logs and seeing the same things just woke up my curiousity and >>wondered if anybody can enlighten me on what is happening... >> >>Below are some of the information that I have copied from my >>/var/log/security and pasted here: >> Aug 4 10:57:26 r40e kernel: ipfw: 299 Deny TCP 192.168.1.35:49312 >>130.89.175.51:80 out via bge0 >> Aug 4 11:00:49 r40e kernel: ipfw: 299 Deny TCP 192.168.1.35:49312 >>130.89.175.51:80 out via bge0 >> Aug 4 11:33:45 r40e kernel: ipfw: 299 Deny TCP 192.168.1.35:49352 >>69.55.225.12:80 out via bge0 >> Aug 4 11:34:10 r40e last message repeated 5 times >> Aug 4 11:36:16 r40e last message repeated 3 times >> Aug 4 11:40:32 r40e last message repeated 4 times >> Aug 4 12:21:10 r40e kernel: ipfw: 299 Deny TCP 192.168.1.35:49364 >>195.92.249.252:80 out via bge0 >> Aug 4 12:21:41 r40e last message repeated 6 times >> Aug 4 12:22:55 r40e last message repeated 2 times >> Aug 4 12:27:11 r40e last message repeated 4 times >> Aug 4 13:24:14 r40e kernel: ipfw: 299 Deny TCP 192.168.1.35:49386 >>216.136.204.21:80 out via bge0 >> Aug 4 13:24:34 r40e last message repeated 5 times >> Aug 4 13:26:26 r40e last message repeated 3 times >> Aug 4 13:30:42 r40e last message repeated 4 times >> Aug 4 15:04:19 r40e kernel: ipfw: 299 Deny TCP 192.168.1.35:49456 >>210.188.175.94:110 out via bge0 >> Aug 4 15:04:46 r40e last message repeated 7 times >> Aug 4 15:06:04 r40e last message repeated 2 times >> Aug 4 15:08:38 r40e last message repeated 3 times >> Aug 4 15:36:28 r40e kernel: ipfw: 299 Deny TCP 192.168.1.35:49487 >>164.46.152.13:110 out via bge0 >> Aug 4 15:36:28 r40e kernel: ipfw: 299 Deny TCP 192.168.1.35:49486 >>164.46.152.13:110 out via bge0 >> Aug 4 15:36:28 r40e kernel: ipfw: 299 Deny TCP 192.168.1.35:49487 >>164.46.152.13:110 out via bge0 >> Aug 4 15:44:42 r40e kernel: ipfw: 299 Deny TCP 192.168.1.35:49504 >>205.180.85.140:80 out via bge0 >> Aug 4 15:45:15 r40e last message repeated 6 times >> Aug 4 15:46:44 r40e last message repeated 2 times >> Aug 4 15:51:00 r40e last message repeated 4 times >>This is found in my /etc/ipfw.rules >>### Allow out non-secure standard www function ### >>$CMD 00200 allow tcp from any to any 80 out via $IFN setup keep-state >>### Allow out send & get email function ### >>$CMD 00230 allow tcp from any to any 25 out via $IFN setup keep-state >>$CMD 00231 allow tcp from any to any 110 out via $IFN setup keep-state >>### deny and log everything else that's trying to get out. ### >>### This rule enforces the block all by default logic. ### >>$CMD 00299 deny log all from any to any out via $IFN > Matthew Seaman wrote: > Hmmm... Looks weird, doesn't it: your firewall is denying packets > going out of your machine to various internet web or pop3 servers. > But network access still works fine. > What's happening it this: there's some sort of delay between your > system and the remote system which means that the exchange of FIN > packets to close down the connection takes so long that the stateful > rule times out in the mean time. There is such a delay built into the > TCP protocols in order to maximise the chances for any packets that > have got a bit lost in transit to finally make it to their > destinations. > If you look at your netstat(1) output after a session of web browsing > you'll probably see a number of connections apparently stuck in the > 'CLOSING' or 'FIN_WAIT' or similar state -- I'd have to look up the > details to be sure exactly which. > Now, since this only occurs after you've decided to shut down the > connection, it's not a disaster. Unless it's happening to a > ridiculous extent, you can probably just ignore it: eventually the > networking code will timeout the connection and tidy everything up. > On the other hand, and particularly if you're running a busy server > and can't afford to have mouldering old connections taking up kernel > resources, there are various things you can try. There are several > sysctls you can play with to ameliorate things. Look at the tuning(7) > man page, particularly the sections on the following sysctls: > > net.inet.tcp.always_keepalive > > net.inet.tcp.delayed_ack > > You might also want to fiddle with some of the > net.inet.ip.fw.dyn_*_lifetime timers, but such things are not > recommended for novices to play with -- get the numbers wrong and you > can end up with a system that can't talk over the network reliably. > Hi, Thank you for your explanation, I will try to go on again on what your trying to explain to me...Frankly speaking I am not that knowledgeable in networking...but I am trying my best to learn... If it is not going to bite me that maybe I should let things be...Just to be on the safe side...Of course, I will take a look again on the tuning manpage... I posted this email because, I was worried that something big is wrong with my settings... I have a laptop in the office and a desktop in my apartment that has almost identical settings from my X Window Systems to my firewall rulesets... As long as there are no major problems I leave things for now...and maybe someday I will be able to create a more suitable ruleset for my systems... Once again thank you very much... Have a nice day to all of you... Srot BULL
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4110CD5A.6090207>