# What does this log mean?



## cpalui (Jan 24, 2013)

Hello,

*W*hen *I* use *F*irefox, and after *I* close it, *I* have this kind of ipfw log:

```
Jan 24 18:36:02 asus kernel: ipfw: 299 Deny TCP 192.168.1.14:38745 184.169.110.33:80 out via wlan0
Jan 24 18:36:04 asus kernel: ipfw: 299 Deny TCP 192.168.1.14:28441 178.33.248.133:80 out via wlan0
Jan 24 18:36:33 asus kernel: ipfw: 299 Deny TCP 192.168.1.14:24162 77.67.11.91:80 out via wlan0
Jan 24 18:36:39 asus kernel: ipfw: 299 Deny TCP 192.168.1.14:58590 2.20.223.144:80 out via wlan0
Jan 24 18:36:51 asus kernel: ipfw: 299 Deny TCP 192.168.1.14:30423 149.20.54.209:80 out via wlan0
```
The addresses can lead to *G*oogle, freebsd FreeBSD, white pages or anything else. Why do *I* call these addresses by these ports, that *I* can't see in *W*ireshark (but *I* don't know it very well) after *I* close *F*irefox?


----------



## SirDice (Jan 25, 2013)

Please post your ruleset. It's possible the firewall thinks the session is already closed when Firefox tries to tear down those sessions.


----------



## cpalui (Jan 25, 2013)

```
$cmd 00010 allow all from any to any via lo0
$cmd 00015 check-state

$cmd 00110 allow tcp from any to 192.168.1.1 53 out via $pif setup keep-state
$cmd 00111 allow udp from any to 192.168.1.1 53 out via $pif keep-state
$cmd 00120 allow udp from any to 192.168.1.1 67 out via $pif keep-state
$cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state
$cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state
$cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root
$cmd 00260 allow udp from any to any 123 out via $pif keep-state

$cmd 00299 deny log all from any to any out via $pif

$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif
$cmd 00301 deny all from 172.16.0.0/12 to any in via $pif
$cmd 00302 deny all from 10.0.0.0/8 to any in via $pif
$cmd 00303 deny all from 127.0.0.0/8 to any in via $pif
$cmd 00304 deny all from 0.0.0.0/8 to any in via $pif
$cmd 00305 deny all from 169.254.0.0/16 to any in via $pif
$cmd 00306 deny all from 192.0.2.0/24 to any in via $pif
$cmd 00307 deny all from 204.152.64.0/23 to any in via $pif
$cmd 00308 deny all from 224.0.0.0/3 to any in via $pif
$cmd 00310 deny icmp from any to any in via $pif
$cmd 00315 deny tcp from any to any 113 in via $pif
$cmd 00320 deny tcp from any to any 137 in via $pif
$cmd 00321 deny tcp from any to any 138 in via $pif
$cmd 00322 deny tcp from any to any 139 in via $pif
$cmd 00323 deny tcp from any to any 81 in via $pif
$cmd 00330 deny all from any to any frag in via $pif
$cmd 00332 deny tcp from any to any established in via $pif
$cmd 00360 allow udp from any to 192.168.1.1 67 in via $pif keep-state

$cmd 00499 deny log all from any to any in via $pif
$cmd 00999 deny log all from any to any
```
*T*hank *Y*ou*.*


----------



## m_zebardast (Feb 23, 2013)

I think that these are stalled or timed out connections that initiated from your network.


----------



## nuxthrou (Feb 25, 2013)

Hi,

Does this streamed error log bother you?
Does this streamed error log affect your FreeBSD Server from accessing or streaming from the network's resources?

If it is not then leave it. It is just like that by default - where rules are set by your ipfw. If you want to get rid of that error, you must check the ipfw rule set and comment out the matched part.




			
				cpalui said:
			
		

> Hello,
> 
> *W*hen *I* use *F*irefox, and after *I* close it, *I* have this kind of ipfw log:
> 
> ...


----------



## qsecofr (Feb 26, 2013)

I might interpret it as being IPFW rejected the traffic @ rule #299 because the packets did not have the setup flags set, and were not already in the state table.  Just simply no match on the prior 7 rules.

You might, if appropriate for you, try adding a rule #298 to allow out and log packets that are established on ports 80,443.  If any packets were to match, then at least you'd have a better idea of the traffic and possibly how to handle it.

Having said that, I've got no idea idea what role Firefox plays after it's been closed.


----------



## RusDyr (Feb 28, 2013)

Or it may be because allowed dynamic rule (00200) has already expired at that moment, while Firefox trying to close connection at the end. I would recommend see dynamic rules also:
`# ipfw -d show`
and see by tcpdump() which TCP flags on that packets.


----------

