Nabble - freebsd-ipfw

ipfw nat

2009-11-20T11:03:14Z

Unless I'm mistaken, there appears no way to cause ipfw's internal
nat mechanism to log dropped packets. This is a considerable loss
of functionality from using natd. Is there a reason for this?

- M

--
Michael Sierchio
+1 415 378 1182
PO Box 9036 Berkeley CA 94709 US
kudzu@...
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Problem Posting to League 'ipfw'

2009-11-17T02:25:16Z

In order to send an e-mail to your league, the e-mail address which you
are sending from must be associated with your team. You will need to
update your e-mail address within the league, otherwise, your
correspondence will be denied.

To update your e-mail address, enter your league home page and select
Options, Personal. You can enter more than one e-mail address by separating
them with a comma and a space.
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: Dansguardian, nat, & ipfw

2009-11-16T21:37:11Z

On Mon, Nov 16, 2009 at 8:51 PM, Brian <bbayorgeon@...> wrote:
> Trying to configure my gateway box running FBSD 7.2 to provide content
> filtering services for some or all clients on a my network.
>
> The box is configured with natd and running IPFW. I like this combination
> and have been using it successfully for years. Not real interested to
> changing to squid or pf or whatever else may be known (or better documented)
> to work with dansguardian.

Dansguardian does not do any pages fetches on its own, it just scans
pages returned by a proxy server. You cannot run Dansguardian without
some kind of web proxy server. By default, the port will install
Squid, but it has been shown to work with TinyProxy.

> Dansguardian seems to be the preferred option for content filtering as near
> as I can tell. There is lots of documentation out there for configuring
> dans with squid. I can't find much of anything for IPFW / NAT
>
> So, the question is, can this be done? I've seen one or two suggestions out
> there giving a brief description of how to use the fwd command to send
> packets to dans but unfortunately I am not smart enough to implement that
> here.

You can use IPFW to fwd packet to Dansguardian quite easily:
ipfw add fwd 127.0.0.1:8080 tcp from $local_subnet to any 80 in recv
$local_nic
ipfw add allow tcp from me to any 80 out xmit $public_nic
ipfw add allow tcp from any 80 to me in recv $public_nic established

The first rule redirects all HTTP traffic from the local subnet to
Dansguardian. Dansguardian will then pass the packets off to a local
install of Squid (uses 127.0.0.1:3128 by default). Squid will then
connect out to the remote web server to grab the pages (the next two
rules).

You *MUST* have a web proxy server installed somewhere, that
Dansguardian will forward the requests to, and receive the responses
from.

--
Freddie Cash
fjwcash@...
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

dansguardian, ipfw, nat question

2009-11-16T20:54:41Z

Hello all

Trying to configure my gateway box running FBSD 7.2 to provide content
filtering services for some or all clients on a my network.

The box is configured with natd and running IPFW. I like this combination
and have been using it successfully for years. Not real interested to
changing to squid or pf or whatever else may be known (or better documented)
to work with dansguardian.

Dansguardian seems to be the preferred option for content filtering as near
as I can tell. There is lots of documentation out there for configuring
dans with squid. I can't find much of anything for IPFW / NAT

So, the question is, can this be done? I've seen one or two suggestions out
there giving a brief description of how to use the fwd command to send
packets to dans but unfortunately I am not smart enough to implement that
here.

Any help, thoughts, or references would be appreciated

thanks

Brian

here is a boiled down set of rules that I use:

#!/bin/sh

cmd="ipfw add"

skip="skipto 700"

oif=dc0

iif=re0

log="log logamount 1000"

ks="keep-state"

ipfw -f flush

$cmd 098 allow all from any to any via $iif #
Allow LAN traffic

$cmd 099 allow all from any to any via lo0 #
Allow loopback traffic

$cmd 105 divert natd all from any to any in via $oif # check if
packet is inbound and nat address if it is

$cmd 110 check-state
# Allow packet if it has previous been added to the "dynamic" rules table

### Authorized icmp / udp outbound packets

$cmd 200 $skip icmp from any to any out via $oif $ks
# ping

$cmd 201 $skip udp from any to any 123 out via $oif $ks
# time

$cmd 203 $skip $log udp from any to xx.xxx.xx.1 67 out via $oif $ks
# DHCP

$cmd 205 $skip udp from any to any 53 out via $oif $ks
# DNS

### Authorized tcp outbound packets

$cmd 301 $skip tcp from any to any 25 out via $oif setup $ks
# mail

$cmd 303 $skip $log tcp from any to any 43 out via $oif setup $ks
# whois

$cmd 305 $skip tcp from any to any 80 out via $oif setup $ks
# http

$cmd 306 $skip tcp from any to any 110 out via $oif setup $ks
# mail

$cmd 307 $skip tcp from any to any 119 out via $oif setup $ks
# USENET

$cmd 308 $skip tcp from any to any 443 out via $oif setup $ks
# Secure http

$cmd 310 $skip $log tcp from any to any 23 out via $oif setup $ks
# telnet

### Everything else outbound is dropped and logged

$cmd 351 deny log logamount 10000 all from any to any out via $oif
# everything else

### Allow these incoming connections

$cmd 360 allow $log udp from xx.xxx.xxx.x to any 68 in via $oif $ks
# DHCP

$cmd 363 allow tcp from any to me 80 in via $oif setup
$ks # Incoming http connections

### May Consider Allowing these incoming connections

$cmd 396 allow $log tcp from any to any 113 in via $oif limit
src-addr 4 # Ident packets.

$cmd 398 allow $log icmp from any to any icmptype 3,11 in via $oif
limit src-addr 2 # Allow out & in console traceroot command

### deny various incoming packets

$cmd 401 deny $log all from 192.168.0.0/16 to any in via $oif # RFC 1918
private IP

$cmd 402 deny $log all from 172.16.0.0/12 to any in via $oif # RFC 1918
private IP

$cmd 403 deny $log all from 10.0.0.0/8 to any in via $oif # RFC 1918
private IP

$cmd 404 deny $log all from 127.0.0.0/8 to any in via $oif # loopback

$cmd 405 deny $log all from 0.0.0.0/8 to any in via $oif # loopback

$cmd 406 deny $log all from 169.254.0.0/16 to any in via $oif # DHCP
auto-config

$cmd 407 deny $log all from 192.0.2.0/24 to any in via $oif # reserved
for docs

$cmd 408 deny $log all from 204.152.64.0/23 to any in via $oif # Sun
cluster

$cmd 409 deny $log all from 224.0.0.0/3 to any in via $oif # Class D &
E multicast

### deny various incoming packets

$cmd 448 reset $log tcp from any to me 113 in via $oif limit src-addr 4 #
This sends a RESET to all ident packets.

$cmd 449 deny $log tcp from any to any 113 in via $oif #
Deny ident

$cmd 450 deny $log icmp from any to any icmptype 5 in via $oif
# Stop & log external redirect requests.

$cmd 451 deny $log icmp from any to any in via $oif #
Deny pings from the world

$cmd 452 deny $log all from any to any in frag #
Fragmented Packets

$cmd 453 deny $log all from any to any 137,138,139,81 in via $oif #
Deny all Netbios service & MS/Windows hosts2 name server

$cmd 454 deny $log all from any to any frag in via $oif #
Deny any late arriving packets

$cmd 455 deny $log tcp from any to any established in via $oif #
Deny ACK packets that did not match the dynamic rule table

$cmd 456 deny $log all from me to me in via $oif
# Stop & log spoofing Attack attempts.

$cmd 457 deny all from any to any 1024-1030 in via $oif #
MS Messenger spam

### Reject & Log all the rest of the incoming connections

$cmd 600 deny log logamount 10000 all from any to any in via $oif

### deny and log all packets that fell through to see what they are

### Nothing should ever get to this rule!!!

$cmd 601 deny log logamount 10000 all from any to any

### This is skipto location for outbound stateful rules

$cmd 700 divert natd all from any to any out via $oif

$cmd 800 allow all from any to any

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Dansguardian, nat, & ipfw

2009-11-16T20:51:44Z

Current problem reports assigned to freebsd-ipfw@FreeBSD.org

