IPFW - Allowed but Denied is shown in my logs

[Matthew Seaman]

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

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.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040804/d012273b/attachment.bin