From vwe at FreeBSD.org Wed Oct 1 21:19:32 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Oct 1 21:19:37 2008 Subject: bin/127707: ipfw(8): ipfw add 10 count ip from any to 172.16.0.1, me does not work Message-ID: <200810012119.m91LJVDi009271@freefall.freebsd.org> Synopsis: ipfw(8): ipfw add 10 count ip from any to 172.16.0.1,me does not work State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Wed Oct 1 21:16:31 UTC 2008 State-Changed-Why: Joao, ipfw does support ``me'' in combination with other addresses: # ipfw add 10 count ip from any to \( 172.16.0.1 or me \) 00010 count ip from any to { 172.16.0.1 or dst-ip me } Please note the different syntax being used here. This has been checked on 7.1-PRERELEASE and should work the same way on other releases. I'm closing this report for now. If you disagree (does not work for you) please report back and we'll reopen this PR. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=127707 From dan_johnson at doomed.us Thu Oct 2 22:41:49 2008 From: dan_johnson at doomed.us (Dan Johnson) Date: Thu Oct 2 22:41:55 2008 Subject: IPFW fwd issue. Message-ID: After beating my head against this for days I ran out of places to look for information, and almost sent this as a help request instead of an observation. So excuse the present tense. All I am actually trying to accomplish is a simple (This worked flawless last i tried under 4.5) squid transparent proxy. I'm using this rule before the nat rule: 00100 fwd 127.0.0.1,3128 log ip from any to any 80 out When I attempt to hit port 80 on an external server, the security log shows the rule was processed, and claims it was forwarded to 127.0.0.1,3128. OK Watching tcpdump -nnvvei lo0 shows no relevant activity. BUT, watching tcpdump -nnvvei xl1 (external iface) shows the port 80 SYN being sent to the remote web server with the original source ip address from 192.168.0.0/24, still using the destination MAC of my default gateway. This is with or without the squid daemon running. And when i do have it running i have it on the local console with debugging enabled (incase a stray packet actually makes it in.) The same holds true if i setup the fwd to my xl1 interface ip address, or another host ex 192.168.0.30. Running tcpdump (Linux) eth0 in promisc on 192.168.0.30 also doesn't show any traffic being forwarded its way when configured to do so. So I'm inclined to beleive this isn't just an error on tcpdumps part (as there is an open issue reported with tcpdump and ipfw fwd) but that the traffic really isn't being modified. The only thing I was doing that is unique is I recompiled the ipfw module to include -DIPFIREWALL_NAT and -DIPFIREWALL_FORWARD instead of adding the whole mess to the base kernel. After noting that I was using a module, I said screw it, and compiled IPFW into the base kernel, viola now it works fine. From dan_johnson at doomed.us Fri Oct 3 02:35:35 2008 From: dan_johnson at doomed.us (Dan Johnson) Date: Fri Oct 3 02:35:42 2008 Subject: IPFW fwd issue. In-Reply-To: <48E580D1.2050106@sharktooth.org> References: <48E580D1.2050106@sharktooth.org> Message-ID: Correct. The issue was that watching lo0 "tcpdump -nnvvei lo0" didn't show the forwarded traffic, it was still going out xl1 unmodified, acting like the rule was a simple 'accept.' I saved this email draft then went back and recompiled my kernel to include ipfw at the core instead of as a module and that fixed everything. Apparently IPFIREWALL_FORWARD is horribly broken when compiled into ipfw as a module, I personally dont care that ipfw is a fixed part of that box's kernel now, but some might. Really the only reason I sent to the mailing list instead of discarding is so once it gets indexed, someone else banging their head against the wall will have this reference. :) On Thu, Oct 2, 2008 at 10:17 PM, Jason Lewis wrote: > 127.0.0.1 is on the interface of lo0. You will need to run tcpdump > against that interface to see the traffic. You also need to setup squid > with transparent forwarding. This means that squid will accept any packet > as another host. > > Dan Johnson wrote: > >> After beating my head against this for days I ran out of places to look >> for >> information, and almost sent this as a help request instead of an >> observation. So excuse the present tense. >> >> >> All I am actually trying to accomplish is a simple (This worked flawless >> last i tried under 4.5) squid transparent proxy. >> I'm using this rule before the nat rule: >> >> 00100 fwd 127.0.0.1,3128 log ip from any to any 80 out >> >> When I attempt to hit port 80 on an external server, the security log >> shows >> the rule was processed, and claims it was forwarded to 127.0.0.1,3128. OK >> >> Watching tcpdump -nnvvei lo0 shows no relevant activity. BUT, watching >> tcpdump -nnvvei xl1 (external iface) shows the port 80 SYN being sent to >> the >> remote web server with the original source ip address from 192.168.0.0/24 >> , >> still using the destination MAC of my default gateway. This is with or >> without the squid daemon running. And when i do have it running i have it >> on >> the local console with debugging enabled (incase a stray packet actually >> makes it in.) >> >> The same holds true if i setup the fwd to my xl1 interface ip address, or >> another host ex 192.168.0.30. >> >> Running tcpdump (Linux) eth0 in promisc on 192.168.0.30 also doesn't show >> any traffic being forwarded its way when configured to do so. So I'm >> inclined to beleive this isn't just an error on tcpdumps part (as there is >> an open issue reported with tcpdump and ipfw fwd) but that the traffic >> really isn't being modified. >> >> The only thing I was doing that is unique is I recompiled the ipfw module >> to >> include -DIPFIREWALL_NAT and -DIPFIREWALL_FORWARD instead of adding the >> whole mess to the base kernel. >> >> After noting that I was using a module, I said screw it, and compiled IPFW >> into the base kernel, viola now it works fine. >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> >> > > From julian at elischer.org Fri Oct 3 04:14:44 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Oct 3 04:14:51 2008 Subject: IPFW fwd issue. In-Reply-To: References: Message-ID: <48E59912.10903@elischer.org> Dan Johnson wrote: > After beating my head against this for days I ran out of places to look for > information, and almost sent this as a help request instead of an > observation. So excuse the present tense. > > > All I am actually trying to accomplish is a simple (This worked flawless > last i tried under 4.5) squid transparent proxy. so, what revision are you trying to do this on? I think in 6.1 it was disabled without an extra option. (see in LINT) > I'm using this rule before the nat rule: > > 00100 fwd 127.0.0.1,3128 log ip from any to any 80 out > > When I attempt to hit port 80 on an external server, the security log shows > the rule was processed, and claims it was forwarded to 127.0.0.1,3128. OK > > Watching tcpdump -nnvvei lo0 shows no relevant activity. BUT, watching > tcpdump -nnvvei xl1 (external iface) shows the port 80 SYN being sent to the > remote web server with the original source ip address from 192.168.0.0/24, > still using the destination MAC of my default gateway. This is with or > without the squid daemon running. And when i do have it running i have it on > the local console with debugging enabled (incase a stray packet actually > makes it in.) that sounds a bit like the problem I mention above... however, sending it to 127.0.0.1 doesn't mean it goes through lo0 so you'll never see it there. > > The same holds true if i setup the fwd to my xl1 interface ip address, or > another host ex 192.168.0.30. > > Running tcpdump (Linux) eth0 in promisc on 192.168.0.30 also doesn't show > any traffic being forwarded its way when configured to do so. So I'm > inclined to beleive this isn't just an error on tcpdumps part (as there is > an open issue reported with tcpdump and ipfw fwd) but that the traffic > really isn't being modified. > > The only thing I was doing that is unique is I recompiled the ipfw module to > include -DIPFIREWALL_NAT and -DIPFIREWALL_FORWARD instead of adding the > whole mess to the base kernel. ah that will fail because the IPFIREWALL_FORWARD option has to change things in teh tcp and Ip code too. > > After noting that I was using a module, I said screw it, and compiled IPFW > into the base kernel, viola now it works fine. yeah the whole ip stack need to be compiled with those options.. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From dan_johnson at doomed.us Fri Oct 3 04:18:07 2008 From: dan_johnson at doomed.us (Dan Johnson) Date: Fri Oct 3 04:18:15 2008 Subject: IPFW fwd issue. In-Reply-To: <48E59912.10903@elischer.org> References: <48E59912.10903@elischer.org> Message-ID: On Fri, Oct 3, 2008 at 12:01 AM, Julian Elischer wrote: > Dan Johnson wrote: > >> After beating my head against this for days I ran out of places to look >> for >> information, and almost sent this as a help request instead of an >> observation. So excuse the present tense. >> >> >> All I am actually trying to accomplish is a simple (This worked flawless >> last i tried under 4.5) squid transparent proxy. >> > > so, what revision are you trying to do this on? > I think in 6.1 it was disabled without an extra option. (see in LINT) > 7.0-Release. In my research I'd found that in 6 and I believe some point in 5.x the option IPFIREWALL_FORWARD_EXTENDED was needed for this configuration, but apparently it was switched back for 7. > > > > I'm using this rule before the nat rule: >> >> 00100 fwd 127.0.0.1,3128 log ip from any to any 80 out >> >> When I attempt to hit port 80 on an external server, the security log >> shows >> the rule was processed, and claims it was forwarded to 127.0.0.1,3128. OK >> >> Watching tcpdump -nnvvei lo0 shows no relevant activity. BUT, watching >> tcpdump -nnvvei xl1 (external iface) shows the port 80 SYN being sent to >> the >> remote web server with the original source ip address from 192.168.0.0/24 >> , >> still using the destination MAC of my default gateway. This is with or >> without the squid daemon running. And when i do have it running i have it >> on >> the local console with debugging enabled (incase a stray packet actually >> makes it in.) >> > > that sounds a bit like the problem I mention above... > however, sending it to 127.0.0.1 doesn't mean it goes through lo0 so > you'll never see it there. > > >> The same holds true if i setup the fwd to my xl1 interface ip address, or >> another host ex 192.168.0.30. >> >> Running tcpdump (Linux) eth0 in promisc on 192.168.0.30 also doesn't show >> any traffic being forwarded its way when configured to do so. So I'm >> inclined to beleive this isn't just an error on tcpdumps part (as there is >> an open issue reported with tcpdump and ipfw fwd) but that the traffic >> really isn't being modified. >> >> The only thing I was doing that is unique is I recompiled the ipfw module >> to >> include -DIPFIREWALL_NAT and -DIPFIREWALL_FORWARD instead of adding the >> whole mess to the base kernel. >> > > ah that will fail because the IPFIREWALL_FORWARD option has to change > things in teh tcp and Ip code too. > Thats what I figured might have been the case, odd that there were no errors logged in the firewall logs though. > > > >> After noting that I was using a module, I said screw it, and compiled IPFW >> into the base kernel, viola now it works fine. >> > > yeah the whole ip stack need to be compiled with those options.. Hopefully next person with this issue wont bang their head on the wall as long once this thread is indexed. :) > > > _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> > > From julian at elischer.org Fri Oct 3 04:36:48 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Oct 3 04:36:54 2008 Subject: IPFW fwd issue. In-Reply-To: References: <48E59912.10903@elischer.org> Message-ID: <48E5A166.8000806@elischer.org> Dan Johnson wrote: > On Fri, Oct 3, 2008 at 12:01 AM, Julian Elischer wrote: > >> Dan Johnson wrote: >> >>> After beating my head against this for days I ran out of places to look >>> for >>> information, and almost sent this as a help request instead of an >>> observation. So excuse the present tense. >>> >>> >>> All I am actually trying to accomplish is a simple (This worked flawless >>> last i tried under 4.5) squid transparent proxy. >>> >> so, what revision are you trying to do this on? >> I think in 6.1 it was disabled without an extra option. (see in LINT) >> > > 7.0-Release. In my research I'd found that in 6 and I believe some point in > 5.x the option IPFIREWALL_FORWARD_EXTENDED was needed for this > configuration, but apparently it was switched back for 7. yeah that was me switching it back.. the whole feature is kinds useless without being able to do that.. man ssh > >> >> >> I'm using this rule before the nat rule: >>> 00100 fwd 127.0.0.1,3128 log ip from any to any 80 out >>> >>> When I attempt to hit port 80 on an external server, the security log >>> shows >>> the rule was processed, and claims it was forwarded to 127.0.0.1,3128. OK >>> >>> Watching tcpdump -nnvvei lo0 shows no relevant activity. BUT, watching >>> tcpdump -nnvvei xl1 (external iface) shows the port 80 SYN being sent to >>> the >>> remote web server with the original source ip address from 192.168.0.0/24 >>> , >>> still using the destination MAC of my default gateway. This is with or >>> without the squid daemon running. And when i do have it running i have it >>> on >>> the local console with debugging enabled (incase a stray packet actually >>> makes it in.) >>> >> that sounds a bit like the problem I mention above... >> however, sending it to 127.0.0.1 doesn't mean it goes through lo0 so >> you'll never see it there. > > >> >>> The same holds true if i setup the fwd to my xl1 interface ip address, or >>> another host ex 192.168.0.30. >>> >>> Running tcpdump (Linux) eth0 in promisc on 192.168.0.30 also doesn't show >>> any traffic being forwarded its way when configured to do so. So I'm >>> inclined to beleive this isn't just an error on tcpdumps part (as there is >>> an open issue reported with tcpdump and ipfw fwd) but that the traffic >>> really isn't being modified. >>> >>> The only thing I was doing that is unique is I recompiled the ipfw module >>> to >>> include -DIPFIREWALL_NAT and -DIPFIREWALL_FORWARD instead of adding the >>> whole mess to the base kernel. >>> >> ah that will fail because the IPFIREWALL_FORWARD option has to change >> things in teh tcp and Ip code too. >> > > Thats what I figured might have been the case, odd that there were no errors > logged in the firewall logs though. > >> >> >>> After noting that I was using a module, I said screw it, and compiled IPFW >>> into the base kernel, viola now it works fine. >>> >> yeah the whole ip stack need to be compiled with those options.. > > > Hopefully next person with this issue wont bang their head on the wall as > long once this thread is indexed. :) > > >> >> _______________________________________________ >>> freebsd-ipfw@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >>> >> > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Oct 6 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 6 11:08:07 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200810061106.m96B6uIC035507@freefall.freebsd.org> 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/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 kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher 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 speci 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 47 problems total. From ganbold at micom.mng.net Tue Oct 7 13:29:55 2008 From: ganbold at micom.mng.net (Ganbold) Date: Tue Oct 7 13:30:08 2008 Subject: ipfw port lookup table patch for review In-Reply-To: <48DA1B65.8030106@micom.mng.net> References: <48DA1B65.8030106@micom.mng.net> Message-ID: <48EB6450.9050004@micom.mng.net> Hi, I have just made the patches that use arrays for port entries. It is under the same directory: http://people.freebsd.org/~ganbold/ipfw_port_table/ Array version (each array can have IPFW_TABLES_MAX entries): http://people.freebsd.org/~ganbold/ipfw_port_table/ipfw_port_table_array_unsorted/ List version is still at: http://people.freebsd.org/~ganbold/ipfw_port_table/ipfw_port_table_list_unsorted/ thanks, Ganbold Ganbold wrote: > Hi, > > I thought it might be useful to have port lookup table similar to > existing IP lookup table > in ipfw and I have made patch for that. > > The downside of the patch so far I'm seeing is the port entries are in > linked list > (no limitation yet, memory overhead), not sorted and it uses linear > search > to match (could be slow when lot of entries). > > Just after I've made the patch I saw > http://www.freebsd.org/cgi/query-pr.cgi?pr=121807&cat= . :( > > I agree with PR's reply however for small number of port entries I > thought > this functionality is quite useful. It gives benefit like no need to > modify existing rule, > adding/deleting port entries is easy. > > I did some small tests and it seems like working. > > Patches are at: > http://people.freebsd.org/~ganbold/ipfw_port_table/ > > The output of some usage samples is at: > http://people.freebsd.org/~ganbold/ipfw_port_table/ipfw_port_table_usage_sample.txt > > > Patches can be successfully applied to CURRENT. Didn't test RELENG_7 > due to > no RELENG_7 PC :) > Please let me know your thoughts. I'm happy to discuss to improve the > patch. > Correct me if I'm doing something wrong here. > > thanks, > > Ganbold > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From bugmaster at FreeBSD.org Mon Oct 13 11:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 13 11:08:06 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200810131106.m9DB6pGw029458@freefall.freebsd.org> 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/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 kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher 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 speci 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 47 problems total. From linzhao at ustc.edu.cn Wed Oct 15 09:45:57 2008 From: linzhao at ustc.edu.cn (Lin Zhao) Date: Wed Oct 15 09:46:06 2008 Subject: pls help on 2 public ip Message-ID: <424063004.07284@ustc.edu.cn> hi all we have a simple network |-------------| internal network---------| freeBSD |----------public network rl0/192.168.0.1|-------------|fxp0/a.b.c.1 a.b.c.2? currently 192.168.0.0/24 is natd to a.b.c.1, and i want to use another public ip (a.b.c.2) for some special websites, such as www.abc.com. how can i configure the ipfw? should i use alias ip or another nic? i'm a newbie to ipfw, thanks. Lin Zhao From to.dev.null at gmx.de Wed Oct 15 22:10:10 2008 From: to.dev.null at gmx.de (to.dev.null@gmx.de) Date: Wed Oct 15 23:23:51 2008 Subject: Expiration of dynamic rules Message-ID: <20081015214327.230570@gmx.net> Hello together, i have a strange phenomenon with dynamic rules. I am using Mac OS X 10..5.5 and have disabled keepalive-messages for dynamic rules: net.inet.ip.fw.dyn_keepalive: 0 ruleset host1 ... check-state allow tcp from me to any out setup keep-state ... 1.) host2: nc -k -l -p 1234 2.) host1: nc host2 1234 3.) dynamic rule with 300s gets created 4.) dynamic rule expired after 300s (ipfw -d show: rule is gone (it shows with flag -e)) 5.) nmap -PN -n -p ... --source-port 1234 --scanflags ack host After 5) that expired rule appeared again with 300s timeout and the firewall is again opened. I would expect that an expired rule could not be reanimated. The reactivation of expired rules seems to stop if after tcp fin from both hosts are detected. Thus if the tcp disconnection was not successfull there are some zombie rules which could be reanimated?!? (also with keepalive you could reproduce it: tcp rst -> then there is no keepalive message and the dynamic rule expires but can be reanimated with 5)) Jerry -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx From rik at inse.ru Thu Oct 16 02:11:37 2008 From: rik at inse.ru (Roman Kurakin) Date: Thu Oct 16 02:11:44 2008 Subject: Expiration of dynamic rules In-Reply-To: <20081015214327.230570@gmx.net> References: <20081015214327.230570@gmx.net> Message-ID: <48F6A160.901@localhost.inse.ru> to.dev.null@gmx.de wrote: > Hello together, > > i have a strange phenomenon with dynamic rules. I am using Mac OS X 10..5.5 and have disabled keepalive-messages for dynamic rules: > > net.inet.ip.fw.dyn_keepalive: 0 > > ruleset host1 > ... > check-state > allow tcp from me to any out setup keep-state > ... > > 1.) host2: nc -k -l -p 1234 > 2.) host1: nc host2 1234 > 3.) dynamic rule with 300s gets created > 4.) dynamic rule expired after 300s (ipfw -d show: rule is gone (it shows with flag -e)) > 5.) nmap -PN -n -p ... --source-port 1234 --scanflags ack host > > After 5) that expired rule appeared again with 300s timeout and the firewall is again opened. > > I would expect that an expired rule could not be reanimated. The reactivation of expired rules seems to stop if after tcp fin from both hosts are detected. Thus if the tcp disconnection was not successfull there are some zombie rules which could be reanimated?!? > IMHO if the connection starts from over again it is a new connection. It is not the old one reanimated. rik > (also with keepalive you could reproduce it: tcp rst -> then there is no keepalive message and the dynamic rule expires but can be reanimated with 5)) > > Jerry > > > From smithi at nimnet.asn.au Thu Oct 16 07:48:18 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Oct 16 07:48:25 2008 Subject: pls help on 2 public ip In-Reply-To: <424063004.07284@ustc.edu.cn> References: <424063004.07284@ustc.edu.cn> Message-ID: <20081016174847.U4254@sola.nimnet.asn.au> On Wed, 15 Oct 2008, Lin Zhao wrote: > hi all > > we have a simple network > > |-------------| > internal network---------| freeBSD |----------public network > rl0/192.168.0.1|-------------|fxp0/a.b.c.1 > a.b.c.2? > > currently 192.168.0.0/24 is natd to a.b.c.1, and i want to use another public ip > (a.b.c.2) for some special websites, such as www.abc.com. > > how can i configure the ipfw? > should i use alias ip or another nic? If a.b.c.2 is a separate box from a.b.c.1 you'll likely want a separate segment, ie on another nic. If the same box, you can use an fxp0 alias. Looks like you could probably use a slightly modified 'simple' ruleset in rc.firewall as a starting point - though you'll want to enable ICMP (see examples in the 'workstation' rules) and probably replace 'me' with the specific a.b.c addresses in rules for the various services offered. How is fxp0 connected to the public network? Via another router? Or eg PPPoE over ADSL? It may matter in terms of whether your uplink is via a single address - that is, is a.b.c.2 reachable directly from the public internet, or only via a.b.c.1? How many public IPs have you (netmask)? cheers, Ian From to.dev.null at gmx.de Thu Oct 16 08:08:09 2008 From: to.dev.null at gmx.de (Jerry) Date: Thu Oct 16 08:08:16 2008 Subject: Expiration of dynamic rules In-Reply-To: <48F6A160.901@localhost.inse.ru> References: <20081015214327.230570@gmx.net> <48F6A160.901@localhost.inse.ru> Message-ID: <344A1282-4B6D-4600-B30B-3A01EFBAAC33@gmx.de> my rules only allow tcp out (host1 -> host2) connections: >> allow tcp from me to any out setup keep-state (me should denote host1) But the nmap goes from host2 -> host1 which should be blocked by the firewall >> 5.) nmap -PN -n -p ... --source-port 1234 --scanflags ack host (i've made a mistake it should mean host1 instead of only host) Thus it seems to be the old dynamic rule. jerry Am 16.10.2008 um 04:05 schrieb Roman Kurakin: > to.dev.null@gmx.de wrote: >> Hello together, >> >> i have a strange phenomenon with dynamic rules. I am using Mac OS X >> 10..5.5 and have disabled keepalive-messages for dynamic rules: >> >> net.inet.ip.fw.dyn_keepalive: 0 >> >> ruleset host1 >> ... >> check-state >> allow tcp from me to any out setup keep-state >> ... >> >> 1.) host2: nc -k -l -p 1234 >> 2.) host1: nc host2 1234 >> 3.) dynamic rule with 300s gets created >> 4.) dynamic rule expired after 300s (ipfw -d show: rule is gone (it >> shows with flag -e)) >> 5.) nmap -PN -n -p ... --source-port 1234 --scanflags ack host >> >> After 5) that expired rule appeared again with 300s timeout and the >> firewall is again opened. >> >> I would expect that an expired rule could not be reanimated. The >> reactivation of expired rules seems to stop if after tcp fin from >> both hosts are detected. Thus if the tcp disconnection was not >> successfull there are some zombie rules which could be reanimated?!? >> > IMHO if the connection starts from over again it is a new > connection. It is not the old one > reanimated. > > rik >> (also with keepalive you could reproduce it: tcp rst -> then there >> is no keepalive message and the dynamic rule expires but can be >> reanimated with 5)) >> >> Jerry >> >> >> > From smithi at nimnet.asn.au Thu Oct 16 10:33:19 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Oct 16 10:33:26 2008 Subject: Speaking of rc.firewall .. Message-ID: <20081016212110.T4254@sola.nimnet.asn.au> I see that both HEAD and RELENG_7 rc.firewall have been updated for in- kernel NAT functionality, but only for the 'open' and 'client' rulesets. Is there any (functional) reason that the ${firewall_nat_enable} case is not also included in the 'simple' rules, where its different placement is determined by being preceded and anteceded by anti-spoofing rules? I'm also slightly bemused by the lack (still) of any rules to allow any ICMP (especially necessary icmptypes for MTU discovery) in 'simple'? cheers, Ian From patrick.matters at gmx.de Thu Oct 16 14:18:53 2008 From: patrick.matters at gmx.de (Patrick Matters) Date: Thu Oct 16 14:19:00 2008 Subject: Expiration of dynamic rules In-Reply-To: <20081015214327.230570@gmx.net> References: <20081015214327.230570@gmx.net> Message-ID: <7809E47C-7C44-43E3-A588-0C99D642FC6B@gmx.de> Hello, a real life example: ruleset host1 ... 00100 0 0 check-state 00101 0 0 allow tcp from me to any out setup keep-state ... sysctl net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 3 net.inet.ip.fw.dyn_fin_lifetime: 3 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 24 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_count: 237 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 2 net.inet.ip.fw.debug: 0 net.inet.ip.fw.one_pass: 0 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 tcpdump 11:57:12.452517 IP host1.port1 > host2.80: S 4285172461:4285172461(0) win 65535 11:57:12.465820 IP host2.80 > host1.port1: S 4165668431:4165668431(0) ack 4285172462 win 5672 11:57:12.465951 IP host1.port1 > host2.80: . ack 1 win 65535 ... some tcp ack and tcp ack,psh 11:57:12.703599 IP host2.80 > host1.port1: P 6629:7198(569) ack 721 win 112 11:57:12.703678 IP host1.port1 > host2.80: . ack 7198 win 65156 11:57:22.700872 IP host2.80 > host1.port1: F 7198:7198(0) ack 721 win 112 11:57:22.700997 IP host1.port1 > host2.80: . ack 7199 win 65535 12:02:07.529664 IP host1.port1 > host2.80: . ack 7199 win 0 12:02:07.529786 IP host1.port1 > host2.80: . ack 7199 win 65535 12:02:07.543323 IP host2.80 > host1.port1: R 4165675630:4165675630(0) win 0 12:02:07.545776 IP host2.80 > host1.port1: R 4165675630:4165675630(0) win 0 netstat tcp4 0 0 host1.port1 host2.80 CLOSE_WAIT CLOSE_WAIT means an established connection on host 1 receives a tcp fin from host 2 and host 1 sends tcp ack to host2. Now host2 waits for a tcp fin from host1 After tcp rst netstat shows no tcp socket with port1 anymore 'nmap -PN -n -S host2 -p port1 -e eth0 --source-port 80 --scanflags ack host1' (it could be any tcp flag or combination of that) The dynmaic rule reopens with timeout 3s and disappears after the timeout. I guess only a tcp fin from host1 would stop the reappearing of the dynamic rule. jerry Am 15.10.2008 um 23:43 schrieb to.dev.null@gmx.de: > Hello together, > > i have a strange phenomenon with dynamic rules. I am using Mac OS X > 10..5.5 and have disabled keepalive-messages for dynamic rules: > > net.inet.ip.fw.dyn_keepalive: 0 > > ruleset host1 > ... > check-state > allow tcp from me to any out setup keep-state > ... > > 1.) host2: nc -k -l -p 1234 > 2.) host1: nc host2 1234 > 3.) dynamic rule with 300s gets created > 4.) dynamic rule expired after 300s (ipfw -d show: rule is gone (it > shows with flag -e)) > 5.) nmap -PN -n -p ... --source-port 1234 --scanflags ack host > > After 5) that expired rule appeared again with 300s timeout and the > firewall is again opened. > > I would expect that an expired rule could not be reanimated. The > reactivation of expired rules seems to stop if after tcp fin from > both hosts are detected. Thus if the tcp disconnection was not > successfull there are some zombie rules which could be reanimated?!? > > (also with keepalive you could reproduce it: tcp rst -> then there > is no keepalive message and the dynamic rule expires but can be > reanimated with 5)) > > Jerry > > > -- > GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! > Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx > From smithi at nimnet.asn.au Thu Oct 16 18:24:46 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Oct 16 18:24:54 2008 Subject: Speaking of rc.firewall .. In-Reply-To: <20081016212110.T4254@sola.nimnet.asn.au> References: <20081016212110.T4254@sola.nimnet.asn.au> Message-ID: <20081017045034.A4254@sola.nimnet.asn.au> On Thu, 16 Oct 2008, Ian Smith wrote: > I see that both HEAD and RELENG_7 rc.firewall have been updated for in- > kernel NAT functionality, but only for the 'open' and 'client' rulesets. > > Is there any (functional) reason that the ${firewall_nat_enable} case is > not also included in the 'simple' rules, where its different placement > is determined by being preceded and anteceded by anti-spoofing rules? > > I'm also slightly bemused by the lack (still) of any rules to allow any > ICMP (especially necessary icmptypes for MTU discovery) in 'simple'? To put my patch where my mouth is, assuming that the answer to my first question is likely 'no', this is against the present RELENG_7 version. It addresses the second (ICMP) issue for 'client' and 'simple', and I see no harm in enabling outbound pings for such out-of-the-box setups? Hope this format's useful (just diff -u), and also that inline is ok. cheers, Ian --- rc.firewall.1.52.2.3 Fri Oct 17 01:34:56 2008 +++ rc.firewall Fri Oct 17 04:27:36 2008 @@ -116,15 +116,14 @@ # will then be run again on each packet after translation by natd # starting at the rule number following the divert rule. # -# For ``simple'' firewall type the divert rule should be put to a +# For ``simple'' firewall type the divert rule is included in a # different place to not interfere with address-checking rules. # -case ${firewall_type} in -[Oo][Pp][Ee][Nn]|[Cc][Ll][Ii][Ee][Nn][Tt]) +setup_nat () { case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then - ${fwcmd} add 50 divert natd ip4 from any to any via ${natd_interface} + ${fwcmd} add $1 divert natd ip4 from any to any via ${natd_interface} fi ;; esac @@ -138,11 +137,11 @@ firewall_nat_flags="if ${firewall_nat_interface} ${firewall_nat_flags}" fi ${fwcmd} nat 123 config log ${firewall_nat_flags} - ${fwcmd} add 50 nat 123 ip4 from any to any via ${firewall_nat_interface} + ${fwcmd} add $1 nat 123 ip4 from any to any via ${firewall_nat_interface} fi ;; esac -esac +} ############ # If you just configured ipfw in the kernel as a tool to solve network @@ -157,6 +156,7 @@ # case ${firewall_type} in [Oo][Pp][Ee][Nn]) + setup_nat 50 ${fwcmd} add 65000 pass all from any to any ;; @@ -172,6 +172,8 @@ # set this to your local network net="$firewall_client_net" + setup_nat 50 + # Allow any traffic to or from my own net. ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me @@ -197,6 +199,12 @@ # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + # Allow outbound pings + ${fwcmd} add pass icmp from me to any out icmptypes 8 keep-state + + # Allow essential ICMP: unreachable, source quench, TTL exceeded + ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 + # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. @@ -248,13 +256,7 @@ # translated by natd(8) would match the `deny' rule above. Similarly # an outgoing packet originated from it before being translated would # match the `deny' rule below. - case ${natd_enable} in - [Yy][Ee][Ss]) - if [ -n "${natd_interface}" ]; then - ${fwcmd} add divert natd all from any to any via ${natd_interface} - fi - ;; - esac + setup_nat # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} @@ -298,6 +300,12 @@ # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + + # Allow outbound pings from our net + ${fwcmd} add pass icmp from any to any out icmptypes 8 keep-state + + # Allow essential ICMP: unreachable, source quench, TTL exceeded + ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel From e9 at homei.net.ua Fri Oct 17 07:15:25 2008 From: e9 at homei.net.ua (Anatoliy) Date: Fri Oct 17 07:15:32 2008 Subject: ipfw rules optimitsing In-Reply-To: <20081017045034.A4254@sola.nimnet.asn.au> References: <20081016212110.T4254@sola.nimnet.asn.au> <20081017045034.A4254@sola.nimnet.asn.au> Message-ID: <48F83739.2090800@homei.net.ua> Greetings to all. I have a problem to optimise ipfw rules. When I have started to search for the decision there were some questions How it is possible to find out how many loading gives this or that rule or all corrected as a whole. Prompt as it better to make in practice? As it would be desirable to learn as dynamic pipes the quantity influences productivity, how many calculations in a second occur thus etc. if what or sysctl displaying expressly or by implication it is variables the information? thnx, an sorry for bad English. From julian at elischer.org Fri Oct 17 11:43:09 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Oct 17 11:43:16 2008 Subject: ipfw rules optimitsing In-Reply-To: <48F83739.2090800@homei.net.ua> References: <20081016212110.T4254@sola.nimnet.asn.au> <20081017045034.A4254@sola.nimnet.asn.au> <48F83739.2090800@homei.net.ua> Message-ID: <48F8743B.8050605@elischer.org> Anatoliy wrote: > Greetings to all. > > I have a problem to optimise ipfw rules. > When I have started to search for the decision there were some questions > How it is possible to find out how many > loading gives this or that rule or all corrected as a whole. > Prompt as it better to make in practice? > As it would be desirable to learn as dynamic pipes the quantity > influences productivity, > how many calculations in a second occur thus etc. > if what or sysctl displaying expressly or by implication it is variables > the information? > > thnx, an sorry for bad English. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" This sounds like something that would be a useful project.. (to profile ipfw) you could try kernel bb profiling if it still works or you could try other ways to work it out.. So far we do not have this information so if you do it we would be very interested. From e9 at homei.net.ua Fri Oct 17 16:56:04 2008 From: e9 at homei.net.ua (Anatoliy) Date: Fri Oct 17 16:56:11 2008 Subject: ipfw rules optimitsing In-Reply-To: <48F8743B.8050605@elischer.org> References: <20081016212110.T4254@sola.nimnet.asn.au> <20081017045034.A4254@sola.nimnet.asn.au> <48F83739.2090800@homei.net.ua> <48F8743B.8050605@elischer.org> Message-ID: <48F8C3A0.1000906@homei.net.ua> Julian Elischer ?????: > Anatoliy wrote: >> Greetings to all. >> >> I have a problem to optimise ipfw rules. >> When I have started to search for the decision there were some questions >> How it is possible to find out how many >> loading gives this or that rule or all corrected as a whole. >> Prompt as it better to make in practice? >> As it would be desirable to learn as dynamic pipes the quantity >> influences productivity, >> how many calculations in a second occur thus etc. >> if what or sysctl displaying expressly or by implication it is >> variables the information? >> >> thnx, an sorry for bad English. >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > This sounds like something that would be a useful project.. > (to profile ipfw) > > you could try kernel bb profiling if it still works or you could try > other ways to work it out.. where i can read about this "bb profiling"? > > So far we do not have this information so if you do it we would be > very interested. at now i use a simple sh script but in not all whot i need ... ------ Script ------ [ ~/util]# cat ipfw_load.sh printf "IPFW match/s\t act/s\t d_steps\t d_searches\t PFnat searches match\t\t CPU sys intrpt idle \n" n=0; while : do ipfw -T sho |awk '{print $4}'|sort -rn >/tmp/ipfw_timest # geting time stamps TS_FW_MAX=`head -1 /tmp/ipfw_timest` # getting last time stamp FW_ACT=`cat /tmp/ipfw_timest|grep ${TS_FW_MAX}|grep -c ""` # couning activ rules val1_rs=$((`ipfw sho |awk '{print $2"+"}'`0)) # how match pacets val1_dnet_stps=`sysctl -n net.inet.ip.dummynet.search_steps` # how match searches steps val1_snet_searchs=`sysctl -n net.inet.ip.dummynet.searches` # how match searches sleep 1 val2_rs=$((`ipfw sho |awk '{print $2"+"}'`0)) # after 1s how match pacets val2_dnet_stps=`sysctl -n net.inet.ip.dummynet.search_steps` # after 1s how match searches steps val2_snet_searchs=`sysctl -n net.inet.ip.dummynet.searches` # after 1s how match searches MPS=$(($val2_rs-$val1_rs)) # pps DSTPSPS=$(($val2_dnet_stps-$val1_dnet_stps)) # dummynet searches steps per sec DSRCHSPS=$(($val2_snet_searchs-$val1_snet_searchs)) # dummynet searches per sec CPU_LD=`iostat -c 2 -t proc |tail +4|awk '{print $5" "$6" "$7}'` # cpu load PFNAT=`pfctl -si|grep -wE "(searches)|(match)"|sed s:\/s::|awk '{print $3}'|tr \\\n " "` if [ $n -eq 10 ]; then n=0 printf "\n IPFW match/s\t act/s\t d_steps\t d_searches\t PFnat searches match\t\t CPU sys intrpt idle \n" fi printf "${MPS}\t\t ${FW_ACT}\t ${DSTPSPS}\t\t ${DSRCHSPS}\t\t ${PFNAT}\t ${CPU_LD} \n" n=$(($n+1)) done From bugmaster at FreeBSD.org Mon Oct 20 11:06:53 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 20 11:08:06 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200810201106.m9KB6qgd082691@freefall.freebsd.org> 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/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 kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher 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 speci 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 47 problems total. From leander.schaefer at gmx.net Mon Oct 20 21:41:43 2008 From: leander.schaefer at gmx.net (Leander S.) Date: Mon Oct 20 21:41:49 2008 Subject: IPFW + Portforwarding Message-ID: <48FCF4D2.4080103@gmx.net> Hi, I'm trying to set up something like a HotSpot. Goal is it to force unregistred users to get redirected to the Captive Portalsite where they'll be able to agree my licence therms and get some information ... etc. ... So fact is I need an IPFW rule which forwards Port 80,443,8080 Traffic to another Port i.e. 8080 --> where my Apache will already wait for serving the Captive Portalsite back to the request. So I did read the man and saw something like the fwd rule and the Kernel Option for it - so I added the option - rcompiled the Kernel and gave my Firewall the following fwd rule in an extra script: ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any 80,443,8080 in via ${LAN_if} ^^ But it's sadly not working .... so here is my whole Firewallscript. Btw. my IPFW is compiled as default deny into the Kernel. The Script: ____________________________________________________________________________ #!/bin/sh if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi ############################# #### Globale Variablen: ##### ############################# WAN_if="msk0" WAN_IP="10.1.10.50" WAN_net="255.0.0.0" WAN="10.0.0.0/8" LAN_if="ath0" LAN_IP="192.1.1.1" LAN_net="255.255.255.0" LAN="192.1.1.0/24" fwcmd="/sbin/ipfw -q" ############################# ########## Start: ########### ############################# ### Firewall Reset ### ${fwcmd} -f flush ### Localhost ### ${fwcmd} add 00100 allow all from any to any via lo0 ${fwcmd} add 00200 deny all from any to 127.0.0.0/8 ${fwcmd} add 00300 deny all from 127.0.0.0/8 to any ### WAN Konfiguration ### ${fwcmd} add 00400 allow all from any to any via ${WAN_if} ${fwcmd} add 00500 divert natd all from any to any in via ${WAN_if} ${fwcmd} add 00600 divert natd all from any to any out via ${WAN_if} ### LAN Konfiguration ### ### Ping ${fwcmd} add 00700 allow icmp from ${LAN} to ${LAN} icmptypes 0,8 ### Portfreigabe ${fwcmd} add 00800 allow tcp from any to ${LAN_IP} 22 in via ${LAN_if} ${fwcmd} add 00900 allow tcp from any to ${LAN_IP} 1723 in via ${LAN_if} ${fwcmd} add 01000 allow tcp from any to ${LAN_IP} 8080 in via ${LAN_if} ### PortalSite - Forwarding: ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any 80,8080,443 in via ${LAN_if} ### Package Detour ${fwcmd} add 01200 allow all from any to any out via ${LAN_if} ____________________________________________________________________________ Every positiv type of help will be very appreciated !!! Thanks, Leander P.S. Additionally: This is my first firewallscript - so if this seems to be to ugly for you - feel free to give me some NewBee tips and tricks! ;) THX -------------- next part -------------- #!/bin/sh if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi ############################# #### Globale Variablen: ##### ############################# WAN_if="msk0" WAN_IP="10.1.10.50" WAN_net="255.0.0.0" WAN="10.0.0.0/8" LAN_if="ath0" LAN_IP="192.1.1.1" LAN_net="255.255.255.0" LAN="192.1.1.0/24" fwcmd="/sbin/ipfw -q" ############################# ########## Start: ########### ############################# ### Firewall Reset ### ${fwcmd} -f flush ### Localhost ### ${fwcmd} add 00100 allow all from any to any via lo0 ${fwcmd} add 00200 deny all from any to 127.0.0.0/8 ${fwcmd} add 00300 deny all from 127.0.0.0/8 to any ### WAN Konfiguration ### ${fwcmd} add 00400 allow all from any to any via ${WAN_if} ${fwcmd} add 00500 divert natd all from any to any in via ${WAN_if} ${fwcmd} add 00600 divert natd all from any to any out via ${WAN_if} ### LAN Konfiguration ### ### Ping ${fwcmd} add 00700 allow icmp from ${LAN} to ${LAN} icmptypes 0,8 ### Portfreigabe ${fwcmd} add 00800 allow tcp from any to ${LAN_IP} 22 in via ${LAN_if} ${fwcmd} add 00900 allow tcp from any to ${LAN_IP} 1723 in via ${LAN_if} ${fwcmd} add 01000 allow tcp from any to ${LAN_IP} 8080 in via ${LAN_if} ### PortalSite - Forwarding: ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any 80,8080,443 in via ${LAN_if} ### Package Detour ${fwcmd} add 01200 allow all from any to any out via ${LAN_if} From leander.schaefer at googlemail.com Mon Oct 20 21:43:17 2008 From: leander.schaefer at googlemail.com (Leander S.) Date: Mon Oct 20 21:43:24 2008 Subject: IPFW + Portforwarding Message-ID: <48FCF5DA.5060802@googlemail.com> Hi, I'm trying to set up something like a HotSpot. Goal is it to force unregistred users to get redirected to the Captive Portalsite where they'll be able to agree my licence therms and get some information ... etc. ... So fact is I need an IPFW rule which forwards Port 80,443,8080 Traffic to another Port i.e. 8080 --> where my Apache will already wait for serving the Captive Portalsite back to the request. So I did read the man and saw something like the fwd rule and the Kernel Option for it - so I added the option - rcompiled the Kernel and gave my Firewall the following fwd rule in an extra script: ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any 80,443,8080 in via ${LAN_if} ^^ But it's sadly not working .... so here is my whole Firewallscript. Btw. my IPFW is compiled as default deny into the Kernel. The Script: ____________________________________________________________________________ #!/bin/sh if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi ############################# #### Globale Variablen: ##### ############################# WAN_if="msk0" WAN_IP="10.1.10.50" WAN_net="255.0.0.0" WAN="10.0.0.0/8" LAN_if="ath0" LAN_IP="192.1.1.1" LAN_net="255.255.255.0" LAN="192.1.1.0/24" fwcmd="/sbin/ipfw -q" ############################# ########## Start: ########### ############################# ### Firewall Reset ### ${fwcmd} -f flush ### Localhost ### ${fwcmd} add 00100 allow all from any to any via lo0 ${fwcmd} add 00200 deny all from any to 127.0.0.0/8 ${fwcmd} add 00300 deny all from 127.0.0.0/8 to any ### WAN Konfiguration ### ${fwcmd} add 00400 allow all from any to any via ${WAN_if} ${fwcmd} add 00500 divert natd all from any to any in via ${WAN_if} ${fwcmd} add 00600 divert natd all from any to any out via ${WAN_if} ### LAN Konfiguration ### ### Ping ${fwcmd} add 00700 allow icmp from ${LAN} to ${LAN} icmptypes 0,8 ### Portfreigabe ${fwcmd} add 00800 allow tcp from any to ${LAN_IP} 22 in via ${LAN_if} ${fwcmd} add 00900 allow tcp from any to ${LAN_IP} 1723 in via ${LAN_if} ${fwcmd} add 01000 allow tcp from any to ${LAN_IP} 8080 in via ${LAN_if} ### PortalSite - Forwarding: ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any 80,8080,443 in via ${LAN_if} ### Package Detour ${fwcmd} add 01200 allow all from any to any out via ${LAN_if} ____________________________________________________________________________ Every positiv type of help will be very appreciated !!! Thanks, Leander P.S. Additionally: This is my first firewallscript - so if this seems to be to ugly for you - feel free to give me some NewBee tips and tricks! ;) THX From jhay at meraka.org.za Tue Oct 21 04:03:53 2008 From: jhay at meraka.org.za (John Hay) Date: Tue Oct 21 04:04:06 2008 Subject: IPFW + Portforwarding In-Reply-To: <48FCF5DA.5060802@googlemail.com> References: <48FCF5DA.5060802@googlemail.com> Message-ID: <20081021040349.GA29232@zibbi.meraka.csir.co.za> On Mon, Oct 20, 2008 at 11:19:22PM +0200, Leander S. wrote: > Hi, > > I'm trying to set up something like a HotSpot. Goal is it to force > unregistred users to get redirected to the Captive Portalsite where > they'll be able to agree my licence therms and get some information ... > etc. ... > > So fact is I need an IPFW rule which forwards Port 80,443,8080 Traffic > to another Port i.e. 8080 --> where my Apache will already wait for > serving the Captive Portalsite back to the request. > > So I did read the man and saw something like the fwd rule and the Kernel > Option for it - so I added the option - rcompiled the Kernel and gave my > Firewall the following fwd rule in an extra script: > > ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any > 80,443,8080 in via ${LAN_if} You have to catch it where it is going out and not in. Fwd only works when packets are out bound. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From rik at inse.ru Tue Oct 21 04:46:50 2008 From: rik at inse.ru (Roman Kurakin) Date: Tue Oct 21 04:47:06 2008 Subject: IPFW + Portforwarding In-Reply-To: <20081021040349.GA29232@zibbi.meraka.csir.co.za> References: <48FCF5DA.5060802@googlemail.com> <20081021040349.GA29232@zibbi.meraka.csir.co.za> Message-ID: <48FD5ED0.2030909@localhost.inse.ru> John Hay wrote: > On Mon, Oct 20, 2008 at 11:19:22PM +0200, Leander S. wrote: > >> Hi, >> >> I'm trying to set up something like a HotSpot. Goal is it to force >> unregistred users to get redirected to the Captive Portalsite where >> they'll be able to agree my licence therms and get some information ... >> etc. ... >> >> So fact is I need an IPFW rule which forwards Port 80,443,8080 Traffic >> to another Port i.e. 8080 --> where my Apache will already wait for >> serving the Captive Portalsite back to the request. >> >> So I did read the man and saw something like the fwd rule and the Kernel >> Option for it - so I added the option - rcompiled the Kernel and gave my >> Firewall the following fwd rule in an extra script: >> >> ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any >> 80,443,8080 in via ${LAN_if} >> Try to make the rule stateful, eq add 'setup keep-state'. Also add some logging in the rule and add the last one additional deny with the logging. > You have to catch it where it is going out and not in. Fwd only works > when packets are out bound. > But how this works for me? ipfw fwd 192.168.0.4,3128 log logamount 1000 tcp from 172.22.4.0/24 to 172.22.4.254 dst-port 3128 setup in via vr0 keep-state rik > John > From jhay at meraka.org.za Tue Oct 21 06:10:10 2008 From: jhay at meraka.org.za (John Hay) Date: Tue Oct 21 06:10:16 2008 Subject: IPFW + Portforwarding In-Reply-To: <48FD5ED0.2030909@localhost.inse.ru> References: <48FCF5DA.5060802@googlemail.com> <20081021040349.GA29232@zibbi.meraka.csir.co.za> <48FD5ED0.2030909@localhost.inse.ru> Message-ID: <20081021061005.GA34936@zibbi.meraka.csir.co.za> On Tue, Oct 21, 2008 at 08:47:12AM +0400, Roman Kurakin wrote: > John Hay wrote: > >On Mon, Oct 20, 2008 at 11:19:22PM +0200, Leander S. wrote: > > > >>Hi, > >> > >>I'm trying to set up something like a HotSpot. Goal is it to force > >>unregistred users to get redirected to the Captive Portalsite where > >>they'll be able to agree my licence therms and get some information ... > >>etc. ... > >> > >>So fact is I need an IPFW rule which forwards Port 80,443,8080 Traffic > >>to another Port i.e. 8080 --> where my Apache will already wait for > >>serving the Captive Portalsite back to the request. > >> > >>So I did read the man and saw something like the fwd rule and the Kernel > >>Option for it - so I added the option - rcompiled the Kernel and gave my > >>Firewall the following fwd rule in an extra script: > >> > >> ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any > >>80,443,8080 in via ${LAN_if} > >> > Try to make the rule stateful, eq add 'setup keep-state'. Also add some > logging in the rule > and add the last one additional deny with the logging. Adding logging is a good idea. Does keep-state work with fwd? I did not know that. I just assumed that it would not. > >You have to catch it where it is going out and not in. Fwd only works > >when packets are out bound. > > > But how this works for me? > > ipfw fwd 192.168.0.4,3128 log logamount 1000 tcp from 172.22.4.0/24 to > 172.22.4.254 dst-port 3128 setup in via vr0 keep-state I don't know. I did not think it will work. The way I understand it, is that fwd is a little like routing, it does not change the ip packet, so in effect it only change the mac address of the next hop and the interface, if needed. One other thing that might be a problem is if ipfw was just loaded as a module and not compiled in. There were reports that fwd does not work with the module. On all the boxes that I use fwd, ipfw is compiled into the kernel. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From linimon at FreeBSD.org Tue Oct 21 10:45:37 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Oct 21 10:45:49 2008 Subject: kern/128260: [ipfw] [patch] ipfw_divert damages IPv6 packets Message-ID: <200810211045.m9LAjbk5042026@freefall.freebsd.org> Synopsis: [ipfw] [patch] ipfw_divert damages IPv6 packets Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Tue Oct 21 10:43:36 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128260 From sem at FreeBSD.org Tue Oct 21 11:29:50 2008 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Tue Oct 21 11:29:56 2008 Subject: IPFW + Portforwarding In-Reply-To: <20081021061005.GA34936@zibbi.meraka.csir.co.za> References: <48FCF5DA.5060802@googlemail.com> <20081021040349.GA29232@zibbi.meraka.csir.co.za> <48FD5ED0.2030909@localhost.inse.ru> <20081021061005.GA34936@zibbi.meraka.csir.co.za> Message-ID: <48FDB93E.9030604@FreeBSD.org> John Hay wrote: > On Tue, Oct 21, 2008 at 08:47:12AM +0400, Roman Kurakin wrote: >> John Hay wrote: >>> On Mon, Oct 20, 2008 at 11:19:22PM +0200, Leander S. wrote: >>> You have to catch it where it is going out and not in. Fwd only works >>> when packets are out bound. >>> >> But how this works for me? >> >> ipfw fwd 192.168.0.4,3128 log logamount 1000 tcp from 172.22.4.0/24 to >> 172.22.4.254 dst-port 3128 setup in via vr0 keep-state > > I don't know. I did not think it will work. The way I understand it, > is that fwd is a little like routing, it does not change the ip > packet, so in effect it only change the mac address of the next hop > and the interface, if needed. No. Really it does not meter where a packet was caught. It's marked for forwarding if it's matched with a fwd rule. -- Dixi. Sem. From bugmaster at FreeBSD.org Mon Oct 27 11:07:15 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 27 11:08:16 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200810271107.m9RB7EWJ001974@freefall.freebsd.org> 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/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 kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher 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 speci 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 48 problems total. From leander.schaefer at googlemail.com Mon Oct 27 13:58:31 2008 From: leander.schaefer at googlemail.com (Leander S.) Date: Mon Oct 27 13:58:39 2008 Subject: Portforwarding - still the same issue Message-ID: <4905C902.9040306@googlemail.com> Roman Kurakin schrieb: > John Hay wrote: >> On Mon, Oct 20, 2008 at 11:19:22PM +0200, Leander S. wrote: >> >>> Hi, >>> >>> I'm trying to set up something like a HotSpot. Goal is it to force >>> unregistred users to get redirected to the Captive Portalsite where >>> they'll be able to agree my licence therms and get some information >>> ... etc. ... >>> >>> So fact is I need an IPFW rule which forwards Port 80,443,8080 >>> Traffic to another Port i.e. 8080 --> where my Apache will already >>> wait for serving the Captive Portalsite back to the request. >>> >>> So I did read the man and saw something like the fwd rule and the >>> Kernel Option for it - so I added the option - rcompiled the Kernel >>> and gave my Firewall the following fwd rule in an extra script: >>> >>> ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any >>> 80,443,8080 in via ${LAN_if} >>> > Try to make the rule stateful, eq add 'setup keep-state'. Also add > some logging in the rule > and add the last one additional deny with the logging. Oh-oh ... Can't log right now - have to recompile the kernel before ... sry. >> You have to catch it where it is going out and not in. Fwd only works >> when packets are out bound. I don't think so ?! And what sence would it make? Because think twice ... I want to fwd incoming HTTP:80 packages to make them look like HTTP:8080 packages ... the outgoing ones are uninteresting because it's apache's job to send back Websitedata on port 8080 where it's listening anyway. >> > But how this works for me? > > ipfw fwd 192.168.0.4,3128 log logamount 1000 tcp from 172.22.4.0/24 > to 172.22.4.254 dst-port 3128 setup in via vr0 keep-state > > rik >> John >> I tried: [...] fwd 127.0.0.1,8080 tcp from 192.1.1.0/24 to me dst-port 80 setup in via ath0 keep-state as well as this one too: [...] fwd 127.0.0.1,8080 tcp from 192.1.1.0/24 to me src-port 80 dst-port 8080 setup in via ath0 keep-state ^^ But sadly without success - "root$ ipfw show" doesn't even show me at least one package going through .... not even blocked ones ... 0 0 ;-) But here is my szenario again: 127.0.0.1 is my FreeBSDMashine wehre IPFW acts and Apache22 Listens on port 8080. 192.1.1.0/24 is the ath0 Interface where Wirlessclients will try to klick http://google:80 BUT accidently should be fwded & run into my PortalSite:8080 192.1.1.1 is the Interfaces IP Adress. 192.1.1.1:8080 would you also bring as well as 127.0.0.1:8080 to the portalsite. Regards, Leander From leander.schaefer at googlemail.com Mon Oct 27 13:58:42 2008 From: leander.schaefer at googlemail.com (Leander S.) Date: Mon Oct 27 13:58:48 2008 Subject: Portforwarding - still the same issue Message-ID: <4905C90C.40506@googlemail.com> Another question would be if it is neccesary to open port 80 secificaly before doing some fwd .. or dows the fwd command also open port 80? I'm just not sure wether port 80 is opend twice - which wouldn't make sence ... ### HTTP Traffic forwarding to Apache:8080 ${fwcmd} add 21200 allow tcp from any to ${LAN_IP} 80 in via ${LAN_if} ${fwcmd} add 21300 allow tcp from any to ${LAN_IP} 8080 in via ${LAN_if} ${fwcmd} add 21400 fwd ${LAN_IP},8080 tcp from ${LAN} to me 80 setup in via ${LAN_if} keep-state root ~ # ipfw show 20100 8 4416 allow ip from any to any via lo0 20200 0 0 deny ip from any to 127.0.0.0/8 20300 0 0 deny ip from 127.0.0.0/8 to any 20400 40 4608 allow ip from any to any via msk0 20600 0 0 divert 8668 ip from any to any via msk0 20700 0 0 allow icmp from 192.1.1.0/24 to 192.1.1.0/24 icmptypes 0,8 20800 0 0 allow tcp from any to 192.1.1.1 dst-port 1723 in via ath0 20900 0 0 allow gre from any to 192.1.1.0/24 21000 0 0 allow gre from 192.1.1.0/24 to any 21100 0 0 allow gre from 192.1.1.0/24 to any out via ath0 21200 450 38013 allow tcp from any to 192.1.1.1 dst-port 80 in via ath0 21300 79 23633 allow tcp from any to 192.1.1.1 dst-port 8080 in via ath0 21400 0 0 fwd 192.1.1.1,8080 tcp from 192.1.1.0/24 to me dst-port 80 setup in via ath0 keep-state 21500 904 1243836 allow ip from any to any out via ath0 65535 5922 575146 deny ip from any to any root ~ # root ~ # sockstat | grep 8080 www httpd 6413 5 tcp46 *:8080 *:* www httpd 6390 5 tcp46 *:8080 *:* www httpd 6389 5 tcp46 *:8080 *:* www httpd 6388 5 tcp46 *:8080 *:* www httpd 6384 5 tcp46 *:8080 *:* www httpd 1459 5 tcp46 *:8080 *:* www httpd 840 5 tcp46 *:8080 *:* www httpd 839 5 tcp46 *:8080 *:* www httpd 838 5 tcp46 *:8080 *:* www httpd 837 5 tcp46 *:8080 *:* root httpd 751 5 tcp46 *:8080 *:* root ~ # Btw.: IPFW and anything else is compiled statically into FreeBSD Kernel - NO_MODULES=YES Regards, Leander From leander.schaefer at gmx.net Mon Oct 27 14:18:26 2008 From: leander.schaefer at gmx.net (Leander S.) Date: Mon Oct 27 14:18:33 2008 Subject: Portforwarding - still the same issue Message-ID: <4905CDAE.7080906@gmx.net> Roman Kurakin schrieb: > John Hay wrote: >> On Mon, Oct 20, 2008 at 11:19:22PM +0200, Leander S. wrote: >> >>> Hi, >>> >>> I'm trying to set up something like a HotSpot. Goal is it to force >>> unregistred users to get redirected to the Captive Portalsite where >>> they'll be able to agree my licence therms and get some information >>> ... etc. ... >>> >>> So fact is I need an IPFW rule which forwards Port 80,443,8080 >>> Traffic to another Port i.e. 8080 --> where my Apache will already >>> wait for serving the Captive Portalsite back to the request. >>> >>> So I did read the man and saw something like the fwd rule and the >>> Kernel Option for it - so I added the option - rcompiled the Kernel >>> and gave my Firewall the following fwd rule in an extra script: >>> >>> ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any >>> 80,443,8080 in via ${LAN_if} >>> > Try to make the rule stateful, eq add 'setup keep-state'. Also add > some logging in the rule > and add the last one additional deny with the logging. Oh-oh ... Can't log right now - have to recompile the kernel before ... sry. >> You have to catch it where it is going out and not in. Fwd only works >> when packets are out bound. I don't think so ?! And what sence would it make? Because think twice ... I want to fwd incoming HTTP:80 packages to make them look like HTTP:8080 packages ... the outgoing ones are uninteresting because it's apache's job to send back Websitedata on port 8080 where it's listening anyway. >> > But how this works for me? > > ipfw fwd 192.168.0.4,3128 log logamount 1000 tcp from 172.22.4.0/24 > to 172.22.4.254 dst-port 3128 setup in via vr0 keep-state > > rik >> John >> I tried: [...] fwd 127.0.0.1,8080 tcp from 192.1.1.0/24 to me dst-port 80 setup in via ath0 keep-state as well as this one too: [...] fwd 127.0.0.1,8080 tcp from 192.1.1.0/24 to me src-port 80 dst-port 8080 setup in via ath0 keep-state ^^ But sadly without success - "root$ ipfw show" doesn't even show me at least one package going through .... not even blocked ones ... 0 0 ;-) But here is my szenario again: 127.0.0.1 is my FreeBSDMashine wehre IPFW acts and Apache22 Listens on port 8080. 192.1.1.0/24 is the ath0 Interface where Wirlessclients will try to klick http://google:80 BUT accidently should be fwded & run into my PortalSite:8080 192.1.1.1 is the Interfaces IP Adress. 192.1.1.1:8080 would you also bring as well as 127.0.0.1:8080 to the portalsite. Regards, Leander From leander.schaefer at gmx.net Mon Oct 27 14:19:39 2008 From: leander.schaefer at gmx.net (Leander S.) Date: Mon Oct 27 14:19:45 2008 Subject: Portforwarding - still the same issue Message-ID: <4905CDF7.8090408@gmx.net> Another question would be if it is neccesary to open port 80 secificaly before doing some fwd .. or dows the fwd command also open port 80? I'm just not sure wether port 80 is opend twice - which wouldn't make sence ... ### HTTP Traffic forwarding to Apache:8080 ${fwcmd} add 21200 allow tcp from any to ${LAN_IP} 80 in via ${LAN_if} ${fwcmd} add 21300 allow tcp from any to ${LAN_IP} 8080 in via ${LAN_if} ${fwcmd} add 21400 fwd ${LAN_IP},8080 tcp from ${LAN} to me 80 setup in via ${LAN_if} keep-state root ~ # ipfw show 20100 8 4416 allow ip from any to any via lo0 20200 0 0 deny ip from any to 127.0.0.0/8 20300 0 0 deny ip from 127.0.0.0/8 to any 20400 40 4608 allow ip from any to any via msk0 20600 0 0 divert 8668 ip from any to any via msk0 20700 0 0 allow icmp from 192.1.1.0/24 to 192.1.1.0/24 icmptypes 0,8 20800 0 0 allow tcp from any to 192.1.1.1 dst-port 1723 in via ath0 20900 0 0 allow gre from any to 192.1.1.0/24 21000 0 0 allow gre from 192.1.1.0/24 to any 21100 0 0 allow gre from 192.1.1.0/24 to any out via ath0 21200 450 38013 allow tcp from any to 192.1.1.1 dst-port 80 in via ath0 21300 79 23633 allow tcp from any to 192.1.1.1 dst-port 8080 in via ath0 21400 0 0 fwd 192.1.1.1,8080 tcp from 192.1.1.0/24 to me dst-port 80 setup in via ath0 keep-state 21500 904 1243836 allow ip from any to any out via ath0 65535 5922 575146 deny ip from any to any root ~ # root ~ # sockstat | grep 8080 www httpd 6413 5 tcp46 *:8080 *:* www httpd 6390 5 tcp46 *:8080 *:* www httpd 6389 5 tcp46 *:8080 *:* www httpd 6388 5 tcp46 *:8080 *:* www httpd 6384 5 tcp46 *:8080 *:* www httpd 1459 5 tcp46 *:8080 *:* www httpd 840 5 tcp46 *:8080 *:* www httpd 839 5 tcp46 *:8080 *:* www httpd 838 5 tcp46 *:8080 *:* www httpd 837 5 tcp46 *:8080 *:* root httpd 751 5 tcp46 *:8080 *:* root ~ # Btw.: IPFW and anything else is compiled statically into FreeBSD Kernel - NO_MODULES=YES Regards, Leander From julian at elischer.org Mon Oct 27 16:33:16 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 27 16:33:23 2008 Subject: Portforwarding - still the same issue In-Reply-To: <4905C902.9040306@googlemail.com> References: <4905C902.9040306@googlemail.com> Message-ID: <4905ED4B.7040007@elischer.org> Leander S. wrote: > Roman Kurakin schrieb: >> John Hay wrote: >>> On Mon, Oct 20, 2008 at 11:19:22PM +0200, Leander S. wrote: >>> >>>> Hi, >>>> >>>> I'm trying to set up something like a HotSpot. Goal is it to force >>>> unregistred users to get redirected to the Captive Portalsite where >>>> they'll be able to agree my licence therms and get some information >>>> ... etc. ... >>>> >>>> So fact is I need an IPFW rule which forwards Port 80,443,8080 >>>> Traffic to another Port i.e. 8080 --> where my Apache will already >>>> wait for serving the Captive Portalsite back to the request. >>>> >>>> So I did read the man and saw something like the fwd rule and the >>>> Kernel Option for it - so I added the option - rcompiled the Kernel >>>> and gave my Firewall the following fwd rule in an extra script: >>>> >>>> ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any >>>> 80,443,8080 in via ${LAN_if} >>>> >> Try to make the rule stateful, eq add 'setup keep-state'. Also add >> some logging in the rule >> and add the last one additional deny with the logging. > Oh-oh ... Can't log right now - have to recompile the kernel before ... > sry. >>> You have to catch it where it is going out and not in. Fwd only works >>> when packets are out bound. I think you can forward an incoming packet out again.. I am sure I have done that. > I don't think so ?! And what sence would it make? Because think twice > ... I want to fwd incoming HTTP:80 packages to make them look like > HTTP:8080 packages ... the outgoing ones are uninteresting because it's > apache's job to send back Websitedata on port 8080 where it's listening > anyway. >>> >> But how this works for me? >> >> ipfw fwd 192.168.0.4,3128 log logamount 1000 tcp from 172.22.4.0/24 >> to 172.22.4.254 dst-port 3128 setup in via vr0 keep-state >> >> rik >>> John >>> > I tried: > > [...] fwd 127.0.0.1,8080 tcp from 192.1.1.0/24 to me dst-port 80 setup > in via ath0 keep-state > > as well as this one too: > > [...] fwd 127.0.0.1,8080 tcp from 192.1.1.0/24 to me src-port 80 > dst-port 8080 setup in via ath0 keep-state > > ^^ > But sadly without success - "root$ ipfw show" doesn't even show me at > least one package going through .... not even blocked ones ... 0 0 ;-) > > what version of FreeBSD.. forwarding was crippled in an early 6.x revision I think. you needed to ad another option as well. > > > But here is my szenario again: > > 127.0.0.1 is my FreeBSDMashine wehre IPFW acts and Apache22 Listens on > port 8080. > > 192.1.1.0/24 is the ath0 Interface where Wirlessclients will try to > klick http://google:80 BUT accidently should be fwded & run into my > PortalSite:8080 > 192.1.1.1 is the Interfaces IP Adress. 192.1.1.1:8080 would you also > bring as well as 127.0.0.1:8080 to the portalsite. > > > Regards, > > Leander > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From david at catwhisker.org Mon Oct 27 16:56:08 2008 From: david at catwhisker.org (David Wolfskill) Date: Mon Oct 27 16:56:14 2008 Subject: Any plans or desire for "bulk addition" to tables? Message-ID: <20081027164452.GC69155@bunrab.catwhisker.org> On my systems that are directly connected to network not known to be relatively "safe," I use ipfw a fair bit. Of late, I've taken to augmenting the usual rules that are sensitive to specific ports and the like with (early) rules that check certain ipfw tables; they are used in the following way: * Traffic where an endpoint is found in table 1 is blocked. Period. * Traffic where the source address is in table 2 is not permitted to initiate a 22/tcp connection. * Traffic where the source address is in table 3 is not permitted to initiate a 80/tcp or a 443/tcp connection. Reasons for the above are somewhat off-topic for the list; I'll merely comment that they have to do with perceived failure to respond to observed attempts at abuse: I will protect my networks. In any case, I've cobbled up a moderately complex mechanism for maintaining the tables in question, and table 1 (in particular) has grown to be rather large: d254(8.0-C)[1] sudo ipfw table 1 list | wc -l Password: 11230 d254(8.0-C)[2] ^1^2 sudo ipfw table 2 list | wc -l 1743 d254(8.0-C)[3] ^2^3 sudo ipfw table 3 list | wc -l 50 d254(8.0-C)[4] Unfortunately, the only way I've found to populate a given table is to issue ipfw table ${table} add ${netblock} for each "netblock" in the table (assuming that I don't care about the optional "value" parameter -- which I haven't found a use for). Issuing something on the order of 13K "ipfw table ... add" commands during the single- to multu-user transition tends to slow down the effective boot time a bit -- especially when I'm booting up CURRENT on my laptop (with WITNESS & INVARIANTS specified). Would some way to teach ipfw(8) how to perform some sort of "bulk add" of a bunch of table entries in a single command invocation be of interest to anyone else? Please include my address on responses, as I'm not subscribed to -ipfw@. (I've tweaked Reply-To to provide an MUA hint.) Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20081027/4041e6ac/attachment.pgp From julian at elischer.org Mon Oct 27 17:24:47 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 27 17:24:53 2008 Subject: Any plans or desire for "bulk addition" to tables? In-Reply-To: <20081027164452.GC69155@bunrab.catwhisker.org> References: <20081027164452.GC69155@bunrab.catwhisker.org> Message-ID: <4905F68F.2030403@elischer.org> David Wolfskill wrote: > On my systems that are directly connected to network not known to be > relatively "safe," I use ipfw a fair bit. > > Of late, I've taken to augmenting the usual rules that are sensitive to > specific ports and the like with (early) rules that check certain ipfw > tables; they are used in the following way: > > * Traffic where an endpoint is found in table 1 is blocked. Period. > > * Traffic where the source address is in table 2 is not permitted to > initiate a 22/tcp connection. > > * Traffic where the source address is in table 3 is not permitted to > initiate a 80/tcp or a 443/tcp connection. > > Reasons for the above are somewhat off-topic for the list; I'll merely > comment that they have to do with perceived failure to respond to > observed attempts at abuse: I will protect my networks. > > In any case, I've cobbled up a moderately complex mechanism for > maintaining the tables in question, and table 1 (in particular) has > grown to be rather large: > > d254(8.0-C)[1] sudo ipfw table 1 list | wc -l > Password: > 11230 > d254(8.0-C)[2] ^1^2 > sudo ipfw table 2 list | wc -l > 1743 > d254(8.0-C)[3] ^2^3 > sudo ipfw table 3 list | wc -l > 50 > d254(8.0-C)[4] > > Unfortunately, the only way I've found to populate a given table is to > issue > > ipfw table ${table} add ${netblock} you can read in a file of entries i.e. ipfw -q filename where each line is of the form table N add IP VAL this increases the speed many times as you are not starting ipfw(1) for each entry. > > for each "netblock" in the table (assuming that I don't care about the > optional "value" parameter -- which I haven't found a use for). oh I have lots of use for that... > > Issuing something on the order of 13K "ipfw table ... add" commands > during the single- to multu-user transition tends to slow down the > effective boot time a bit -- especially when I'm booting up CURRENT on > my laptop (with WITNESS & INVARIANTS specified). I add many thousands using hte method described above and it trakse a second or so you can alternatively do: myscript|ipfw -q /dev/stdin where 'myscript' generates the values. > > Would some way to teach ipfw(8) how to perform some sort of "bulk add" > of a bunch of table entries in a single command invocation be of > interest to anyone else? > > Please include my address on responses, as I'm not subscribed to -ipfw@. > (I've tweaked Reply-To to provide an MUA hint.) > > Peace, > david From leander.schaefer at gmx.net Mon Oct 27 21:39:31 2008 From: leander.schaefer at gmx.net (Leander S.) Date: Mon Oct 27 21:39:39 2008 Subject: Portforwarding - still the same issue In-Reply-To: <4905ED4B.7040007@elischer.org> References: <4905C902.9040306@googlemail.com> <4905ED4B.7040007@elischer.org> Message-ID: <49063510.3070102@gmx.net> Julian Elischer schrieb: > Leander S. wrote: >> Roman Kurakin schrieb: >>> John Hay wrote: >>>> On Mon, Oct 20, 2008 at 11:19:22PM +0200, Leander S. wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm trying to set up something like a HotSpot. Goal is it to force >>>>> unregistred users to get redirected to the Captive Portalsite >>>>> where they'll be able to agree my licence therms and get some >>>>> information ... etc. ... >>>>> >>>>> So fact is I need an IPFW rule which forwards Port 80,443,8080 >>>>> Traffic to another Port i.e. 8080 --> where my Apache will already >>>>> wait for serving the Captive Portalsite back to the request. >>>>> >>>>> So I did read the man and saw something like the fwd rule and the >>>>> Kernel Option for it - so I added the option - rcompiled the >>>>> Kernel and gave my Firewall the following fwd rule in an extra >>>>> script: >>>>> >>>>> ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any >>>>> 80,443,8080 in via ${LAN_if} >>>>> >>> Try to make the rule stateful, eq add 'setup keep-state'. Also add >>> some logging in the rule >>> and add the last one additional deny with the logging. >> Oh-oh ... Can't log right now - have to recompile the kernel before >> ... sry. >>>> You have to catch it where it is going out and not in. Fwd only works >>>> when packets are out bound. > > I think you can forward an incoming packet out again.. > I am sure I have done that. I'm also very sure - you might wanna have a quick look here: http://wannabe.guru.org/scott/hobbies/wireless/wireless.html ^^ That's where I've originally heard about that ... but it sadly didn't work out for me ... > >> I don't think so ?! And what sence would it make? Because think twice >> ... I want to fwd incoming HTTP:80 packages to make them look like >> HTTP:8080 packages ... the outgoing ones are uninteresting because >> it's apache's job to send back Websitedata on port 8080 where it's >> listening anyway. >>>> >>> But how this works for me? >>> >>> ipfw fwd 192.168.0.4,3128 log logamount 1000 tcp from 172.22.4.0/24 >>> to 172.22.4.254 dst-port 3128 setup in via vr0 keep-state >>> >>> rik >>>> John >>>> >> I tried: >> >> [...] fwd 127.0.0.1,8080 tcp from 192.1.1.0/24 to me dst-port 80 >> setup in via ath0 keep-state >> >> as well as this one too: >> >> [...] fwd 127.0.0.1,8080 tcp from 192.1.1.0/24 to me src-port 80 >> dst-port 8080 setup in via ath0 keep-state >> >> ^^ >> But sadly without success - "root$ ipfw show" doesn't even show me >> at least one package going through .... not even blocked ones ... 0 >> 0 ;-) >> >> > > what version of FreeBSD.. > forwarding was crippled in an early 6.x revision I think. > you needed to ad another option as well. I'm running the latest 7.0 RELEASE ... those are included into the Kernel NETGRAPH_IPFW IPFIREWALL IPFIREWALL_VERBOSE IPFIREWALL_VERBOSE_LIMIT=5 IPFIREWALL_FORWARD DUMMYNET IPDIVERT > >> >> >> But here is my szenario again: >> >> 127.0.0.1 is my FreeBSDMashine wehre IPFW acts and Apache22 Listens >> on port 8080. >> >> 192.1.1.0/24 is the ath0 Interface where Wirlessclients will try to >> klick http://google:80 BUT accidently should be fwded & run into my >> PortalSite:8080 >> 192.1.1.1 is the Interfaces IP Adress. 192.1.1.1:8080 would you also >> bring as well as 127.0.0.1:8080 to the portalsite. >> >> >> Regards, >> >> Leander >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From ali_professional at hotmail.com Tue Oct 28 08:45:07 2008 From: ali_professional at hotmail.com (techartist) Date: Tue Oct 28 11:20:37 2008 Subject: IPFW MAC FILTERING WITH PORT FORWARDING Message-ID: <20203051.post@talk.nabble.com> HI GEEKS! I HAVE 4 G STREAM OF INTERNET FOR MY ORGANIZATION FOR WHICH ON LAN SIDE I HAVE CACHE SERVER OF FREEBSD 4.9 STABLE RELEASE. ON THIS CACHE SERVER, THIS CACHE SERVER IS DOING TRANSPARENT PROXY ROLE. BUT MEANWHILE TO CONTROL MY LAN USERS I AM TRYING TO DO MAC FILTERING, WHAT I NEED THAT FIREWALL SHOULD CHECK THE USERS REQUEST IF THE REQUEST PASSED WITH MAC ADDRESS PRESENT IN FIREWALL FILE THAN IT ALLOW AND TRANSPARENTLY ALLOW THE STREAM OF INTERNET AND IF ITS NOT THAN IT TOTALLY DENY THAT CONNECTION ONLY. IF YOU HAVE ANY IDEA PLZ INFORM ME IMMEDIATLEY... I HAVE ALREADY DONE SOME TRICKS BUT ITS NOT WORKING ON , FIRST TELL ME THAN I DISCUSS YOU WITH MY APPLIED TRICKS... THANKS ALIZ -- View this message in context: http://www.nabble.com/IPFW-MAC-FILTERING-WITH-PORT-FORWARDING-tp20203051p20203051.html Sent from the freebsd-ipfw mailing list archive at Nabble.com.