2009-11-16T03:06:55Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth
o kern/139226 ipfw [ipfw] install_state: entry already present, done
o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken
o kern/137232 ipfw [ipfw] parser troubles
o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul
o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o
o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file.
o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port
o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke
o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0)
o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior
o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho
o kern/129103 ipfw [ipfw] IPFW check state does not work =(
o kern/129093 ipfw [ipfw] ipfw nat must not drop packets
o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n
o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets
o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l
o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes
o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit
o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6
o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip
s kern/121807 ipfw [request] TCP and UDP port_table in ipfw
o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor
o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields
o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem
o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s
o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4
o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from
o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form
o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule
p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec
o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c
o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets
o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work
o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q
o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a
o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a
o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b
o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table
o kern/102471 ipfw [ipfw] [patch] add tos and dscp support
o kern/98831 ipfw [ipfw] ipfw has UDP hickups
o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to
o kern/97504 ipfw [ipfw] IPFW Rules bug
o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v
o kern/93300 ipfw [ipfw] ipfw pipe lost packets
o kern/91847 ipfw [ipfw] ipfw with vlanX as the device
o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul
o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation
o kern/86957 ipfw [ipfw] [patch] ipfw mac logging
o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou
s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION
o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir
o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp
o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT
o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes (
o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a
o kern/69963 ipfw [ipfw] install_state warning about already existing en
o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes
o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw
o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent
o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags
o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f
a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau

63 problems total.

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

FW: HELP ME

2009-11-12T10:09:07Z

Hi

Me again

Sorry my good friend . I can`t config my ipfw very well .

If you can send a sample ipfw config which is works fine you will give me a
great help.

Sample config with this type of pipe rule , and my ipfw deny everythin by
default.

$cmdfw pipe 30 config mask dst-ip 0x000000ff bw 1024Kbit/s queue 10KBytes
$cmdfw pipe 31 config mask src-ip 0x000000ff bw 256Kbit/s queue 10KBytes

$cmdfw add 1100 pipe 30 all from any to 192.168.6.0/24 in via $ext_if1
$cmdfw add 900 pipe 31 all from 192.168.6.0/24 to any out via $ext_if1
$cmdfw add 1000 divert natd ip from any to any via $ext_if1

Thanx a lot

Regard

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: HELP ME

2009-11-10T10:21:31Z

Hi--

On Nov 10, 2009, at 4:40 AM, Nima Mohammadi wrote:
> i have a freebsd 7.1 with ipfw and dummynet and natd and all the
> things is
> good. but the i can not limite the upload to the internet with
> dummynet.
> the download limit works fine .
>
> when change the pipe2 (to me in ) to ( to any in) the internet
> connection of
> my client will be down

Try something like:

ipfw add pipe 2 ip from ${iuser} to any out via nfe0

Regards,
--
-Chuck

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: HELP ME

2009-11-10T09:56:13Z

On Tue, Nov 10, 2009 at 6:40 AM, Nima Mohammadi <it@...> wrote:

> Hi
> i have a freebsd 7.1 with ipfw and dummynet and natd and all the things is
> good.
> but the i can not limite the upload to the internet with dummynet.
> the download limit works fine .
>
>
>
> when change the pipe2 (to me in ) to ( to any in) the internet connection
> of
> my client will be down
> vr0 : internal net : 192.168.10.0/24
> nfe0: out net : 212.80.13.1 ,2 ,3
>
> the upload is very high .
> HELP ME
>
> here is my ipfw config :
> pfw -q -f flush
>
> #Dedicate internet user and non internet user
>
> ############################################################################
> #
> #charter 55 for ali shirali movaghat share with andishgar
>
> iuser="192.168.10.0/24{1,3,25,
> <
> http://192.168.10.0/24%7B1,3,25,27,31,42,48,50,53,54,55,63,69,81,84,88,92,9
> 8,100,105,118,128,131,134,135,137,140,155,165,171%7D>
>
> 27,31,42,48,50,53,54,55,63,69,81,84,88,92,98,100,105,118,128,131,134,135,137
> ,140,155,165,171}"
>
> noiuser="192.168.10.0/24{44, <http://192.168.10.0/24%7B44,46%7D> 46}"
>
> ############################################################################
> ##
>
>
> ##########################dummynet##########################################
> #
> #recive
> ipfw -q add pipe 1 ip from any to ${iuser} out via vr0
> ipfw pipe 1 config bw 9KByte/s # queue 11 delay 100ms
>
> #send
> ipfw -q add pipe 2 ip from ${iuser} to me in via vr0
> ipfw pipe 2 config bw 7KByte/s # queue 11 delay 100ms
>
> ############################################################################
> #
>
>
> ##################################NAT#######################################
> ##
> ipfw -q add divert natd all from any to any via nfe0
> ipfw -q add check-state
>
> ############################################################################
>
> #block any to loopback
> ipfw -q add allow ip from any to any via lo0
> ipfw -q add deny ip from any to 127.0.0.0/8
>
> #########################END internet
> users##################################
>
> #web & ssl & yahoo messenger
> ###################WEB Accsess##############################
> ipfw -q add allow tcp from ${iuser} to any 80,443,5050 keep-state
>
> #allow all http to internal
> ipfw -q add allow tcp from any to any 80 in via nfe0 keep-state
>
> #charter 10 access on ghd24.net
> #ipfw -q add allow tcp from 192.168.10.64 to 66.49.211.210,94.182.197.230
> 80
> keep-state
> ######################END Web Access#########################
>
> #aseman
> ipfw -q add allow tcp from any to any 7769 keep-state
>
> #amadeus
> ipfw -q add allow tcp from any to any 9876,10000 keep-state
>
> #air tour
> ipfw -q add allow tcp from any to any 1770 keep-state
>
> #ftp
> ipfw -q add allow ip from any to any 21 keep-state
> #ipfw -q add allow ip from any to any 1024-65535 keep-state
> ipfw -q add allow tcp from 192.168.10.69,192.168.10.1,192.168.10.9 to any
> 1024-65535 keep-state
> ipfw -q add allow tcp from any 1024-65535 to 192.168.10.1 keep-state
>
> #ipfw -q add check-state
>
> #DNS
> ipfw -q add allow ip from any to any 53 keep-state
> ipfw -q add allow ip from any 53 to any keep-state
>
> #remote
> ipfw -q add allow ip from any to any 35252,12114,3389 keep-state
>
> #mysql remote
> #ipfw -q add allow ip from any to any 3306,1433 keep-state
>
> #share
> #ipfw -q add allow tcp from any to me 139
> #ipfw -q add allow tcp from any 139 to any
>
> #ping
> ipfw -q add allow icmp from any to any
>
> #cpanel
> #ipfw -q add allow ip from any to any 2082,2083,2095 keep-state
>
> #ssh
> ipfw -q add allow tcp from any to me 5432 keep-state
> ipfw -q add allow tcp from any 5432 to any keep-state
>
> #Out look pop3
> ######################POP3 Access#####################
>
> ipfw -q add allow tcp from ${iuser},${noiuser} to any 25 keep-state
> ipfw -q add allow tcp from ${iuser},${noiuser} to any 110 keep-state
>
> ######################END POP3 Access#################
> #gmail
> #ipfw -q add allow tcp from any to any 995,465 keep-state
>
> #Ghost Surf
> ipfw -q add allow tcp from any to any 8888 keep-state
>
> #VPN TO EXTRENAL
> ipfw -q add allow gre from any to any keep-state
> ipfw -q add allow tcp from any to any 1723 keep-state
>
> #allow all to external
> ipfw -q add allow ip from any to any out via nfe0
>
> #deny all in from external
> ipfw -q add deny all from any to any in via nfe0
>
> _______________________________________________
> freebsd-ipfw@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
>

Currently your IPFW rule for pipe 2 is only matching traffic sourced from
192.168.10.0/24 <http://192.168.10.0/24 nfe0> with a destination of "me", me
being any IP interface on your box, so your rule would work only if traffic
is destined to an IP on your box. Your IPFW rule for pipe 1 is matching on
any and works, I'd look at applying the same logic to your pipe 2 rule :)
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

HELP ME

2009-11-10T04:40:58Z

Hi
i have a freebsd 7.1 with ipfw and dummynet and natd and all the things is
good.
but the i can not limite the upload to the internet with dummynet.
the download limit works fine .

when change the pipe2 (to me in ) to ( to any in) the internet connection of
my client will be down
vr0 : internal net : 192.168.10.0/24
nfe0: out net : 212.80.13.1 ,2 ,3

the upload is very high .
HELP ME

here is my ipfw config :
pfw -q -f flush

#Dedicate internet user and non internet user
############################################################################
#
#charter 55 for ali shirali movaghat share with andishgar

iuser="192.168.10.0/24{1,3,25,
<http://192.168.10.0/24%7B1,3,25,27,31,42,48,50,53,54,55,63,69,81,84,88,92,9
8,100,105,118,128,131,134,135,137,140,155,165,171%7D>
27,31,42,48,50,53,54,55,63,69,81,84,88,92,98,100,105,118,128,131,134,135,137
,140,155,165,171}"

noiuser="192.168.10.0/24{44, <http://192.168.10.0/24%7B44,46%7D> 46}"
############################################################################
##

##########################dummynet##########################################
#
#recive
ipfw -q add pipe 1 ip from any to ${iuser} out via vr0
ipfw pipe 1 config bw 9KByte/s # queue 11 delay 100ms

#send
ipfw -q add pipe 2 ip from ${iuser} to me in via vr0
ipfw pipe 2 config bw 7KByte/s # queue 11 delay 100ms
############################################################################
#

##################################NAT#######################################
##
ipfw -q add divert natd all from any to any via nfe0
ipfw -q add check-state
############################################################################

#block any to loopback
ipfw -q add allow ip from any to any via lo0
ipfw -q add deny ip from any to 127.0.0.0/8

#########################END internet
users##################################

#web & ssl & yahoo messenger
###################WEB Accsess##############################
ipfw -q add allow tcp from ${iuser} to any 80,443,5050 keep-state

#allow all http to internal
ipfw -q add allow tcp from any to any 80 in via nfe0 keep-state

#charter 10 access on ghd24.net
#ipfw -q add allow tcp from 192.168.10.64 to 66.49.211.210,94.182.197.230 80
keep-state
######################END Web Access#########################

#aseman
ipfw -q add allow tcp from any to any 7769 keep-state

#amadeus
ipfw -q add allow tcp from any to any 9876,10000 keep-state

#air tour
ipfw -q add allow tcp from any to any 1770 keep-state

#ftp
ipfw -q add allow ip from any to any 21 keep-state
#ipfw -q add allow ip from any to any 1024-65535 keep-state
ipfw -q add allow tcp from 192.168.10.69,192.168.10.1,192.168.10.9 to any
1024-65535 keep-state
ipfw -q add allow tcp from any 1024-65535 to 192.168.10.1 keep-state

#ipfw -q add check-state

#DNS
ipfw -q add allow ip from any to any 53 keep-state
ipfw -q add allow ip from any 53 to any keep-state

#remote
ipfw -q add allow ip from any to any 35252,12114,3389 keep-state

#mysql remote
#ipfw -q add allow ip from any to any 3306,1433 keep-state

#share
#ipfw -q add allow tcp from any to me 139
#ipfw -q add allow tcp from any 139 to any

#ping
ipfw -q add allow icmp from any to any

#cpanel
#ipfw -q add allow ip from any to any 2082,2083,2095 keep-state

#ssh
ipfw -q add allow tcp from any to me 5432 keep-state
ipfw -q add allow tcp from any 5432 to any keep-state

#Out look pop3
######################POP3 Access#####################

ipfw -q add allow tcp from ${iuser},${noiuser} to any 25 keep-state
ipfw -q add allow tcp from ${iuser},${noiuser} to any 110 keep-state

######################END POP3 Access#################
#gmail
#ipfw -q add allow tcp from any to any 995,465 keep-state

#Ghost Surf
ipfw -q add allow tcp from any to any 8888 keep-state

#VPN TO EXTRENAL
ipfw -q add allow gre from any to any keep-state
ipfw -q add allow tcp from any to any 1723 keep-state

#allow all to external
ipfw -q add allow ip from any to any out via nfe0

#deny all in from external
ipfw -q add deny all from any to any in via nfe0

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Current problem reports assigned to freebsd-ipfw@FreeBSD.org

2009-11-09T03:06:55Z

Re: kern/115755: [ipfw] [patch] unify message and add a rule number where limit was reached

2009-11-08T07:34:37Z

Synopsis: [ipfw] [patch] unify message and add a rule number where limit was reached

State-Changed-From-To: patched->closed
State-Changed-By: gavin
State-Changed-When: Sun Nov 8 15:33:49 UTC 2009
State-Changed-Why:
I can't see this ever being merged to 6.x now as it changes the
format of the log file.

http://www.freebsd.org/cgi/query-pr.cgi?pr=115755
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: Diverting sockets and streams

2009-11-05T00:56:25Z

Jakub Bednar wrote:

> Hi Julian,
>
> thanks for making this clear to me.
>
>>
>>>
>>> so basically I have to implement part of the TCP stack in my app.
>>
>> yes,
>> though there may be other ways to do what you want..
>> what DO you want to do?
>>
>
> I need to make a transparent proxy e.g. HTTP proxy, that will be able to
> scan the data stream for some security problems (exploits or whatever).
>
> I had a solution based on packet forwarding and packet UID matching
> rather then divert sockets. This solution works fine on FreeBSD, Linux
> and Mac OS X Leopard. Hovewer in the new Mac OS X Snow Leopard,
> forwarding outgoing packets to local port does not work. So I'm looking
> for another solution.

sounds like the broke it..

maybe they inherited a change from FreeBSD that was reverted out but
existed for one release, that broke exactly that :-)

ipfw fwd
along with fwd uid
is the way to do this on FreeBSD but snow leopard IS a problem.

doing it with divert is going to be a real pain.

you can also do this with nat in some cases I think..

>
> Jakub

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: Diverting sockets and streams

2009-11-05T00:47:27Z

Hi Julian,

thanks for making this clear to me.

>
>>
>> so basically I have to implement part of the TCP stack in my app.
>
> yes,
> though there may be other ways to do what you want..
> what DO you want to do?
>

I need to make a transparent proxy e.g. HTTP proxy, that will be able
to scan the data stream for some security problems (exploits or
whatever).

I had a solution based on packet forwarding and packet UID matching
rather then divert sockets. This solution works fine on FreeBSD, Linux
and Mac OS X Leopard. Hovewer in the new Mac OS X Snow Leopard,
forwarding outgoing packets to local port does not work. So I'm
looking for another solution.

Jakub
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: Diverting sockets and streams

2009-11-04T09:44:46Z

jakub wrote:

> Hi list,
>
> I have a newbie question about divert sockets but I can't find a direct
> answer.
>
> I have a rule like this:
>
> ipfw add divert 5555 tcp from me to any 80 keep-state
>
> If I understand it correctly, in order to check the data stream properly
> I have to deal with:
>
> 1. packet reordering
> 2. packet duplication

yes, divert treats each packet individually
with the exception of frags which it reassembles.

>
> so basically I have to implement part of the TCP stack in my app.

yes,
though there may be other ways to do what you want..
what DO you want to do?

>
> I don't have to bother with fragmentation (according to man pages).
> I won't be able to understand IPSec packets as I will get encrypted IP
> frames.

yes

>
> Am I correct? Or can you please tell me how it really works?

packets enter the system and are run through the IP stack where the
first thing they hit is ipfw. in ipfw the divert rule forces them
to the divert code (which does reassembly but that's all) and
passes the result to a divert socket.

there is apossibilty that done correctly with ESP one migh tb eab;e to
get to the unencrypted packet but you'd have to read the code starting
at ip_input() in ip_input.c to check for sure.

>
> Thanks a lot,
>
> Jakub
>
> _______________________________________________
> freebsd-ipfw@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Diverting sockets and streams

2009-11-04T08:37:23Z

Hi list,

I have a newbie question about divert sockets but I can't find a direct
answer.

I have a rule like this:

ipfw add divert 5555 tcp from me to any 80 keep-state

If I understand it correctly, in order to check the data stream properly
I have to deal with:

1. packet reordering
2. packet duplication

so basically I have to implement part of the TCP stack in my app.

I don't have to bother with fragmentation (according to man pages).
I won't be able to understand IPSec packets as I will get encrypted IP
frames.

Am I correct? Or can you please tell me how it really works?

Thanks a lot,

Jakub

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Current problem reports assigned to freebsd-ipfw@FreeBSD.org

2009-11-02T03:06:57Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth
o kern/139226 ipfw [ipfw] install_state: entry already present, done
o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken
o kern/137232 ipfw [ipfw] parser troubles
o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul
o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o
o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file.
o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port
o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke
o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0)
o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior
o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho
o kern/129103 ipfw [ipfw] IPFW check state does not work =(
o kern/129093 ipfw [ipfw] ipfw nat must not drop packets
o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n
o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets
o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l
o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes
o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit
o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6
o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip
s kern/121807 ipfw [request] TCP and UDP port_table in ipfw
o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor
o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields
o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem
o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s
o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4
o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from
p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe
o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form
o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule
p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec
o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c
o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets
o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work
o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q
o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a
o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a
o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b
o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table
o kern/102471 ipfw [ipfw] [patch] add tos and dscp support
o kern/98831 ipfw [ipfw] ipfw has UDP hickups
o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to
o kern/97504 ipfw [ipfw] IPFW Rules bug
o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v
o kern/93300 ipfw [ipfw] ipfw pipe lost packets
o kern/91847 ipfw [ipfw] ipfw with vlanX as the device
o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul
o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation
o kern/86957 ipfw [ipfw] [patch] ipfw mac logging
o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou
s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION
o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir
o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp
o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT
o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes (
o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a
o kern/69963 ipfw [ipfw] install_state warning about already existing en
o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes
o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw
o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent
o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags
o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f
a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau

64 problems total.

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: dummynet cpu usage

2009-10-27T09:29:24Z

Здравствуйте,

and i forgot to say -- on freebsd 6 it worked fine with same config, problem appeared on 7.2-STABLE, i've upgraded to use IPFIREWALL_NAT

On Tue, Oct 27, 2009 at 10:40:22AM +0300, Evgenii Davidov пишет:

>
> Hello!
>
> sometimes i see "dummynet" process eating 50% of cpu, but not all the time, at the same values of pps and traffic, how can i help it maybe?
>
> my rules are:
>
> 00040 5684913 4633951201 queue tablearg ip from any to table(80) out via bge1
> 00050 147394453 116505899626 pipe tablearg ip from any to table(2) out via bge1
> 00070 36989671 23121793602 pipe 16 ip from table(16) to any in via bge1
> 00071 192817060 91846274165 pipe 5 ip from not table(16) to any in via bge1
>
> i have about 164 pipes and queues
>
> thank you!
>
> --
> Evgenii V Davidov
> _______________________________________________
> freebsd-ipfw@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

--
Evgenii V Davidov
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

dummynet cpu usage

2009-10-27T00:40:22Z

Hello!

sometimes i see "dummynet" process eating 50% of cpu, but not all the time, at the same values of pps and traffic, how can i help it maybe?

my rules are:

00040 5684913 4633951201 queue tablearg ip from any to table(80) out via bge1
00050 147394453 116505899626 pipe tablearg ip from any to table(2) out via bge1
00070 36989671 23121793602 pipe 16 ip from table(16) to any in via bge1
00071 192817060 91846274165 pipe 5 ip from not table(16) to any in via bge1

i have about 164 pipes and queues

thank you!

--
Evgenii V Davidov
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Current problem reports assigned to freebsd-ipfw@FreeBSD.org

2009-10-26T04:07:01Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth
o kern/139226 ipfw [ipfw] install_state: entry already present, done
o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken
o kern/137232 ipfw [ipfw] parser troubles
o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul
o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o
o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file.
o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port
o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke
o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0)
o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior
o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho
o kern/129103 ipfw [ipfw] IPFW check state does not work =(
o kern/129093 ipfw [ipfw] ipfw nat must not drop packets
o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n
o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets
o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l
o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes
o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit
o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6
o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip
s kern/121807 ipfw [request] TCP and UDP port_table in ipfw
o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor
o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields
o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem
o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s
o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4
o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from
p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe
o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form
o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule
p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec
o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c
o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets
o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work
o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q
o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a
o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a
o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b
o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table
o kern/102471 ipfw [ipfw] [patch] add tos and dscp support
o kern/98831 ipfw [ipfw] ipfw has UDP hickups
o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to
o kern/97504 ipfw [ipfw] IPFW Rules bug
o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v
o kern/93300 ipfw [ipfw] ipfw pipe lost packets
o kern/91847 ipfw [ipfw] ipfw with vlanX as the device
o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul
o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation
o kern/86957 ipfw [ipfw] [patch] ipfw mac logging
o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou
s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION
o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir
o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp
o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT
o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes (
o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a
o kern/69963 ipfw [ipfw] install_state warning about already existing en
o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes
o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw
o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent
o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags
o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f
a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau

64 problems total.

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth

2009-10-22T05:20:02Z

The following reply was made to PR kern/139581; it has been noted by GNATS.

From: Ian Smith <smithi@...>
To: alexus <alexus@...>
Cc: bug-followup@..., freebsd@...
Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth
Date: Thu, 22 Oct 2009 23:17:23 +1100 (EST)

On Mon, 19 Oct 2009, alexus wrote:

> new set of rules

> pipe 1 config bw 1Mbit/s mask src-port www
> pipe 2 config bw 1Mbit/s mask src-port www

Wrong mask syntax entirely. You can see from your pipe masks as shown,
it's taken as meaning no mask at all:

> mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000

Anyway, masking pipes creates dynamic pipes per masked flow, each of
which gets ALL of the specified bandwidth. If you want to limit total
bandwidth to 1Mbit/s, you likely want to use dynamic queues instead.

ipfw(8) is a precise reference, but very terse. Suggested reading:

http://info.iet.unipi.it/~luigi/dummynet/

and especially the last link from that page:

http://info.iet.unipi.it/~luigi/ip_dummynet/original.html

for clear examples of sharing evenly a single link - though noting
that page is outdated re the sysctls for dummynet, bridging etc.

Still looking more like a usage issue than describing a bug, but:

> > If this is still an issue, please:

> > . say whether the extra ~25% traffic shown is on the same interface
> > as the webserver, ie the interface MRTG monitors, or not?
> > . the value of sysctl net.inet.ip.fw.one_pass ?

cheers, Ian
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: IPFW closing range of ports

2009-10-19T14:00:56Z

You could starve it by using a pipe, allocate 16 kbit/sec. Then
technically you aren't blocking it.

ipfw add 1000 pipe 10 tcp from any to any 14500-65535 out
ipfw pipe 10 config bw 16k queue 100 mask dst-ip 0xff000000

Otherwise, you can block the ports:
ipfw add 1000 deny tcp from any to any 14500-65535 out

Depends on how much of a BOFH mood your are in that day.

-- Matthew

PeterJJ wrote:
> I'm new to this, so go easy please.
>
> I have put in place a very basic ipfw ruleset in my place of employment.
> To this i have been asked to block out all peer to peer sharing to ports in
> the range of 14500-65000.
>
>
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

IPFW closing range of ports

2009-10-19T13:14:11Z

I'm new to this, so go easy please.

I have put in place a very basic ipfw ruleset in my place of employment.
To this i have been asked to block out all peer to peer sharing to ports in the range of 14500-65000.

Is it doable?
I am currently experiencing issues with users where I work running a music streaming service which at first runs from the free service's own servers, then starts running peer to peer. I am not allowed to block the application. I would like to as it is hogging bandwidth, but have been told I am not permitted. Is there anything I can do?
The application will run with the peer to peer option disabled, relying only on the company's server, before eventually getting kicked off after an hour or so (but I don't care about that).

Thank you all in advance

Re: ipfw: install_state: entry already present, done

2009-10-19T10:38:05Z

Interesting idea, but doesn't seem to help any :(

I added it into the workstation set I had with it loading between the
127.0.0.1 rules and the check-state. Message didn't stop and "ipfw show"
doesn't show anything hitting that rule.

What "ipfw show" does show is a lot on the "allow tcp .... setup
keep-state" and "allow udp .... keep-state" rules hitting all the
packets (plus one each on 2 of the abuse ones farther down)

I tried rolling back my sys/netinet/ip_fw2.c to the latest revision from
7.1 and that didn't help either, so I don't think it was a change to
that file. Unless there is a kernel developer aroun who is more familiar
with the network stack to fix this or point me in a better direction,
I'll keep rolling back individual files trying to find which commit
caused this.

Ian Smith wrote:

> On Fri, 16 Oct 2009, Chris St Denis wrote:
> >
> > This is definitely a regression in 7.2.
> >
> > Downgrades to 6.4, 7.0, 7.1 did not show this symptom. Upgrade the test
> > server back to 7.2 and the messages come back.
>
> I notice neither your rules shown below nor the "workstation" rules -
> unlike the "client" and "simple" rulesets - allow IP fragments to pass,
> and I'm not sure what happens to frags that are associated with stateful
> DNS rules.
>
> The only frags I usually see here are associated with DNS responses from
> my forwarders, usually huge lists of NS for spamhaus.org that are almost
> always fragmented (around 2Kbytes).
>
> You could maybe try a specific 'allow log all from any to any frag' ?
>
> Just a wild stab in the dark,
>
> cheers, Ian
>
> > Chris St Denis wrote:
> > > check_state doesn't help. The error is also generated from the rc.conf
> > > firewall_type="workstation" rule set which includes check_state among
> > > several other rules.
> > >
> > > I made a copy of this server (it's a virtual server under WMware) and
> > > downgraded it to 6.4-RELEASE-p7 and I no longer get the error.
> > >
> > > I downgraded another copy to 7.2-RELEASE (no patches) by copying the
> > > generic kernel off the CD. Still gets errors.
> > >
> > > Downgraded it to 7.0-RELEASE and the message stopped.
> > >
> > > I'm going to try going to 7.1 and see which behavior it has.
> > >
> > > Looks like there may have been a regression in 7.2 (or maybe 7.1 pending
> > > the results of my further testing)
> > >
> > >
> > > Jason Lewis wrote:
> > > > Did you try a check_state? I am using this same rule structure on BSD6
> > > > without a problem.
> > > >
> > > > Thanks,
> > > > Jason
> > > > http://jasonlewis.yaritz.net
> > > >
> > > >
> > > > > Freddie Cash wrote:
> > > > >
> > > > > > On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis <chris@...>
> > > > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Haven't gotten any response on -questions so trying here. I've also
> > > > > > > opened
> > > > > > > a PR (kern/139226) but it's gotten no replies so I figured I should
> > > > > > > try
> > > > > > > here
> > > > > > > since I'm not certain if it's a bug or not. Regardless I am hoping
> > > > > > > for
> > > > > > > at
> > > > > > > least a work-around -- a few extra rules or settings to keep my
> > > > > > > console
> > > > > > > from
> > > > > > > being flooded by errors. So far only option I found is commenting
> > > > > > > out
> > > > > > > the
> > > > > > > error display line in the kernel source which is far from optimal.
> > > > > > >
> > > > > > > I'm trying to setup a stateful firewall for my server such that any
> > > > > > > traffic
> > > > > > > can go out, and it's reply come back -- a fairly typical
> > > > > > > workstation
> > > > > > > setup.
> > > > > > > However I'm getting the error message "ipfw: install_state: entry
> > > > > > > already
> > > > > > > present, done" repeated many times in my logs (tho the rules seemed
> > > > > > > to
> > > > > > > work
> > > > > > > fine otherwise).
> > > > > > >
> > > > > > > I stripped down the rules to the minimum I could and discovered the
> > > > > > > line
> > > > > > > causing it is "allow udp from me to any keep-state".
> > > > > > >
> > > > > > > Only seems to happen when I have bind running as a slave dns server
> > > > > > > (not
> > > > > > > publicly listed, just the zone replication traffic causes the
> > > > > > > error)
> > > > > > > but I
> > > > > > > assume any other large source of UDP traffic would also do it.
> > > > > > >
> > > > > > > Full firewall rules:
> > > > > > >
> > > > > > > dns2# ipfw list
> > > > > > > 00100 allow ip from any to any via lo0
> > > > > > > 00200 deny ip from any to 127.0.0.0/8
> > > > > > > 00300 deny ip from 127.0.0.0/8 to any
> > > > > > > 00400 allow udp from me to any keep-state
> > > > > > > 65535 deny ip from any to any
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > If you add "out xmit em0" to the udp rule, do the errors stop
> > > > > >
> > > > > I added that and restarted bind (thus generating a bunch of UDP
> > > > > traffic)
> > > > > and the error still floods the console.
> > > > >
> > > > > Current rule set:
> > > > > 00100 allow ip from any to any via lo0
> > > > > 00200 deny ip from any to 127.0.0.0/8
> > > > > 00300 deny ip from 127.0.0.0/8 to any
> > > > > 00400 allow udp from me to any out xmit em0 keep-state
> > > > > 00500 allow ip from any to any
> > > > > 65535 deny ip from any to any
> > > > >
> > > > > _______________________________________________
> > > > > freebsd-ipfw@... mailing list
> > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> > > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
> > > > >
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > freebsd-ipfw@... mailing list
> > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
> > > >
> > >
> > >
> >
> >
> > --
> > Chris St Denis
> > Programmer
> > SmarttNet (www.smartt.com)
> > Ph: 604-473-9700 Ext. 200
> > -------------------------------------------
> > "Smart Internet Solutions For Businesses"
> > _______________________________________________
> > freebsd-ipfw@... mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
> >
> _______________________________________________
> freebsd-ipfw@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
>

--
Chris St Denis
Programmer
SmarttNet (www.smartt.com)
Ph: 604-473-9700 Ext. 200
-------------------------------------------
"Smart Internet Solutions For Businesses"

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth

2009-10-19T09:30:05Z

The following reply was made to PR kern/139581; it has been noted by GNATS.

From: alexus <alexus@...>
To: Ian Smith <smithi@...>
Cc: bug-followup@...,
freebsd@...
Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth
Date: Mon, 19 Oct 2009 11:58:41 -0400

On Oct 19, 2009, at 10:24 AM, Ian Smith wrote:

> May be a usage issue; I'll have a go. Partial quoting, out of order.
>
> : I'm trying to limit my apache that runs under daemon to up 2Mbit/s
> : when I do "ipfw pipe show" I don't see anything in my slots other
> then
> : very first entry that never chage, nor does it limits my traffic, as
> : if I look at my MRTG i see way more traffic then 2Mbit/s
>
> Unless you specify masks on your pipes you'll only ever see the first
> connection that used that pipe, that's normal.

ok

new set of rules

su-3.2# cat /etc/ipfw.rules
flush
pipe flush
pipe 1 config bw 1Mbit/s mask src-port www
pipe 2 config bw 1Mbit/s mask src-port www
add 100 allow ip from any to any via lo0
add 200 deny ip from any to 127.0.0.0/8
add 300 deny ip from 127.0.0.0/8 to any
add 8381 pipe 1 tcp from any to any dst-port www uid daemon
add 8382 pipe 2 tcp from any to any src-port www uid daemon
add 65000 pass all from any to any
su-3.2# ipfw show
00100 1476 230632 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
00300 0 0 deny ip from 127.0.0.0/8 to any
08381 482 36368 pipe 1 tcp from any to any dst-port 80 uid daemon
08382 620 743113 pipe 2 tcp from any 80 to any uid daemon
65000 6832 5040856 allow ip from any to any
65535 0 0 deny ip from any to any
su-3.2# ipfw pipe show
00001: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/
Byte Drp
0 tcp 64.237.55.83/49492 66.230.133.69/80 509 38156
0 0 0
00002: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/
Byte Drp
0 tcp 66.230.133.69/80 64.237.55.83/49492 656 785292 1
1500 1
su-3.2# ipfw pipe show
00001: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/
Byte Drp
0 tcp 64.237.55.83/49492 66.230.133.69/80 1247 98023
0 0 0
00002: 1.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/
Byte Drp
0 tcp 66.230.133.69/80 64.237.55.83/49492 1475 1453606
0 0 1
su-3.2#

in this case i did specify mask for pipe, yet when I'm issuing ipfw
pipe show I still don't see anything in terms of slots that being in use

su-3.2# sysctl net.inet.ip.dummynet.pipe_slot_limit
net.inet.ip.dummynet.pipe_slot_limit: 100
su-3.2#

seems like at all time I see only 1 slot being utilized and as I
mention before it never changes.

>
> MRTG sees all traffic on an interface, and your ipfw stats indicate at
> least 25% more traffic than that due to your webserver, so it's not
> clear how you could tell if your pipe was exceeding 2Mbit/s or not?
>

I obviously do have other traffic then www, but majority of it is www.
but I see why you coming with this, so let me just give you an example.
if I at peak time shutdown my apache, my traffic drops dramatically
and by dramatically i mean at least 90% (and in most cases more)
my traffic went to as much as 10mbps with supposedly limited pipe of
2mbps, when I set it to 1mbps it seems to be almost there...

> Also, it's recommended not to run your inbound and outbound traffic
> through the one pipe, unless simulating half-duplex connections; see
> explanation in ipfw(8), EXAMPLES section under TRAFFIC SHAPING.

i thought about that and as you suggested i did separate them into 2
separate pipes (see on top)

>
> : su-3.2# ipfw show
> : 00100 1249368 205115325 allow ip from any to any via lo0
> : 00200 0 0 deny ip from any to 127.0.0.0/8
> : 00300 0 0 deny ip from 127.0.0.0/8 to any
> : 08380 2838075 3586421013 pipe 1 tcp from any 80 to any uid daemon
> : 08380 2097473 136454502 pipe 1 tcp from any to any dst-port 80 uid
> daemon
> : 65000 5740679 4716157064 allow ip from any to any
> : 65535 0 0 deny ip from any to any
>
> 3.586 GiB outbound from the webserver (served data)
> 0.136 GiB inbound to the webserver (requests, acks)
> + ---
> 3.722 GiB through the pipe.
> but
> 4.716 GiB passed from any to any, either way.
>
> So there's about 1 Gig of extra traffic shown here, assuming you have
> net.inet.ip.fw.one_pass=0 and all traffic eventually hits rule 65000
> (and 4.7G extra traffic if net.inet.ip.fw.one_pass=1) but there's not
> enough info to see whether or not it's on the interface MRTG watches?
>
> : su-3.2# ipfw pipe show
> : 00001: 2.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail
> : mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
> : BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes
> Pkt/Byte Drp
> : 0 tcp 64.237.55.83/59388 208.80.152.3/80 4936077 3723134341 0 0
> 30179
>
> Total packets and bytes match the above, indicating that this was done
> just after the ipfw show. 0.6% dropped packets indicates some
> limiting
> happening, but with a shared in/outbound pipe, not in which direction.
>
> If this is still an issue, please:
>
> . be more precise than "way more traffic" if you have more data?
> . say whether the extra ~25% traffic shown is on the same interface
> as the webserver, ie the interface MRTG monitors, or not?
> . the value of sysctl net.inet.ip.fw.one_pass ?
>
> cheers, Ian
>

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth

2009-10-19T07:50:02Z

The following reply was made to PR kern/139581; it has been noted by GNATS.

From: Ian Smith <smithi@...>
To: bug-followup@..., freebsd@...
Cc:
Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth
Date: Tue, 20 Oct 2009 01:24:17 +1100

May be a usage issue; I'll have a go. Partial quoting, out of order.

: I'm trying to limit my apache that runs under daemon to up 2Mbit/s
: when I do "ipfw pipe show" I don't see anything in my slots other then
: very first entry that never chage, nor does it limits my traffic, as
: if I look at my MRTG i see way more traffic then 2Mbit/s

Unless you specify masks on your pipes you'll only ever see the first
connection that used that pipe, that's normal.

MRTG sees all traffic on an interface, and your ipfw stats indicate at
least 25% more traffic than that due to your webserver, so it's not
clear how you could tell if your pipe was exceeding 2Mbit/s or not?

Also, it's recommended not to run your inbound and outbound traffic
through the one pipe, unless simulating half-duplex connections; see
explanation in ipfw(8), EXAMPLES section under TRAFFIC SHAPING.

: su-3.2# ipfw show
: 00100 1249368 205115325 allow ip from any to any via lo0
: 00200 0 0 deny ip from any to 127.0.0.0/8
: 00300 0 0 deny ip from 127.0.0.0/8 to any
: 08380 2838075 3586421013 pipe 1 tcp from any 80 to any uid daemon
: 08380 2097473 136454502 pipe 1 tcp from any to any dst-port 80 uid daemon
: 65000 5740679 4716157064 allow ip from any to any
: 65535 0 0 deny ip from any to any

3.586 GiB outbound from the webserver (served data)
0.136 GiB inbound to the webserver (requests, acks)
+ ---
3.722 GiB through the pipe.
but
4.716 GiB passed from any to any, either way.

So there's about 1 Gig of extra traffic shown here, assuming you have
net.inet.ip.fw.one_pass=0 and all traffic eventually hits rule 65000
(and 4.7G extra traffic if net.inet.ip.fw.one_pass=1) but there's not
enough info to see whether or not it's on the interface MRTG watches?

: su-3.2# ipfw pipe show
: 00001: 2.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail
: mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
: BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes
Pkt/Byte Drp
: 0 tcp 64.237.55.83/59388 208.80.152.3/80 4936077 3723134341 0 0 30179

Total packets and bytes match the above, indicating that this was done
just after the ipfw show. 0.6% dropped packets indicates some limiting
happening, but with a shared in/outbound pipe, not in which direction.

If this is still an issue, please:

. be more precise than "way more traffic" if you have more data?
. say whether the extra ~25% traffic shown is on the same interface
as the webserver, ie the interface MRTG monitors, or not?
. the value of sysctl net.inet.ip.fw.one_pass ?

cheers, Ian

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Current problem reports assigned to freebsd-ipfw@FreeBSD.org

2009-10-19T04:06:55Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth
o kern/139226 ipfw [ipfw] install_state: entry already present, done
o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken
o kern/137232 ipfw [ipfw] parser troubles
o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul
o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o
o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file.
o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port
o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke
o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0)
o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior
o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho
o kern/129103 ipfw [ipfw] IPFW check state does not work =(
o kern/129093 ipfw [ipfw] ipfw nat must not drop packets
o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n
o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets
o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l
o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes
o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit
o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6
o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip
s kern/121807 ipfw [request] TCP and UDP port_table in ipfw
o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor
o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields
o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem
o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s
o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4
o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from
p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe
o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form
o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule
p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec
o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c
o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets
o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work
o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q
o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a
o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a
o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b
o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table
o kern/102471 ipfw [ipfw] [patch] add tos and dscp support
o kern/98831 ipfw [ipfw] ipfw has UDP hickups
o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to
o kern/97504 ipfw [ipfw] IPFW Rules bug
o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v
o kern/93300 ipfw [ipfw] ipfw pipe lost packets
o kern/91847 ipfw [ipfw] ipfw with vlanX as the device
o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul
o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation
o kern/86957 ipfw [ipfw] [patch] ipfw mac logging
o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou
s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION
o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir
o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp
o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT
o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes (
o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a
o kern/69963 ipfw [ipfw] install_state warning about already existing en
o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes
o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw
o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent
o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags
o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f
a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau

64 problems total.

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: ipfw: install_state: entry already present, done

2009-10-16T23:41:56Z

On Fri, 16 Oct 2009, Chris St Denis wrote:
>
> This is definitely a regression in 7.2.
>
> Downgrades to 6.4, 7.0, 7.1 did not show this symptom. Upgrade the test
> server back to 7.2 and the messages come back.

I notice neither your rules shown below nor the "workstation" rules -
unlike the "client" and "simple" rulesets - allow IP fragments to pass,
and I'm not sure what happens to frags that are associated with stateful
DNS rules.

The only frags I usually see here are associated with DNS responses from
my forwarders, usually huge lists of NS for spamhaus.org that are almost
always fragmented (around 2Kbytes).

You could maybe try a specific 'allow log all from any to any frag' ?

Just a wild stab in the dark,

cheers, Ian

> Chris St Denis wrote:
> > check_state doesn't help. The error is also generated from the rc.conf
> > firewall_type="workstation" rule set which includes check_state among
> > several other rules.
> >
> > I made a copy of this server (it's a virtual server under WMware) and
> > downgraded it to 6.4-RELEASE-p7 and I no longer get the error.
> >
> > I downgraded another copy to 7.2-RELEASE (no patches) by copying the
> > generic kernel off the CD. Still gets errors.
> >
> > Downgraded it to 7.0-RELEASE and the message stopped.
> >
> > I'm going to try going to 7.1 and see which behavior it has.
> >
> > Looks like there may have been a regression in 7.2 (or maybe 7.1 pending
> > the results of my further testing)
> >
> >
> > Jason Lewis wrote:
> > > Did you try a check_state? I am using this same rule structure on BSD6
> > > without a problem.
> > >
> > > Thanks,
> > > Jason
> > > http://jasonlewis.yaritz.net
> > >
> > >
> > > > Freddie Cash wrote:
> > > >
> > > > > On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis <chris@...>
> > > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > > Haven't gotten any response on -questions so trying here. I've also
> > > > > > opened
> > > > > > a PR (kern/139226) but it's gotten no replies so I figured I should
> > > > > > try
> > > > > > here
> > > > > > since I'm not certain if it's a bug or not. Regardless I am hoping
> > > > > > for
> > > > > > at
> > > > > > least a work-around -- a few extra rules or settings to keep my
> > > > > > console
> > > > > > from
> > > > > > being flooded by errors. So far only option I found is commenting
> > > > > > out
> > > > > > the
> > > > > > error display line in the kernel source which is far from optimal.
> > > > > >
> > > > > > I'm trying to setup a stateful firewall for my server such that any
> > > > > > traffic
> > > > > > can go out, and it's reply come back -- a fairly typical
> > > > > > workstation
> > > > > > setup.
> > > > > > However I'm getting the error message "ipfw: install_state: entry
> > > > > > already
> > > > > > present, done" repeated many times in my logs (tho the rules seemed
> > > > > > to
> > > > > > work
> > > > > > fine otherwise).
> > > > > >
> > > > > > I stripped down the rules to the minimum I could and discovered the
> > > > > > line
> > > > > > causing it is "allow udp from me to any keep-state".
> > > > > >
> > > > > > Only seems to happen when I have bind running as a slave dns server
> > > > > > (not
> > > > > > publicly listed, just the zone replication traffic causes the
> > > > > > error)
> > > > > > but I
> > > > > > assume any other large source of UDP traffic would also do it.
> > > > > >
> > > > > > Full firewall rules:
> > > > > >
> > > > > > dns2# ipfw list
> > > > > > 00100 allow ip from any to any via lo0
> > > > > > 00200 deny ip from any to 127.0.0.0/8
> > > > > > 00300 deny ip from 127.0.0.0/8 to any
> > > > > > 00400 allow udp from me to any keep-state
> > > > > > 65535 deny ip from any to any
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > If you add "out xmit em0" to the udp rule, do the errors stop
> > > > >
> > > > I added that and restarted bind (thus generating a bunch of UDP
> > > > traffic)
> > > > and the error still floods the console.
> > > >
> > > > Current rule set:
> > > > 00100 allow ip from any to any via lo0
> > > > 00200 deny ip from any to 127.0.0.0/8
> > > > 00300 deny ip from 127.0.0.0/8 to any
> > > > 00400 allow udp from me to any out xmit em0 keep-state
> > > > 00500 allow ip from any to any
> > > > 65535 deny ip from any to any
> > > >
> > > > _______________________________________________
> > > > freebsd-ipfw@... mailing list
> > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > freebsd-ipfw@... mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
> > >
> >
> >
>
>
> --
> Chris St Denis
> Programmer
> SmarttNet (www.smartt.com)
> Ph: 604-473-9700 Ext. 200
> -------------------------------------------
> "Smart Internet Solutions For Businesses"
> _______________________________________________
> freebsd-ipfw@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
>
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: kern/139226: [ipfw] install_state: entry already present, done

2009-10-16T16:30:06Z

The following reply was made to PR kern/139226; it has been noted by GNATS.

From: Chris St Denis <chris@...>
To: bug-followup@..., chris@...
Cc:
Subject: Re: kern/139226: [ipfw] install_state: entry already present, done
Date: Fri, 16 Oct 2009 16:21:31 -0700

I tested this in other versions of FreeBSD by downgrading to 6.4, 7.0, &
7.1 with freebsd-update. None of the other version experianced this
behavior. However when going back to 7.2 (with freebsd-update) the error
returned.

Seems to be a regression in 7.2

--
Chris St Denis
Programmer
SmarttNet (www.smartt.com)
Ph: 604-473-9700 Ext. 200
-------------------------------------------
"Smart Internet Solutions For Businesses"

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: ipfw: install_state: entry already present, done

2009-10-16T16:12:16Z

This is definitely a regression in 7.2.

Downgrades to 6.4, 7.0, 7.1 did not show this symptom. Upgrade the test
server back to 7.2 and the messages come back.

Chris St Denis wrote:

> check_state doesn't help. The error is also generated from the rc.conf
> firewall_type="workstation" rule set which includes check_state among
> several other rules.
>
> I made a copy of this server (it's a virtual server under WMware) and
> downgraded it to 6.4-RELEASE-p7 and I no longer get the error.
>
> I downgraded another copy to 7.2-RELEASE (no patches) by copying the
> generic kernel off the CD. Still gets errors.
>
> Downgraded it to 7.0-RELEASE and the message stopped.
>
> I'm going to try going to 7.1 and see which behavior it has.
>
> Looks like there may have been a regression in 7.2 (or maybe 7.1
> pending the results of my further testing)
>
>
> Jason Lewis wrote:
>> Did you try a check_state? I am using this same rule structure on BSD6
>> without a problem.
>>
>> Thanks,
>> Jason
>> http://jasonlewis.yaritz.net
>>
>>
>>> Freddie Cash wrote:
>>>
>>>> On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis <chris@...>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> Haven't gotten any response on -questions so trying here. I've also
>>>>> opened
>>>>> a PR (kern/139226) but it's gotten no replies so I figured I
>>>>> should try
>>>>> here
>>>>> since I'm not certain if it's a bug or not. Regardless I am hoping
>>>>> for
>>>>> at
>>>>> least a work-around -- a few extra rules or settings to keep my
>>>>> console
>>>>> from
>>>>> being flooded by errors. So far only option I found is commenting out
>>>>> the
>>>>> error display line in the kernel source which is far from optimal.
>>>>>
>>>>> I'm trying to setup a stateful firewall for my server such that any
>>>>> traffic
>>>>> can go out, and it's reply come back -- a fairly typical workstation
>>>>> setup.
>>>>> However I'm getting the error message "ipfw: install_state: entry
>>>>> already
>>>>> present, done" repeated many times in my logs (tho the rules
>>>>> seemed to
>>>>> work
>>>>> fine otherwise).
>>>>>
>>>>> I stripped down the rules to the minimum I could and discovered the
>>>>> line
>>>>> causing it is "allow udp from me to any keep-state".
>>>>>
>>>>> Only seems to happen when I have bind running as a slave dns server
>>>>> (not
>>>>> publicly listed, just the zone replication traffic causes the error)
>>>>> but I
>>>>> assume any other large source of UDP traffic would also do it.
>>>>>
>>>>> Full firewall rules:
>>>>>
>>>>> dns2# ipfw list
>>>>> 00100 allow ip from any to any via lo0
>>>>> 00200 deny ip from any to 127.0.0.0/8
>>>>> 00300 deny ip from 127.0.0.0/8 to any
>>>>> 00400 allow udp from me to any keep-state
>>>>> 65535 deny ip from any to any
>>>>>
>>>>>
>>>>>
>>>>>
>>>> If you add "out xmit em0" to the udp rule, do the errors stop
>>>>
>>> I added that and restarted bind (thus generating a bunch of UDP
>>> traffic)
>>> and the error still floods the console.
>>>
>>> Current rule set:
>>> 00100 allow ip from any to any via lo0
>>> 00200 deny ip from any to 127.0.0.0/8
>>> 00300 deny ip from 127.0.0.0/8 to any
>>> 00400 allow udp from me to any out xmit em0 keep-state
>>> 00500 allow ip from any to any
>>> 65535 deny ip from any to any
>>>
>>> _______________________________________________
>>> freebsd-ipfw@... mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
>>>
>>>
>>
>>
>> _______________________________________________
>> freebsd-ipfw@... mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
>>
>
>

Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth

2009-10-14T13:19:39Z

Old Synopsis: ipfw pipe
New Synopsis: [ipfw] "ipfw pipe" not limiting bandwidth

Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw
Responsible-Changed-By: gavin
Responsible-Changed-When: Wed Oct 14 20:17:06 UTC 2009
Responsible-Changed-Why:
Over to maintainer(s)

http://www.freebsd.org/cgi/query-pr.cgi?pr=139581
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Current problem reports assigned to freebsd-ipfw@FreeBSD.org

2009-10-12T04:06:55Z

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/139226 ipfw [ipfw] install_state: entry already present, done
o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken
o kern/137232 ipfw [ipfw] parser troubles
o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul
o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o
o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file.
o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port
o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke
o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0)
o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior
o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho
o kern/129103 ipfw [ipfw] IPFW check state does not work =(
o kern/129093 ipfw [ipfw] ipfw nat must not drop packets
o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n
o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets
o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l
o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes
o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit
o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6
o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip
s kern/121807 ipfw [request] TCP and UDP port_table in ipfw
o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor
o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields
o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem
o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s
o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4
o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from
p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe
o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form
o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule
p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec
o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c
o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets
o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work
o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q
o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a
o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a
o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b
o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table
o kern/102471 ipfw [ipfw] [patch] add tos and dscp support
o kern/98831 ipfw [ipfw] ipfw has UDP hickups
o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to
o kern/97504 ipfw [ipfw] IPFW Rules bug
o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v
o kern/93300 ipfw [ipfw] ipfw pipe lost packets
o kern/91847 ipfw [ipfw] ipfw with vlanX as the device
o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul
o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation
o kern/86957 ipfw [ipfw] [patch] ipfw mac logging
o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou
s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION
o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir
o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp
o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT
o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes (
o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a
o kern/69963 ipfw [ipfw] install_state warning about already existing en
o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes
o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw
o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent
o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags
o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f
a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau

63 problems total.

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: ipfw: install_state: entry already present, done

2009-10-09T12:47:13Z

check_state doesn't help. The error is also generated from the rc.conf
firewall_type="workstation" rule set which includes check_state among
several other rules.

I made a copy of this server (it's a virtual server under WMware) and
downgraded it to 6.4-RELEASE-p7 and I no longer get the error.

I downgraded another copy to 7.2-RELEASE (no patches) by copying the
generic kernel off the CD. Still gets errors.

Downgraded it to 7.0-RELEASE and the message stopped.

I'm going to try going to 7.1 and see which behavior it has.

Looks like there may have been a regression in 7.2 (or maybe 7.1 pending
the results of my further testing)

Jason Lewis wrote:

> Did you try a check_state? I am using this same rule structure on BSD6
> without a problem.
>
> Thanks,
> Jason
> http://jasonlewis.yaritz.net
>
>
>> Freddie Cash wrote:
>>
>>> On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis <chris@...> wrote:
>>>
>>>
>>>
>>>> Haven't gotten any response on -questions so trying here. I've also
>>>> opened
>>>> a PR (kern/139226) but it's gotten no replies so I figured I should try
>>>> here
>>>> since I'm not certain if it's a bug or not. Regardless I am hoping for
>>>> at
>>>> least a work-around -- a few extra rules or settings to keep my console
>>>> from
>>>> being flooded by errors. So far only option I found is commenting out
>>>> the
>>>> error display line in the kernel source which is far from optimal.
>>>>
>>>> I'm trying to setup a stateful firewall for my server such that any
>>>> traffic
>>>> can go out, and it's reply come back -- a fairly typical workstation
>>>> setup.
>>>> However I'm getting the error message "ipfw: install_state: entry
>>>> already
>>>> present, done" repeated many times in my logs (tho the rules seemed to
>>>> work
>>>> fine otherwise).
>>>>
>>>> I stripped down the rules to the minimum I could and discovered the
>>>> line
>>>> causing it is "allow udp from me to any keep-state".
>>>>
>>>> Only seems to happen when I have bind running as a slave dns server
>>>> (not
>>>> publicly listed, just the zone replication traffic causes the error)
>>>> but I
>>>> assume any other large source of UDP traffic would also do it.
>>>>
>>>> Full firewall rules:
>>>>
>>>> dns2# ipfw list
>>>> 00100 allow ip from any to any via lo0
>>>> 00200 deny ip from any to 127.0.0.0/8
>>>> 00300 deny ip from 127.0.0.0/8 to any
>>>> 00400 allow udp from me to any keep-state
>>>> 65535 deny ip from any to any
>>>>
>>>>
>>>>
>>>>
>>> If you add "out xmit em0" to the udp rule, do the errors stop
>>>
>> I added that and restarted bind (thus generating a bunch of UDP traffic)
>> and the error still floods the console.
>>
>> Current rule set:
>> 00100 allow ip from any to any via lo0
>> 00200 deny ip from any to 127.0.0.0/8
>> 00300 deny ip from 127.0.0.0/8 to any
>> 00400 allow udp from me to any out xmit em0 keep-state
>> 00500 allow ip from any to any
>> 65535 deny ip from any to any
>>
>> _______________________________________________
>> freebsd-ipfw@... mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
>>
>>
>
>
> _______________________________________________
> freebsd-ipfw@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
>

Re: ipfw: install_state: entry already present, done

2009-10-07T19:42:25Z

Did you try a check_state? I am using this same rule structure on BSD6
without a problem.

Thanks,
Jason
http://jasonlewis.yaritz.net

> Freddie Cash wrote:
>> On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis <chris@...> wrote:
>>
>>
>>> Haven't gotten any response on -questions so trying here. I've also
>>> opened
>>> a PR (kern/139226) but it's gotten no replies so I figured I should try
>>> here
>>> since I'm not certain if it's a bug or not. Regardless I am hoping for
>>> at
>>> least a work-around -- a few extra rules or settings to keep my console
>>> from
>>> being flooded by errors. So far only option I found is commenting out
>>> the
>>> error display line in the kernel source which is far from optimal.
>>>
>>> I'm trying to setup a stateful firewall for my server such that any
>>> traffic
>>> can go out, and it's reply come back -- a fairly typical workstation
>>> setup.
>>> However I'm getting the error message "ipfw: install_state: entry
>>> already
>>> present, done" repeated many times in my logs (tho the rules seemed to
>>> work
>>> fine otherwise).
>>>
>>> I stripped down the rules to the minimum I could and discovered the
>>> line
>>> causing it is "allow udp from me to any keep-state".
>>>
>>> Only seems to happen when I have bind running as a slave dns server
>>> (not
>>> publicly listed, just the zone replication traffic causes the error)
>>> but I
>>> assume any other large source of UDP traffic would also do it.
>>>
>>> Full firewall rules:
>>>
>>> dns2# ipfw list
>>> 00100 allow ip from any to any via lo0
>>> 00200 deny ip from any to 127.0.0.0/8
>>> 00300 deny ip from 127.0.0.0/8 to any
>>> 00400 allow udp from me to any keep-state
>>> 65535 deny ip from any to any
>>>
>>>
>>>
>> If you add "out xmit em0" to the udp rule, do the errors stop
> I added that and restarted bind (thus generating a bunch of UDP traffic)
> and the error still floods the console.
>
> Current rule set:
> 00100 allow ip from any to any via lo0
> 00200 deny ip from any to 127.0.0.0/8
> 00300 deny ip from 127.0.0.0/8 to any
> 00400 allow udp from me to any out xmit em0 keep-state
> 00500 allow ip from any to any
> 65535 deny ip from any to any
>
> _______________________________________________
> freebsd-ipfw@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."
>

_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."

Re: Extension of dummynet/ipfw to support userspace packet classification

2009-10-07T16:02:49Z

On Thu, Oct 08, 2009 at 12:54:52AM +0200, Luigi Rizzo wrote:

> On Wed, Oct 07, 2009 at 12:46:24PM -0700, Joe R wrote:
> > We at ironport have a requirement to do bandwidth management, but the
> > traffic classification (and selection of bandwidth pipes) is done in
> > userspace. The reason classification is done in userspace is because the
> > traffic classifications are something like streaming audio traffic, video
> > traffic, based on website categories etc.
> >
> >
> >
> > Our appliance is based on FreeBSD, and so we decided to look at dummynet to
> > support our requirement. We could not use dummynet as such because it uses
> > ipfw for packet classification, where packet classification (and pipe
> > selection) is done in kernel based on tcp/ip parameters like IP and port.
> >
> >
> >
> > So we decided to extended dummynet/ipfw to support packet classification in
> > userspace.
> >
> > Our idea is to extended socket structure to have a pipe number and have a
> > setsockoption to associate the pipe number to a socket structure. Then have
> > a new ipfw target (mappedpipe), which will pass the packet to dummynet
> > (similar to pipe target) but with the pipe number in the socket structure if
> > it is non-zero.
> >
> >
> >
> > I would like to know your comments on this proposal and if people are
> > interested, I will be happy to submit a patch on this.
>
> i think the feature is useful. However I would implement it as an
> ipfw 'option' called "sockarg" (or similar) as follows:
>
> ipfw pipe tablearg sockarg
>
> where 'sockarg' succeeds ONLY if the packet is associated to a socket
> for which the special setsockoption has been issued, and in this
> case sets the 'tablearg' to the value of the setsockopt. This is
> somewhat similar to the 'uid' and 'gid' options (except for setting
> tablearg). This way the mechanism can be very general (not limited
> to pipes) and the implementation is probably
> simpler than the one you propose.
>
> In terms of runtime costs, we can look at check_uidgid() function,
> and there are two ways to implement this feature:
> - as in check_uidgid() , actively lookup for a matching socket if one
> is not available. This is expensive but would allow the feature to
> match also incoming packets;
> - only match if the args->inp parameter is non-null, otherwise do not
> call in_pcblookup_hash(). This is cheaper but clearly only works
> for locally generated packets.
> Perhaps we could use an argument for 'sockarg' so we can decide
> whether to call or not the in_pcblookup_hash() on a case-by-case
> basis.

To complete the analysis, I must say that I don't know how intrusive
is the setsockopt that can attach a classification tag to the socket.
This is my main concern for merging your proposal into the system
(and i am only concerned about the socket part, the ipfw change is
trivial).

Also for completeness, there is also another possible approach to
address your problem, which is more general and fully contained in
ipfw (so less intrusive for the OS):

add a 'hashtable' structure to ipfw, which works in a way similar
to the 'table' with the difference that entries would be the whole
5-tuple of the packet.

There is already a hash table in ipfw (used for dynamic rules) so
it would be only a matter of adding the necessary glue to manipulate
the hash table from /sbin/ipfw. An additional bonus of this approach
is that one could use this new code to 'prime' the dynamic rule table
after a reboot, which is a feature that people ask from time to time.

cheers
luigi
_______________________________________________
freebsd-ipfw@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@..."