IPFW - Allowed but Denied is shown in my logs
Srot BULL
pwd8jmr22w at me.point.ne.jp
Wed Aug 4 04:50:41 PDT 2004
> 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
More information about the freebsd-questions
mailing list