From bugmaster at FreeBSD.org Mon Jan 5 11:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 5 11:08:18 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200901051106.n05B6rSD002816@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/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o 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 51 problems total. From linimon at FreeBSD.org Thu Jan 8 08:27:29 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Jan 8 08:27:40 2009 Subject: bin/130132: [patch] ipfw(8): no way to get mask from ipfw pipe show/list for some pipes Message-ID: <200901080827.n088RRiX074387@freefall.freebsd.org> Old Synopsis: no way to get mask from ipfw pipe show/list for some pipes New Synopsis: [patch] ipfw(8): no way to get mask from ipfw pipe show/list for some pipes Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 8 08:26:51 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130132 From bugmaster at FreeBSD.org Mon Jan 12 03:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 12 03:08:15 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200901121106.n0CB6rh6092018@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 bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o 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 52 problems total. From fbsdmail at dnswatch.com Sun Jan 18 01:13:49 2009 From: fbsdmail at dnswatch.com (fbsdmail@dnswatch.com) Date: Sun Jan 18 01:13:56 2009 Subject: possible to block one address on all ports? Message-ID: <1528c4e04e7e0d186cf8a9d9c4974ad6.dnswclient@webmail.dnswatch.com> Greetings, I have what I hope is a simple question that I /hope/ has a simple option. Here's my scenario; My current filtering is done on an application/ service level. While I'm anxious to migrate this to IPFW, I'm don't yet have the time available that will be required. But I have a situation that requires the need to drop any, and all requests from one single IP address. So I thought I might seize this situation as an opportunity to "get my feet wet" with IPFW. So here's my question; Is it possible for me to use IPFW without altering any traffic - that is; nothing changes on incoming/outgoing EXCEPT where this /evil/ IP is concerned? Or, can I start IPFW, and use it to ONLY drop all requests from this /evil/ IP no matter which ports that IP makes a request on? I can? Can/would anyone be willing to tell me how? Apologies in advance, I realize this is pretty "ground level stuff". But I feel if I could get a good start, getting up to speed from there will be a greatly shortened learning curve. Thank you for all your time and consideration. --Chris From kim at tinker.com Sun Jan 18 14:13:33 2009 From: kim at tinker.com (Kim Shrier) Date: Sun Jan 18 14:13:39 2009 Subject: possible to block one address on all ports? In-Reply-To: <1528c4e04e7e0d186cf8a9d9c4974ad6.dnswclient@webmail.dnswatch.com> References: <1528c4e04e7e0d186cf8a9d9c4974ad6.dnswclient@webmail.dnswatch.com> Message-ID: <4A2B0C19-799B-4C09-A887-8FDC6AE0B019@tinker.com> On Jan 18, 2009, at 1:38 AM, fbsdmail@dnswatch.com wrote: > Greetings, > I have what I hope is a simple question that I /hope/ has a simple > option. Here's my scenario; My current filtering is done on an > application/ > service level. While I'm anxious to migrate this to IPFW, I'm don't > yet > have the time available that will be required. But I have a > situation that > requires the need to drop any, and all requests from one single IP > address. > So I thought I might seize this situation as an opportunity to "get my > feet wet" with IPFW. So here's my question; > Is it possible for me to use IPFW without altering any traffic - > that is; > nothing changes on incoming/outgoing EXCEPT where this /evil/ IP is > concerned? > Or, can I start IPFW, and use it to ONLY drop all requests from this > /evil/ IP > no matter which ports that IP makes a request on? > I can? Can/would anyone be willing to tell me how? > Apologies in advance, I realize this is pretty "ground level stuff". > But I > feel if I could get a good start, getting up to speed from there > will be a > greatly shortened learning curve. > > Thank you for all your time and consideration. > > --Chris > > > _______________________________________________ > 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" > In order to use ipfw, you need to have it compiled into your kernel or you need to load the ipfw.so kernel module and then you need to enable filtering and finally you need to specify some rules to control the filtering. I am going to assume that you don't have ipfw compiled into your kernel and will need to load the kernel module. Probably the easiest way to get started is to define the following variables in /etc/rc.conf or /etc/rc.conf.local, your preference. firewall_enable="YES" firewall_type="OPEN" firewall_logging="YES" These directives enable ipfw, tell it to block nothing, and enables logging of blocked packets. You can then startup ipfw with the following command: # /etc/rc.d/ipfw start You can view the filtering rules that are installed with this command: # ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65535 deny ip from any to any The following discription of what happens is oversimplified but is accurate enough to get you started with ipfw. Each filter rule has a rule number. When a packet comes in, it is compared to each rule until there is a match. When there is a match, the specified action is carried out. In the rules above, the only action is allow or deny. There are other actions but you can learn about them later as you get more comfortable with ipfw. The first rule (100) allows all ip traffic that goes through the loopback interface to go on through. This basically says that anything on the machine that wants to talk to anything else on the machine via the loopback interface should be allowed to do it. The second rule (200) blocks anything whose destination ip is to the 127.0.0.0 network. The reason you want to block these packets is because legitimate network packets going to the 127.0.0.0 network should be on the lo0 interface. Those packets would have been matched by rule 100 and already allowed. They would never get to rule 200. So packets going to the 127.0.0.0 network but not on the lo0 interface are blocked. The third rule (300) is similar to rule 200 except that if blocks packets that have a source address on the 127.0.0.0 network that are not on the lo0 interface. Once again, legitimate packets coming from a 127.0.0.0 network address should be on lo0 and already allowed by rule 100. The fourth rule (65000) allows all ip packets with any source address and any destination address to go on through the filter. The fifth rule (65535) is installed by ipfw as the default rule. It blocks all ip packets that have not been explicitly allowed or blocked by previous rules. Once you have these rules in place, it is easy to add a rule to block traffic from the evil machine. Assuming that you want to block all ip traffic, including TCP, UDP, ICMP, etc., you can insert a rule after 300 and before 65000 to do this. # ipfw add 1000 deny log ip from www.xxx.yyy.zzz to any This defines a filter rule numbered 1000 that will be evaluated after rule 300. It will deny (drop) all ip packets with a source address of www.xxx.yyy.zzz and any destination address. It will also log this event to /var/log/security. If you don't want to log these packets, you can remove the word "log" from the above command. Viewing your rules should give you the following: # ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01000 deny log ip from www.xxx.yyy.zzz to any 65000 allow ip from any to any 65535 deny ip from any to any This gives you an open firewall that only blocks packets from the evil machine and spoofed 127.0.0.0/8 packets. Kim -- Kim Shrier - principal, Shrier and Deihl - mailto:kim@tinker.com Remote Unix Network Admin, Security, Internet Software Development Tinker Internet Services - Superior FreeBSD-based Web Hosting http://www.tinker.com/ From fbsdmail at dnswatch.com Sun Jan 18 15:28:53 2009 From: fbsdmail at dnswatch.com (fbsdmail@dnswatch.com) Date: Sun Jan 18 15:29:00 2009 Subject: possible to block one address on all ports? In-Reply-To: <4A2B0C19-799B-4C09-A887-8FDC6AE0B019@tinker.com> References: <1528c4e04e7e0d186cf8a9d9c4974ad6.dnswclient@webmail.dnswatch.com> <4A2B0C19-799B-4C09-A887-8FDC6AE0B019@tinker.com> Message-ID: <581b3767ad793d5bce046a42f6516798.dnswclient@webmail.dnswatch.com> Greetings Kim, and thank you very much for such a concise overview... On Sun, January 18, 2009 1:57 pm, Kim Shrier wrote: > On Jan 18, 2009, at 1:38 AM, fbsdmail@dnswatch.com wrote: > > >> Greetings, >> I have what I hope is a simple question that I /hope/ has a simple >> option. Here's my scenario; My current filtering is done on an >> application/ service level. While I'm anxious to migrate this to IPFW, >> I'm don't >> yet have the time available that will be required. But I have a situation >> that requires the need to drop any, and all requests from one single IP >> address. So I thought I might seize this situation as an opportunity to >> "get my >> feet wet" with IPFW. So here's my question; Is it possible for me to use >> IPFW without altering any traffic - >> that is; nothing changes on incoming/outgoing EXCEPT where this /evil/ IP >> is concerned? Or, can I start IPFW, and use it to ONLY drop all requests >> from this /evil/ IP >> no matter which ports that IP makes a request on? I can? Can/would anyone >> be willing to tell me how? Apologies in advance, I realize this is >> pretty "ground level stuff". But I >> feel if I could get a good start, getting up to speed from there will be >> a greatly shortened learning curve. >> >> Thank you for all your time and consideration. >> >> >> --Chris >> >> >> >> _______________________________________________ >> 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" >> > > > In order to use ipfw, you need to have it compiled into your kernel or > you need to load the ipfw.so kernel module and then you need to enable > filtering and finally you need to specify some rules to control the > filtering. > > I am going to assume that you don't have ipfw compiled into your kernel > and will need to load the kernel module. > > Probably the easiest way to get started is to define the following > variables in /etc/rc.conf or /etc/rc.conf.local, your preference. > > firewall_enable="YES" firewall_type="OPEN" firewall_logging="YES" > > These directives enable ipfw, tell it to block nothing, and enables > logging of blocked packets. You can then startup ipfw with the following > command: > > > # /etc/rc.d/ipfw start > > > You can view the filtering rules that are installed with this command: > > > # ipfw list > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 65000 allow ip from any to any > 65535 deny ip from any to any > > > The following discription of what happens is oversimplified but is > accurate enough to get you started with ipfw. Each filter rule has a rule > number. When a packet comes in, it is compared to each rule until there is > a match. When there is a match, the specified action is carried out. In > the rules above, the only action is allow or deny. There are other actions > but you can learn about them later as you get more comfortable with ipfw. > > The first rule (100) allows all ip traffic that goes through the > loopback interface to go on through. This basically says that anything on > the machine that wants to talk to anything else on the machine via the > loopback interface should be allowed to do it. > > The second rule (200) blocks anything whose destination ip is to the > 127.0.0.0 > network. The reason you want to block these packets is because legitimate > network packets going to the 127.0.0.0 network should be on the lo0 > interface. Those packets would have been matched by rule 100 and already > allowed. They would never get to rule 200. So packets going to the > 127.0.0.0 > network but not on the lo0 interface are blocked. > > The third rule (300) is similar to rule 200 except that if blocks > packets that have a source address on the 127.0.0.0 network that are not on > the lo0 interface. Once again, legitimate packets coming from a > 127.0.0.0 > network address should be on lo0 and already allowed by rule 100. > > The fourth rule (65000) allows all ip packets with any source address > and any destination address to go on through the filter. > > The fifth rule (65535) is installed by ipfw as the default rule. It > blocks all ip packets that have not been explicitly allowed or blocked by > previous rules. > > Once you have these rules in place, it is easy to add a rule to block > traffic from the evil machine. Assuming that you want to block all ip > traffic, including TCP, UDP, ICMP, etc., you can insert a rule after 300 > and before 65000 to do this. > > > # ipfw add 1000 deny log ip from www.xxx.yyy.zzz to any > > > This defines a filter rule numbered 1000 that will be evaluated after > rule 300. It will deny (drop) all ip packets with a source address of > www.xxx.yyy.zzz and any destination address. It will also log this event to > /var/log/security. If you don't want to log these packets, you can > remove the word "log" from the above command. > > Viewing your rules should give you the following: > > > # ipfw list > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 01000 deny log ip from www.xxx.yyy.zzz to any > 65000 allow ip from any to any > 65535 deny ip from any to any > > > This gives you an open firewall that only blocks packets from the evil > machine and spoofed 127.0.0.0/8 packets. I find I'm only left with one question; If my box is assigned an internet routable IP (not a private IP), which address should take precedence? In other words, knowing that IPFW works "top down", or "first match". How would/should I add my internet routable IP (assuming I should). Or should I simply replace 127.0.0.1 with my internet routable IP as shown in your example? I see you have posted another reply. I'll see if you've already addressed my question in that reply. :) Thank you again for taking the time to be so helpful. Best wishes. --Chris > > Kim > > > -- > Kim Shrier - principal, Shrier and Deihl - mailto:kim@tinker.com > Remote Unix Network Admin, Security, Internet Software Development > Tinker Internet Services - Superior FreeBSD-based Web Hosting > http://www.tinker.com/ > > > > From kim at tinker.com Sun Jan 18 16:42:23 2009 From: kim at tinker.com (Kim Shrier) Date: Sun Jan 18 16:42:30 2009 Subject: possible to block one address on all ports? In-Reply-To: <581b3767ad793d5bce046a42f6516798.dnswclient@webmail.dnswatch.com> References: <1528c4e04e7e0d186cf8a9d9c4974ad6.dnswclient@webmail.dnswatch.com> <4A2B0C19-799B-4C09-A887-8FDC6AE0B019@tinker.com> <581b3767ad793d5bce046a42f6516798.dnswclient@webmail.dnswatch.com> Message-ID: On Jan 18, 2009, at 4:28 PM, fbsdmail@dnswatch.com wrote: > Greetings Kim, and thank you very much for such a concise overview... > ... snip ... > > I find I'm only left with one question; > If my box is assigned an internet routable IP (not a private IP), > which address should take precedence? In other words, knowing that > IPFW works "top down", or "first match". How would/should I add my > internet routable IP (assuming I should). Or should I simply replace > 127.0.0.1 with my internet routable IP as shown in your example? > > I see you have posted another reply. I'll see if you've already > addressed my question in that reply. :) > > Thank you again for taking the time to be so helpful. > > Best wishes. > > --Chris > You don't need to do anything for your routable IP address. Packets going to and coming from that IP will be matched by rule 65000 and go on through the filter. Also, you don't want to change rules 100 through 300 regardless of the IP address of your interface. I don't know what you are doing with your machine but you can look at the rules inserted by the WORKSTATION or SIMPLE firewall configurations to see how to do more sophisticated filtering. I also recommend the book, "Building Internet Firewalls" by Chapman and Zwicky to learn more about packet filtering. Kim -- Kim Shrier - principal, Shrier and Deihl - mailto:kim@tinker.com Remote Unix Network Admin, Security, Internet Software Development Tinker Internet Services - Superior FreeBSD-based Web Hosting http://www.tinker.com/ From bugmaster at FreeBSD.org Mon Jan 19 03:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 19 03:08:08 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200901191106.n0JB6xUj062992@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 bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 52 problems total. From arkadietz at yahoo.com Tue Jan 20 08:07:25 2009 From: arkadietz at yahoo.com (Kiril Georgiev) Date: Tue Jan 20 09:18:08 2009 Subject: Question :) Message-ID: <252793.48085.qm@web51910.mail.re2.yahoo.com> Hello! I want to ask you have equivalent commands in FreeBSD and if what they are. Commands that are talking ip rou, ip roule.Also want to know if FreeBSD is doing better than Linux Kernel 2.6.8 in the role of Bridge, Router, VPN and quality of some PPOE hub. Interested if FreeBSD is doing better than Linux. And say how pps / mbit / gigabyte packages may adopt or failure for a second. The idea is this to say that I have internet service provider and have a link from 500mb / s if FreeBSD will cope better with this. Example of one of the things that are referred to ask below.If you can do some tests and comparisons will be very grateful.This is very important to me and is of great importance. Example: ip rou add 192.168.0.0/24 via 10.0.0.1 table fake ip rule add from 192.168.0.0/24 table fake ip rule add from 192.168.0.0/24 table fake pref 12000 These examples say what will appear to IPFW. If you can do something. --- When you dream there are no rules, people can fly, anything can happen. Sometimes there is a moment as you are awakening when you become aware of the real world around you, but you are still dreaming. You may think you can fly but you do better not try. People can fly. Arkadietz cOrp. ? 2000-2008, Inc. From bugmaster at FreeBSD.org Mon Jan 26 03:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 26 03:08:08 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200901261106.n0QB6vxE024287@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 bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 52 problems total. From kagekonjou at gmail.com Tue Jan 27 16:30:05 2009 From: kagekonjou at gmail.com (Kage) Date: Tue Jan 27 16:30:12 2009 Subject: Multi-IP Jails using IPFW (7.1-REL) Message-ID: Hey, I need a solution for using IPFW to forward multiple IPs (any port) to a single jail. Basically, here's what I'd like: JID IP Address Hostname Path 1 10.0.0.100 some.host.name /usr/jails/jail-1 1.2.3.4 -> IPFW -> jail-1 (10.0.0.100) 1.2.3.5 -> IPFW -> jail-1 (10.0.0.100) 1.2.3.6 -> IPFW -> jail-1 (10.0.0.100) The jails need to be able to connect to the outside world via one of the IPs that are forwarded to it (doesn't matter which it defaults to). It CANNOT connect out via the base IP set in ifconfig, only one of the aliases, specifically one of the ones pointing to the jail via ipfw. Ideally, I'd like to do this in ipfw since I've barely worked with pf, and I've got tons of rules already setup in ipfw. According to a bunch of people around, a solution like can be done with ipfw (and apparently has been done by a few), but no one will tell me how. Can someone please tell me what rule(s) I need to add to my ipfw settings? Thanks! -- ~ Kage http://vitund.com http://hackthissite.org