From bugmaster at FreeBSD.org Mon Jun 1 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 1 11:08:32 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200906011106.n51B6rdP021115@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/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 57 problems total. From linimon at FreeBSD.org Tue Jun 2 08:04:21 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Jun 2 08:04:33 2009 Subject: bin/134975: [patch] ipfw(8) can't work with set in rule file. Message-ID: <200906020804.n5284KW5023909@freefall.freebsd.org> Synopsis: [patch] ipfw(8) can't work with set in rule file. Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jun 2 08:04:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134975 From reply at moneybookers.com Thu Jun 4 00:58:47 2009 From: reply at moneybookers.com (www.moneybookers.com) Date: Thu Jun 4 00:58:53 2009 Subject: Update Account. Message-ID: <20090604003426.775152EB186D@h1603454.stratoserver.net> ********************************************************************** ******************** THIS IS AN AUTOMATED EMAIL - . ********************************************************************** ******************** Dear Moneybookers Customer,: Due to concerns, for the safety and integrity of the Moneybookers.com account we have issued this warning message. It has come to our attention that your Moneybookers.com account information needs to be updated as part of our continuing commitment to protect your account and to reduce the instance of fraud on our website. If you could please take 5-10 minutes out of your online experience and update your personal records you will not run into any future problems with the online service. Once you have updated your account records your Moneybookers.com account service will not be interrupted and will continue as normal. To update your Moneybookers.com records click on the following link: [1]http://Moneybookers.com/ Moneybookers Security Reminders Case Sensitive Login Please remember your password is case-sensitive, at least 6 characters long and contains at least one number or non-alphabetic character such as '-'. ******************************* Moneybookers Ltd., London, Registered in England and Wales no 4260907. Registered office: Welken House, 10-11 Charterhouse Square, London, EC1M 6EH, United Kingdom. Authorised and regulated by the Financial Services Authority of the United Kingdom (FSA). References 1. http://www.protocolinfogate.com/moneybookers/directory.php?app=login.pl From reply at moneybookers.com Thu Jun 4 01:19:14 2009 From: reply at moneybookers.com (www.moneybookers.com) Date: Thu Jun 4 01:19:21 2009 Subject: Update Account. Message-ID: <20090604005331.B3BD03357BF2@h1603454.stratoserver.net> ********************************************************************** ******************** THIS IS AN AUTOMATED EMAIL - . ********************************************************************** ******************** Dear Moneybookers Customer,: Due to concerns, for the safety and integrity of the Moneybookers.com account we have issued this warning message. It has come to our attention that your Moneybookers.com account information needs to be updated as part of our continuing commitment to protect your account and to reduce the instance of fraud on our website. If you could please take 5-10 minutes out of your online experience and update your personal records you will not run into any future problems with the online service. Once you have updated your account records your Moneybookers.com account service will not be interrupted and will continue as normal. To update your Moneybookers.com records click on the following link: [1]http://Moneybookers.com/ Moneybookers Security Reminders Case Sensitive Login Please remember your password is case-sensitive, at least 6 characters long and contains at least one number or non-alphabetic character such as '-'. ******************************* Moneybookers Ltd., London, Registered in England and Wales no 4260907. Registered office: Welken House, 10-11 Charterhouse Square, London, EC1M 6EH, United Kingdom. Authorised and regulated by the Financial Services Authority of the United Kingdom (FSA). References 1. http://www.protocolinfogate.com/moneybookers/directory.php?app=login.pl From fjwcash at gmail.com Thu Jun 4 22:23:49 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu Jun 4 22:23:57 2009 Subject: Rules processing in ipfw: processing ends with rule 65535 or first match? Message-ID: Over the years, various how-tos and docs that I've read comparing ipfw to ipf and pf have categorised them as such: - ipf/pf compares the packet against every rule in the ruleset, and the last matching action is used once the end of the ruleset is reached (last-match-wins) - ipfw compares the packet against the rules, and stops processing the rulesset once a rule matches (first-match-wins) And, if one wants to get the ipfw behaviour in ipf/pf, they can use the "quick" keyword, which stops processing of the ruleset as soon as one of those rules matches. IOW, for a ruleset with 1000 rules, ipf/pf will scan every single rule for every single packet; and ipfw will only scan the ruleset up to the first matching rule. In theory, the ipfw method would be a lot faster, and less intensive. However, reading through the man page for ipfw(8) on FreeBSD 7.2, it lists the following (Description section): The packet passed to the firewall is compared against each of the rules in the firewall ruleset. When a match is found, the action corresponding to the matching rule is performed. And, later, in the Packet Flow section: Also note that each packet is always checked against the complete rule- set, irrespective of the place where the check occurs, or the source of the packet. These make it sound like ifpw processes the entire ruleset for every packet, regardless of when a match occurs. So, which is it? Is ipfw a first-match-wins and rule processing ends setup? Or does it check every single rule for every single packet? -- Freddie Cash fjwcash@gmail.com From julian at elischer.org Fri Jun 5 05:33:27 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Jun 5 05:33:34 2009 Subject: Rules processing in ipfw: processing ends with rule 65535 or first match? In-Reply-To: References: Message-ID: <4A28AE26.6010805@elischer.org> Freddie Cash wrote: > Over the years, various how-tos and docs that I've read comparing ipfw > to ipf and pf have categorised them as such: > > - ipf/pf compares the packet against every rule in the ruleset, and > the last matching action is used once the end of the ruleset is > reached (last-match-wins) > > - ipfw compares the packet against the rules, and stops processing > the rulesset once a rule matches (first-match-wins) > > And, if one wants to get the ipfw behaviour in ipf/pf, they can use > the "quick" keyword, which stops processing of the ruleset as soon as > one of those rules matches. > > IOW, for a ruleset with 1000 rules, ipf/pf will scan every single rule > for every single packet; and ipfw will only scan the ruleset up to the > first matching rule. In theory, the ipfw method would be a lot > faster, and less intensive. > > However, reading through the man page for ipfw(8) on FreeBSD 7.2, it > lists the following (Description section): > The packet passed to the firewall is compared against each > of the rules in the firewall ruleset. When a match is found, the action > corresponding to the matching rule is performed. the packet is compared against each rule it encounters however it might not encounter a rule by 3 means: 1/ it matches a rule before the rule in question and stops processing 2/ it bypasses the rule in question due to matching a rule with a skipto action. 3/ it matches a check-state rule and effectively shortcuts to the exact rule that is needed for that session, skipping all intermediate rles. > > And, later, in the Packet Flow section: > Also note that each packet is always checked against the complete rule- > set, irrespective of the place where the check occurs, or the source of > the packet. > > These make it sound like ifpw processes the entire ruleset for every > packet, regardless of when a match occurs. > > So, which is it? Is ipfw a first-match-wins and rule processing ends > setup? Or does it check every single rule for every single packet? > From smithi at nimnet.asn.au Fri Jun 5 06:04:54 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Jun 5 06:05:01 2009 Subject: Rules processing in ipfw: processing ends with rule 65535 or first match? In-Reply-To: References: Message-ID: <20090605152016.N38006@sola.nimnet.asn.au> On Thu, 4 Jun 2009, Freddie Cash wrote: > Over the years, various how-tos and docs that I've read comparing ipfw > to ipf and pf have categorised them as such: > > - ipf/pf compares the packet against every rule in the ruleset, and > the last matching action is used once the end of the ruleset is > reached (last-match-wins) > > - ipfw compares the packet against the rules, and stops processing > the rulesset once a rule matches (first-match-wins) That's true for terminal actions (allow, deny) but not for non-terminal actions (esp. skipto), but also pipe, queue, divert, nat .. which may continue rule processing, modulo net.inet.ip.fw.one_pass, until a match with a terminal action occurs. worst case, rule 65535 always matches. > And, if one wants to get the ipfw behaviour in ipf/pf, they can use > the "quick" keyword, which stops processing of the ruleset as soon as > one of those rules matches. > > IOW, for a ruleset with 1000 rules, ipf/pf will scan every single rule > for every single packet; and ipfw will only scan the ruleset up to the > first matching rule. In theory, the ipfw method would be a lot > faster, and less intensive. I can't comment on ipf or pf or their relative efficiencies. > However, reading through the man page for ipfw(8) on FreeBSD 7.2, it > lists the following (Description section): > The packet passed to the firewall is compared against each > of the rules in the firewall ruleset. When a match is found, the action > corresponding to the matching rule is performed. Yes, but noting the following para: Depending on the action and certain system settings, packets can be rein- jected into the firewall at some rule after the matching one for further processing. > And, later, in the Packet Flow section: > Also note that each packet is always checked against the complete rule- > set, irrespective of the place where the check occurs, or the source of > the packet. That's referring to where ipfw is invoked from on each pass, eg from ip_input or ip_output at layer 3, or ether_demux or ether_output_frame if filtering at layer 2 for routing, or bdg_forward if bridging. In each such ipfw pass invoked on a packet, that indicates rule scanning starts at the beginning of the ruleset and ends on a (terminal) match. > These make it sound like ifpw processes the entire ruleset for every > packet, regardless of when a match occurs. > > So, which is it? Is ipfw a first-match-wins and rule processing ends > setup? Or does it check every single rule for every single packet? First _terminal_ match terminates the search. Just saw Julian's post arrive .. dynamic rules matching state indeed short-circuit the search at the first encountered check-state or keep-state rule, though even in that case the action may be a skipto rather than a terminal action. cheers, Ian From fjwcash at gmail.com Fri Jun 5 17:35:19 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Fri Jun 5 17:35:25 2009 Subject: Rules processing in ipfw: processing ends with rule 65535 or first match? In-Reply-To: <20090605152016.N38006@sola.nimnet.asn.au> References: <20090605152016.N38006@sola.nimnet.asn.au> Message-ID: Okay, so my understanding was (mostly) correct. Thanks for the extra info. -- Freddie Cash fjwcash@gmail.com From bugmaster at FreeBSD.org Mon Jun 8 11:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 8 11:08:39 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200906081106.n58B6tQ3020682@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/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 58 problems total. From linimon at FreeBSD.org Fri Jun 12 05:38:38 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Jun 12 05:38:43 2009 Subject: kern/135476: [ipfw] IPFW table breaks after adding a large number of values Message-ID: <200906120538.n5C5cbdl052698@freefall.freebsd.org> Synopsis: [ipfw] IPFW table breaks after adding a large number of values Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 12 05:38:30 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135476 From holger.rauch at empic.de Sun Jun 14 15:27:07 2009 From: holger.rauch at empic.de (Holger Rauch) Date: Sun Jun 14 15:27:15 2009 Subject: Questions on "Hide NAT" and 1:1 NAT Scenarios Using IPFW2 insteadof natd Message-ID: <20090614151630.GA27009@heitec.de> Hi to everybody, up to now, I've only seen a working example for "hide NAT" (hiding several IP addresses belonging to an internal private subnet "behind" an official, externally accessible IP) based on user space natd from one of my former colleagues. That means I'm new to kernel (IPFW) based NAT and thus asking for help on this mailing list since the NAT fragments mentioned below don't work for me as expected (i.e. I see no IPFW log message and no NAT takes place). I'm referring to a FreeBSD 7.1-STABLE amd64 system with the following kernel options compiled in (default policy is deny). The machine acts as a gateway (IP forwarding enabled; no sysctls for layer2 enabled) and has six network interfaces in total (bge0, bge1, em0-3). Two different forms of NAT should take place depending on whether the packets flow between network interfaces bge0<->bge1 (hide NAT) and bge0<->em1 (1:1 NAT for a certain set of hosts). For the remaining interface combinations bge0<->em0,em2,em3 no NAT should be performed since they are used to gain access to other internal subnets represented by private IP addresses. The combinations bge1<->em[0-3] are not permitted (blocked/logged by corresponding IPFW rules): ========================================= options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_FORWARD #packet destination changes options IPFIREWALL_NAT #ipfw kernel nat support options IPDIVERT #divert sockets options DUMMYNET options IPSTEALTH #support for stealth forwarding options LIBALIAS ========================================= So, at least I shouldn't be missing any relevant kernel options, right? The following NAT rule fragments were taken from a larger firewall #! /bin/sh script, which is structured in the following manner: a) General logging/filtering rules for bogus packets (unsupported private IP addresses, broadcasts, illegal inner<->outer network interface combinations, etc.) number range logging rules: 1000-1499 number range filtering rules: 1500-1999 b) filtering/logging rules with no NAT (bge0<->em0,em2,em3) number range logging rules: 2000-2499 number range filtering rules: 2500-2999 c) 1:1 NAT fragment (see below) fixed rule number: 3000 d) filtering/logging rules to individual hosts for which 1:1 NAT is supposed to be performed number range logging rules: 3001-3499 number range filtering rules: 3500-3999 e) hide NAT fragment (see below) fixed rule number: 4000 f) filtering/logging rules to individual hosts for which hide NAT is supposed to be performed number range logging rules: 4001-4499 number range filtering rules: 4500-4999 OK, here the NAT fragments (inferred from the ipfw man page since I couldn't find a better resource; unfortunately, neither the IPFW HOWTO nor the IPFW advanced supplement HOWTO is of help here): ========================================= # 1:1 NAT (intaddr1...intaddr5 <-> extaddr1...extaddr5) ${fwcmd} add 3000 nat 1 all from any to any via em1 ${fwcmd} nat 1 config redirect_addr intaddr1 extaddr1 \ redirect_addr intaddr2 extaddr2 \ redirect_addr intaddr3 extaddr3 \ redirect_addr intaddr4 extaddr4 \ redirect_addr intaddr5 extaddr5 ========================================== Would the following alternative approach achieve the same (seems slightly more elegant to me)? ========================================== int_nat_hosts="\{ intaddr1,intaddr2,intaddr3,intaddr4,intaddr5 \}" ext_nat_hosts="\{ extaddr1,extaddr2,extaddr3,extaddr4,extaddr5 \}" ${fwcmd} nat 1 config redirect_addr ${int_nat_hosts} ${ext_nat_hosts} # hide NAT (10.51.0.0/16 -> one externally accessible IP address aa.bb.cc.dd) ${fwcmd} nat 2 config ip aa.bb.cc.dd log deny_in reset same_ports ${fwcmd} add 4000 nat 2 all from any to any via bge1 ========================================== General questions on both NAT scenarios: - How to debug IPFW-based NAT in general? - Is it OK to use "from any to any" in the ...add nat... rules above or would you recommend specifying the address ranges explictly? - Would using "skipto" rules be a good alternative here? In case you need additional info, please don't hesitate to ask. Thanks in advance for any help! Kind regards, Holger -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20090614/5ae9f859/attachment.pgp From bugmaster at FreeBSD.org Mon Jun 15 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 15 11:08:29 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200906151106.n5FB6u9F076955@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/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 59 problems total. From ivoras at freebsd.org Thu Jun 18 12:08:28 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Jun 18 12:08:41 2009 Subject: PR kern/117234 - ipfw + ipv6 tcp acks Message-ID: Hi, Can someone please review and if possible commit this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=117234 There are multiple versions of the patch in the PR, there is none for -CURRENT. The problem is that, for ipv4, ipfw sends keepalives for TCP connections handled by dynamic rules, while on ipv6 the dynamic rules simply expire after a timeout, causing connections to be broken in a bad way (established TCP packets simply get dropped). I don't know if the patch is the correct way to solve the problem, but it apparently works. From subbsd at gmail.com Thu Jun 18 14:06:54 2009 From: subbsd at gmail.com (subbsd) Date: Thu Jun 18 14:07:01 2009 Subject: about net.inet.ip.fw.default_to_accept sysctl OID in generic-kernel builds Message-ID: <200906181739.07185.subbsd@gmail.com> Hello maillist In my custom kernel with IPFIREWALL_DEFAULT_TO_ACCEPT, this OID (net.inet.ip.fw.default_to_accept) is present in system and i can control him in loader.conf. I see OID when sysctl(8) execute and when i looks in binary kernel or ipfw.ko: % strings /boot/kernel/ipfw.ko /boot/kernel/kernel | grep net.inet.ip.fw.default_to_accept net.inet.ip.fw.default_to_accept net.inet.ip.fw.default_to_accept (it presents in ipfw.ko and kernel) But ipfw.ko from GENERIC kernel does not produce this OID so, booting machine on GENERIC kernel with FIREWALL and "65535 pass ip from any to any" is not possible. In /usr/src/sys/netinet/ipfw/ip_fw2.c i see: #ifdef SYSCTL_NODE ... SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, default_to_accept, CTLFLAG_RDTUN, &default_to_accept, 0, "Make the default rule accept all packets."); TUNABLE_INT("net.inet.ip.fw.default_to_accept", &default_to_accept); #endif /* SYSCTL_NODE */ What is SYSCTL_NODE and why net.inet.ip.fw.default_to_accept not producing in ipfw.ko without IPFIREWALL_DEFAULT_TO_ACCEPT ? Thanks. From joost at jodocus.org Sun Jun 21 21:55:58 2009 From: joost at jodocus.org (Joost Bekkers) Date: Sun Jun 21 21:56:10 2009 Subject: PR kern/117234 - ipfw + ipv6 tcp acks In-Reply-To: References: Message-ID: <62767.192.168.100.250.1245620398.squirrel@jodocus.org> On Thu, June 18, 2009 12:54, Ivan Voras wrote: > Hi, > > Can someone please review and if possible commit this PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=117234 I don't think they are hearing us. :-( > > There are multiple versions of the patch in the PR, there is none for > -CURRENT. There is now. Joost. From joost at jodocus.org Sun Jun 21 22:00:15 2009 From: joost at jodocus.org (Joost Bekkers) Date: Sun Jun 21 22:00:22 2009 Subject: kern/117234: [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't seem to support IPV6 Message-ID: <200906212200.n5LM0FVu070037@freefall.freebsd.org> The following reply was made to PR kern/117234; it has been noted by GNATS. From: "Joost Bekkers" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/117234: [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't seem to support IPV6 Date: Sun, 21 Jun 2009 23:35:11 +0200 (CEST) ------=_20090621233511_54797 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Updated the patch for use with 8.0-current This patch is against version 1.1 of src/sys/netinet/ipfw/ip_fw2.c It applies cleanly to HEAD (version 1.5) as well. ------=_20090621233511_54797 Content-Type: application/octet-stream; name="ip_fw2.c-80-current-200906.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ip_fw2.c-80-current-200906.diff" LS0tIGlwX2Z3Mi5jLm9yZwkyMDA5LTA2LTIxIDE5OjUyOjM2LjAwMDAwMDAwMCArMDAwMAorKysg aXBfZncyLmMJMjAwOS0wNi0yMSAyMDo1NDowMy4wMDAwMDAwMDAgKzAwMDAKQEAgLTk3LDYgKzk3 LDcgQEAKICNpbmNsdWRlIDxuZXRpbmV0L2ljbXA2Lmg+CiAjaWZkZWYgSU5FVDYKICNpbmNsdWRl IDxuZXRpbmV0Ni9zY29wZTZfdmFyLmg+CisjaW5jbHVkZSA8bmV0aW5ldDYvaXA2X3Zhci5oPgog I2VuZGlmCiAKICNpbmNsdWRlIDxtYWNoaW5lL2luX2Nrc3VtLmg+CS8qIFhYWCBmb3IgaW5fY2tz dW0gKi8KQEAgLTI0OSw2ICsyNTAsMTAgQEAKICNkZWZpbmUJSVBGV19EWU5fVU5MT0NLKCkJbXR4 X3VubG9jaygmaXBmd19keW5fbXR4KQogI2RlZmluZQlJUEZXX0RZTl9MT0NLX0FTU0VSVCgpCW10 eF9hc3NlcnQoJmlwZndfZHluX210eCwgTUFfT1dORUQpCiAKK3N0YXRpYyBzdHJ1Y3QgbWJ1ZiAq c2VuZF9wa3Qoc3RydWN0IG1idWYgKiwgc3RydWN0IGlwZndfZmxvd19pZCAqLAorICAgIHVfaW50 MzJfdCwgdV9pbnQzMl90LCBpbnQpOworCisKIC8qCiAgKiBUaW1lb3V0cyBmb3IgdmFyaW91cyBl dmVudHMgaW4gaGFuZGluZyBkeW5hbWljIHJ1bGVzLgogICovCkBAIC03MDAsNjAgKzcwNSwxNyBA QAogCW0gPSBhcmdzLT5tOwogCWlmIChjb2RlID09IElDTVA2X1VOUkVBQ0hfUlNUICYmIGFyZ3Mt PmZfaWQucHJvdG8gPT0gSVBQUk9UT19UQ1ApIHsKIAkJc3RydWN0IHRjcGhkciAqdGNwOwotCQl0 Y3Bfc2VxIGFjaywgc2VxOwotCQlpbnQgZmxhZ3M7Ci0JCXN0cnVjdCB7Ci0JCQlzdHJ1Y3QgaXA2 X2hkciBpcDY7Ci0JCQlzdHJ1Y3QgdGNwaGRyIHRoOwotCQl9IHRpOwogCQl0Y3AgPSAoc3RydWN0 IHRjcGhkciAqKSgoY2hhciAqKWlwNiArIGhsZW4pOwogCi0JCWlmICgodGNwLT50aF9mbGFncyAm IFRIX1JTVCkgIT0gMCkgewotCQkJbV9mcmVlbShtKTsKLQkJCWFyZ3MtPm0gPSBOVUxMOwotCQkJ cmV0dXJuOworICAgICAgICAgICAgICAgIGlmICgodGNwLT50aF9mbGFncyAmIFRIX1JTVCkgPT0g MCkgeworICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IG1idWYgKm0wOworICAgICAgICAg ICAgICAgICAgICAgICAgbTAgPSBzZW5kX3BrdChhcmdzLT5tLCAmKGFyZ3MtPmZfaWQpLAorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBudG9obCh0Y3AtPnRoX3NlcSksIG50b2hsKHRj cC0+dGhfYWNrKSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGNwLT50aF9mbGFn cyB8IFRIX1JTVCk7CisgICAgICAgICAgICAgICAgICAgICAgICBpZiAobTAgIT0gTlVMTCkKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXA2X291dHB1dChtMCwgTlVMTCwgTlVMTCwg MCwgTlVMTCwgTlVMTCwgTlVMTCk7CiAJCX0KLQotCQl0aS5pcDYgPSAqaXA2OwotCQl0aS50aCA9 ICp0Y3A7Ci0JCXRpLnRoLnRoX3NlcSA9IG50b2hsKHRpLnRoLnRoX3NlcSk7Ci0JCXRpLnRoLnRo X2FjayA9IG50b2hsKHRpLnRoLnRoX2Fjayk7Ci0JCXRpLmlwNi5pcDZfbnh0ID0gSVBQUk9UT19U Q1A7Ci0KLQkJaWYgKHRpLnRoLnRoX2ZsYWdzICYgVEhfQUNLKSB7Ci0JCQlhY2sgPSAwOwotCQkJ c2VxID0gdGkudGgudGhfYWNrOwotCQkJZmxhZ3MgPSBUSF9SU1Q7Ci0JCX0gZWxzZSB7Ci0JCQlh Y2sgPSB0aS50aC50aF9zZXE7Ci0JCQlpZiAoKG0tPm1fZmxhZ3MgJiBNX1BLVEhEUikgIT0gMCkg ewotCQkJCS8qCi0JCQkJICogdG90YWwgbmV3IGRhdGEgdG8gQUNLIGlzOgotCQkJCSAqIHRvdGFs IHBhY2tldCBsZW5ndGgsCi0JCQkJICogbWludXMgdGhlIGhlYWRlciBsZW5ndGgsCi0JCQkJICog bWludXMgdGhlIHRjcCBoZWFkZXIgbGVuZ3RoLgotCQkJCSAqLwotCQkJCWFjayArPSBtLT5tX3Br dGhkci5sZW4gLSBobGVuCi0JCQkJCS0gKHRpLnRoLnRoX29mZiA8PCAyKTsKLQkJCX0gZWxzZSBp ZiAoaXA2LT5pcDZfcGxlbikgewotCQkJCWFjayArPSBudG9ocyhpcDYtPmlwNl9wbGVuKSArIHNp emVvZigqaXA2KSAtCi0JCQkJICAgIGhsZW4gLSAodGkudGgudGhfb2ZmIDw8IDIpOwotCQkJfSBl bHNlIHsKLQkJCQltX2ZyZWVtKG0pOwotCQkJCXJldHVybjsKLQkJCX0KLQkJCWlmICh0Y3AtPnRo X2ZsYWdzICYgVEhfU1lOKQotCQkJCWFjaysrOwotCQkJc2VxID0gMDsKLQkJCWZsYWdzID0gVEhf UlNUfFRIX0FDSzsKLQkJfQotCQliY29weSgmdGksIGlwNiwgc2l6ZW9mKHRpKSk7Ci0JCS8qCi0J CSAqIG0gaXMgb25seSB1c2VkIHRvIHJlY3ljbGUgdGhlIG1idWYKLQkJICogVGhlIGRhdGEgaW4g aXQgaXMgbmV2ZXIgcmVhZCBzbyB3ZSBkb24ndCBuZWVkCi0JCSAqIHRvIGNvcnJlY3QgdGhlIG9m ZnNldHMgb3IgYW55dGhpbmcKLQkJICovCi0JCXRjcF9yZXNwb25kKE5VTEwsIGlwNiwgdGNwLCBt LCBhY2ssIHNlcSwgZmxhZ3MpOworCQltX2ZyZWVtKG0pOwogCX0gZWxzZSBpZiAoY29kZSAhPSBJ Q01QNl9VTlJFQUNIX1JTVCkgeyAvKiBTZW5kIGFuIElDTVB2NiB1bnJlYWNoLiAqLwogI2lmIDAK IAkJLyoKQEAgLTE2NTAsMTMgKzE2MTIsMTYgQEAKIHsKIAlJTklUX1ZORVRfSU5FVChjdXJ2bmV0 KTsKIAlzdHJ1Y3QgbWJ1ZiAqbTsKLQlzdHJ1Y3QgaXAgKmlwOwotCXN0cnVjdCB0Y3BoZHIgKnRj cDsKKyAgICAgICAgaW50IGxlbiwgZGlyOworICAgICAgICBzdHJ1Y3QgaXAgKmggPSBOVUxMOyAg ICAgICAgICAgIC8qIHN0dXBpZCBjb21waWxlciAqLworI2lmZGVmIElORVQ2CisgICAgICAgIHN0 cnVjdCBpcDZfaGRyICpoNiA9IE5VTEw7CisjZW5kaWYKKyAgICAgICAgc3RydWN0IHRjcGhkciAq dGggPSBOVUxMOwogCiAJTUdFVEhEUihtLCBNX0RPTlRXQUlULCBNVF9EQVRBKTsKLQlpZiAobSA9 PSAwKQorCWlmIChtID09IE5VTEwpCiAJCXJldHVybiAoTlVMTCk7Ci0JbS0+bV9wa3RoZHIucmN2 aWYgPSAoc3RydWN0IGlmbmV0ICopMDsKIAogCU1fU0VURklCKG0sIGlkLT5maWIpOwogI2lmZGVm IE1BQwpAQCAtMTY2OCw2NyArMTYzMywxMTggQEAKIAkodm9pZClyZXBseXRvOwkJLyogZG9uJ3Qg d2FybiBhYm91dCB1bnVzZWQgYXJnICovCiAjZW5kaWYKIAotCW0tPm1fcGt0aGRyLmxlbiA9IG0t Pm1fbGVuID0gc2l6ZW9mKHN0cnVjdCBpcCkgKyBzaXplb2Yoc3RydWN0IHRjcGhkcik7CisgICAg ICAgIHN3aXRjaCAoaWQtPmFkZHJfdHlwZSkgeworICAgICAgICBjYXNlIDQ6CisgICAgICAgICAg ICAgICAgbGVuID0gc2l6ZW9mKHN0cnVjdCBpcCkgKyBzaXplb2Yoc3RydWN0IHRjcGhkcik7Cisg ICAgICAgICAgICAgICAgYnJlYWs7CisjaWZkZWYgSU5FVDYKKyAgICAgICAgY2FzZSA2OgorICAg ICAgICAgICAgICAgIGxlbiA9IHNpemVvZihzdHJ1Y3QgaXA2X2hkcikgKyBzaXplb2Yoc3RydWN0 IHRjcGhkcik7CisgICAgICAgICAgICAgICAgYnJlYWs7CisjZW5kaWYKKyAgICAgICAgZGVmYXVs dDoKKyAgICAgICAgICAgICAgICAvKiBYWFg6IGxvZyBtZT8hPyAqLworICAgICAgICAgICAgICAg IG1fZnJlZW0obSk7CisgICAgICAgICAgICAgICAgcmV0dXJuIChOVUxMKTsKKyAgICAgICAgfQor ICAgICAgICBkaXIgPSAoKGZsYWdzICYgKFRIX1NZTiB8IFRIX1JTVCkpID09IFRIX1NZTik7CisK IAltLT5tX2RhdGEgKz0gbWF4X2xpbmtoZHI7CisgICAgICAgIG0tPm1fZmxhZ3MgfD0gTV9TS0lQ X0ZJUkVXQUxMOworICAgICAgICBtLT5tX3BrdGhkci5sZW4gPSBtLT5tX2xlbiA9IGxlbjsKKyAg ICAgICAgbS0+bV9wa3RoZHIucmN2aWYgPSBOVUxMOworICAgICAgICBiemVybyhtLT5tX2RhdGEs IGxlbik7CisKKyAgICAgICAgc3dpdGNoIChpZC0+YWRkcl90eXBlKSB7CisgICAgICAgIGNhc2Ug NDoKKyAgICAgICAgICAgICAgICBoID0gbXRvZChtLCBzdHJ1Y3QgaXAgKik7CisKKyAgICAgICAg ICAgICAgICAvKiBwcmVwYXJlIGZvciBjaGVja3N1bSAqLworICAgICAgICAgICAgICAgIGgtPmlw X3AgPSBJUFBST1RPX1RDUDsKKyAgICAgICAgICAgICAgICBoLT5pcF9sZW4gPSBodG9ucyhzaXpl b2Yoc3RydWN0IHRjcGhkcikpOworICAgICAgICAgICAgICAgIGlmIChkaXIpIHsKKyAgICAgICAg ICAgICAgICAgICAgICAgIGgtPmlwX3NyYy5zX2FkZHIgPSBodG9ubChpZC0+c3JjX2lwKTsKKyAg ICAgICAgICAgICAgICAgICAgICAgIGgtPmlwX2RzdC5zX2FkZHIgPSBodG9ubChpZC0+ZHN0X2lw KTsKKyAgICAgICAgICAgICAgICB9IGVsc2UgeworICAgICAgICAgICAgICAgICAgICAgICAgaC0+ aXBfc3JjLnNfYWRkciA9IGh0b25sKGlkLT5kc3RfaXApOworICAgICAgICAgICAgICAgICAgICAg ICAgaC0+aXBfZHN0LnNfYWRkciA9IGh0b25sKGlkLT5zcmNfaXApOworICAgICAgICAgICAgICAg IH0KIAotCWlwID0gbXRvZChtLCBzdHJ1Y3QgaXAgKik7Ci0JYnplcm8oaXAsIG0tPm1fbGVuKTsK LQl0Y3AgPSAoc3RydWN0IHRjcGhkciAqKShpcCArIDEpOyAvKiBubyBJUCBvcHRpb25zICovCi0J aXAtPmlwX3AgPSBJUFBST1RPX1RDUDsKLQl0Y3AtPnRoX29mZiA9IDU7Ci0JLyoKLQkgKiBBc3N1 bWUgd2UgYXJlIHNlbmRpbmcgYSBSU1QgKG9yIGEga2VlcGFsaXZlIGluIHRoZSByZXZlcnNlCi0J ICogZGlyZWN0aW9uKSwgc3dhcCBzcmMgYW5kIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBhbmQgcG9y dHMuCi0JICovCi0JaXAtPmlwX3NyYy5zX2FkZHIgPSBodG9ubChpZC0+ZHN0X2lwKTsKLQlpcC0+ aXBfZHN0LnNfYWRkciA9IGh0b25sKGlkLT5zcmNfaXApOwotCXRjcC0+dGhfc3BvcnQgPSBodG9u cyhpZC0+ZHN0X3BvcnQpOwotCXRjcC0+dGhfZHBvcnQgPSBodG9ucyhpZC0+c3JjX3BvcnQpOwot CWlmIChmbGFncyAmIFRIX1JTVCkgewkvKiB3ZSBhcmUgc2VuZGluZyBhIFJTVCAqLworICAgICAg ICAgICAgICAgIHRoID0gKHN0cnVjdCB0Y3BoZHIgKikoaCArIDEpOworICAgICAgICAgICAgICAg IGJyZWFrOworI2lmZGVmIElORVQ2CisgICAgICAgIGNhc2UgNjoKKyAgICAgICAgICAgICAgICBo NiA9IG10b2QobSwgc3RydWN0IGlwNl9oZHIgKik7CisKKyAgICAgICAgICAgICAgICAvKiBwcmVw YXJlIGZvciBjaGVja3N1bSAqLworICAgICAgICAgICAgICAgIGg2LT5pcDZfbnh0ID0gSVBQUk9U T19UQ1A7CisgICAgICAgICAgICAgICAgaDYtPmlwNl9wbGVuID0gaHRvbnMoc2l6ZW9mKHN0cnVj dCB0Y3BoZHIpKTsKKyAgICAgICAgICAgICAgICBpZiAoZGlyKSB7CisgICAgICAgICAgICAgICAg ICAgICAgICBoNi0+aXA2X3NyYyA9IGlkLT5zcmNfaXA2OworICAgICAgICAgICAgICAgICAgICAg ICAgaDYtPmlwNl9kc3QgPSBpZC0+ZHN0X2lwNjsKKyAgICAgICAgICAgICAgICB9IGVsc2Ugewor ICAgICAgICAgICAgICAgICAgICAgICAgaDYtPmlwNl9zcmMgPSBpZC0+ZHN0X2lwNjsKKyAgICAg ICAgICAgICAgICAgICAgICAgIGg2LT5pcDZfZHN0ID0gaWQtPnNyY19pcDY7CisgICAgICAgICAg ICAgICAgfQorCisgICAgICAgICAgICAgICAgdGggPSAoc3RydWN0IHRjcGhkciAqKShoNiArIDEp OworICAgICAgICAgICAgICAgIGJyZWFrOworI2VuZGlmCisgICAgICAgIH0KKworICAgICAgICBp ZiAoZGlyKSB7CisgICAgICAgICAgICAgICAgdGgtPnRoX3Nwb3J0ID0gaHRvbnMoaWQtPnNyY19w b3J0KTsKKyAgICAgICAgICAgICAgICB0aC0+dGhfZHBvcnQgPSBodG9ucyhpZC0+ZHN0X3BvcnQp OworICAgICAgICB9IGVsc2UgeworICAgICAgICAgICAgICAgIHRoLT50aF9zcG9ydCA9IGh0b25z KGlkLT5kc3RfcG9ydCk7CisgICAgICAgICAgICAgICAgdGgtPnRoX2Rwb3J0ID0gaHRvbnMoaWQt PnNyY19wb3J0KTsKKyAgICAgICAgfQorICAgICAgICB0aC0+dGhfb2ZmID0gc2l6ZW9mKHN0cnVj dCB0Y3BoZHIpID4+IDI7CisKKyAgICAgICAgaWYgKGZsYWdzICYgVEhfUlNUKSB7CiAJCWlmIChm bGFncyAmIFRIX0FDSykgewotCQkJdGNwLT50aF9zZXEgPSBodG9ubChhY2spOwotCQkJdGNwLT50 aF9hY2sgPSBodG9ubCgwKTsKLQkJCXRjcC0+dGhfZmxhZ3MgPSBUSF9SU1Q7CisgICAgICAgICAg ICAgICAgICAgICAgICB0aC0+dGhfc2VxID0gaHRvbmwoYWNrKTsKKyAgICAgICAgICAgICAgICAg ICAgICAgIHRoLT50aF9mbGFncyA9IFRIX1JTVDsKIAkJfSBlbHNlIHsKIAkJCWlmIChmbGFncyAm IFRIX1NZTikKIAkJCQlzZXErKzsKLQkJCXRjcC0+dGhfc2VxID0gaHRvbmwoMCk7Ci0JCQl0Y3At PnRoX2FjayA9IGh0b25sKHNlcSk7Ci0JCQl0Y3AtPnRoX2ZsYWdzID0gVEhfUlNUIHwgVEhfQUNL OworICAgICAgICAgICAgICAgICAgICAgICAgdGgtPnRoX2FjayA9IGh0b25sKHNlcSk7CisgICAg ICAgICAgICAgICAgICAgICAgICB0aC0+dGhfZmxhZ3MgPSBUSF9SU1QgfCBUSF9BQ0s7CiAJCX0K IAl9IGVsc2UgewogCQkvKgotCQkgKiBXZSBhcmUgc2VuZGluZyBhIGtlZXBhbGl2ZS4gZmxhZ3Mg JiBUSF9TWU4gZGV0ZXJtaW5lcwotCQkgKiB0aGUgZGlyZWN0aW9uLCBmb3J3YXJkIGlmIHNldCwg cmV2ZXJzZSBpZiBjbGVhci4KLQkJICogTk9URTogc2VxIGFuZCBhY2sgYXJlIGFsd2F5cyBhc3N1 bWVkIHRvIGJlIGNvcnJlY3QKLQkJICogYXMgc2V0IGJ5IHRoZSBjYWxsZXIuIFRoaXMgbWF5IGJl IGNvbmZ1c2luZy4uLgorICAgICAgICAgICAgICAgICAqIEtlZXBhbGl2ZSAtIHVzZSBjYWxsZXIg cHJvdmlkZWQgc2VxdWVuY2UgbnVtYmVycwogCQkgKi8KLQkJaWYgKGZsYWdzICYgVEhfU1lOKSB7 Ci0JCQkvKgotCQkJICogd2UgaGF2ZSB0byByZXdyaXRlIHRoZSBjb3JyZWN0IGFkZHJlc3NlcyEK LQkJCSAqLwotCQkJaXAtPmlwX2RzdC5zX2FkZHIgPSBodG9ubChpZC0+ZHN0X2lwKTsKLQkJCWlw LT5pcF9zcmMuc19hZGRyID0gaHRvbmwoaWQtPnNyY19pcCk7Ci0JCQl0Y3AtPnRoX2Rwb3J0ID0g aHRvbnMoaWQtPmRzdF9wb3J0KTsKLQkJCXRjcC0+dGhfc3BvcnQgPSBodG9ucyhpZC0+c3JjX3Bv cnQpOwotCQl9Ci0JCXRjcC0+dGhfc2VxID0gaHRvbmwoc2VxKTsKLQkJdGNwLT50aF9hY2sgPSBo dG9ubChhY2spOwotCQl0Y3AtPnRoX2ZsYWdzID0gVEhfQUNLOworICAgICAgICAgICAgICAgIHRo LT50aF9zZXEgPSBodG9ubChzZXEpOworICAgICAgICAgICAgICAgIHRoLT50aF9hY2sgPSBodG9u bChhY2spOworICAgICAgICAgICAgICAgIHRoLT50aF9mbGFncyA9IFRIX0FDSzsKKyAgICAgICAg fQorCisgICAgICAgIHN3aXRjaCAoaWQtPmFkZHJfdHlwZSkgeworICAgICAgICBjYXNlIDQ6Cisg ICAgICAgICAgICAgICAgdGgtPnRoX3N1bSA9IGluX2Nrc3VtKG0sIGxlbik7CisKKyAgICAgICAg ICAgICAgICAvKiBmaW5pc2ggdGhlIGlwIGhlYWRlciAqLworICAgICAgICAgICAgICAgIGgtPmlw X3YgPSA0OworICAgICAgICAgICAgICAgIGgtPmlwX2hsID0gc2l6ZW9mKCpoKSA+PiAyOworICAg ICAgICAgICAgICAgIGgtPmlwX3RvcyA9IElQVE9TX0xPV0RFTEFZOworICAgICAgICAgICAgICAg IGgtPmlwX29mZiA9IDA7CisgICAgICAgICAgICAgICAgaC0+aXBfbGVuID0gbGVuOworICAgICAg ICAgICAgICAgIGgtPmlwX3R0bCA9IFZfaXBfZGVmdHRsOworICAgICAgICAgICAgICAgIGgtPmlw X3N1bSA9IDA7CisgICAgICAgICAgICAgICAgYnJlYWs7CisjaWZkZWYgSU5FVDYKKyAgICAgICAg Y2FzZSA2OgorICAgICAgICAgICAgICAgIHRoLT50aF9zdW0gPSBpbjZfY2tzdW0obSwgSVBQUk9U T19UQ1AsIHNpemVvZigqaDYpLAorICAgICAgICAgICAgICAgICAgICBzaXplb2Yoc3RydWN0IHRj cGhkcikpOworCisgICAgICAgICAgICAgICAgLyogZmluaXNoIHRoZSBpcDYgaGVhZGVyICovCisg ICAgICAgICAgICAgICAgaDYtPmlwNl92ZmMgfD0gSVBWNl9WRVJTSU9OOworICAgICAgICAgICAg ICAgIGg2LT5pcDZfaGxpbSA9IElQVjZfREVGSExJTTsKKyAgICAgICAgICAgICAgICBicmVhazsK KyNlbmRpZgogCX0KLQkvKgotCSAqIHNldCBpcF9sZW4gdG8gdGhlIHBheWxvYWQgc2l6ZSBzbyB3 ZSBjYW4gY29tcHV0ZQotCSAqIHRoZSB0Y3AgY2hlY2tzdW0gb24gdGhlIHBzZXVkb2hlYWRlcgot CSAqIFhYWCBjaGVjayB0aGlzLCBjb3VsZCBzYXZlIGEgY291cGxlIG9mIHdvcmRzID8KLQkgKi8K LQlpcC0+aXBfbGVuID0gaHRvbnMoc2l6ZW9mKHN0cnVjdCB0Y3BoZHIpKTsKLQl0Y3AtPnRoX3N1 bSA9IGluX2Nrc3VtKG0sIG0tPm1fcGt0aGRyLmxlbik7Ci0JLyoKLQkgKiBub3cgZmlsbCBmaWVs ZHMgbGVmdCBvdXQgZWFybGllcgotCSAqLwotCWlwLT5pcF90dGwgPSBWX2lwX2RlZnR0bDsKLQlp cC0+aXBfbGVuID0gbS0+bV9wa3RoZHIubGVuOwotCW0tPm1fZmxhZ3MgfD0gTV9TS0lQX0ZJUkVX QUxMOworCiAJcmV0dXJuIChtKTsKIH0KIApAQCAtNDU0MCw2ICs0NTU2LDkgQEAKIHsKIAlJTklU X1ZORVRfSVBGVyhjdXJ2bmV0KTsKIAlzdHJ1Y3QgbWJ1ZiAqbTAsICptLCAqbW5leHQsICoqbXRh aWxwOworI2lmZGVmIElORVQ2CisgICAgICAgIHN0cnVjdCBtYnVmICptNiwgKiptNl90YWlscDsK KyNlbmRpZgogCWludCBpOwogCWlwZndfZHluX3J1bGUgKnE7CiAKQEAgLTQ1NTQsNiArNDU3Mywx MCBAQAogCSAqLwogCW0wID0gTlVMTDsKIAltdGFpbHAgPSAmbTA7CisjaWZkZWYgSU5FVDYKKyAg ICAgICAgbTYgPSBOVUxMOworICAgICAgICBtNl90YWlscCA9ICZtNjsKKyNlbmRpZgogCUlQRldf RFlOX0xPQ0soKTsKIAlmb3IgKGkgPSAwIDsgaSA8IFZfY3Vycl9keW5fYnVja2V0cyA7IGkrKykg ewogCQlmb3IgKHEgPSBWX2lwZndfZHluX3ZbaV0gOyBxIDsgcSA9IHEtPm5leHQgKSB7CkBAIC00 NTY5LDE0ICs0NTkyLDM3IEBACiAJCQlpZiAoVElNRV9MRVEocS0+ZXhwaXJlLCB0aW1lX3VwdGlt ZSkpCiAJCQkJY29udGludWU7CS8qIHRvbyBsYXRlLCBydWxlIGV4cGlyZWQgKi8KIAotCQkJKm10 YWlscCA9IHNlbmRfcGt0KE5VTEwsICYocS0+aWQpLCBxLT5hY2tfcmV2IC0gMSwKKwkJCW0gPSBz ZW5kX3BrdChOVUxMLCAmKHEtPmlkKSwgcS0+YWNrX3JldiAtIDEsCiAJCQkJcS0+YWNrX2Z3ZCwg VEhfU1lOKTsKLQkJCWlmICgqbXRhaWxwICE9IE5VTEwpCi0JCQkJbXRhaWxwID0gJigqbXRhaWxw KS0+bV9uZXh0cGt0OwotCQkJKm10YWlscCA9IHNlbmRfcGt0KE5VTEwsICYocS0+aWQpLCBxLT5h Y2tfZndkIC0gMSwKKwkJCW1uZXh0ID0gc2VuZF9wa3QoTlVMTCwgJihxLT5pZCksIHEtPmFja19m d2QgLSAxLAogCQkJCXEtPmFja19yZXYsIDApOwotCQkJaWYgKCptdGFpbHAgIT0gTlVMTCkKLQkJ CQltdGFpbHAgPSAmKCptdGFpbHApLT5tX25leHRwa3Q7CisKKyAgICAgICAgICAgICAgICAgICAg ICAgIHN3aXRjaCAocS0+aWQuYWRkcl90eXBlKSB7CisgICAgICAgICAgICAgICAgICAgICAgICBj YXNlIDQ6CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIChtICE9IE5VTEwpIHsK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqbXRhaWxwID0gbTsKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtdGFpbHAgPSAmKCptdGFpbHAp LT5tX25leHRwa3Q7CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0KKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaWYgKG1uZXh0ICE9IE5VTEwpIHsKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqbXRhaWxwID0gbW5leHQ7CisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbXRhaWxwID0gJigqbXRhaWxwKS0+bV9uZXh0 cGt0OworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGJyZWFrOworI2lmZGVmIElORVQ2CisgICAgICAgICAgICAgICAgICAg ICAgICBjYXNlIDY6CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIChtICE9IE5V TEwpIHsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqbTZfdGFpbHAg PSBtOworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG02X3RhaWxwID0g JigqbTZfdGFpbHApLT5tX25leHRwa3Q7CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IH0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWYgKG1uZXh0ICE9IE5VTEwpIHsK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqbTZfdGFpbHAgPSBtbmV4 dDsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtNl90YWlscCA9ICYo Km02X3RhaWxwKS0+bV9uZXh0cGt0OworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9 CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJyZWFrOworI2VuZGlmCisgICAgICAg ICAgICAgICAgICAgICAgICB9CisKKyAgICAgICAgICAgICAgICAgICAgICAgIG0gPSBtbmV4dCA9 IE5VTEw7CiAJCX0KIAl9CiAJSVBGV19EWU5fVU5MT0NLKCk7CkBAIC00NTg1LDYgKzQ2MzEsMTMg QEAKIAkJbS0+bV9uZXh0cGt0ID0gTlVMTDsKIAkJaXBfb3V0cHV0KG0sIE5VTEwsIE5VTEwsIDAs IE5VTEwsIE5VTEwpOwogCX0KKyNpZmRlZiBJTkVUNgorICAgICAgICBmb3IgKG0gPSBtbmV4dCA9 IG02OyBtICE9IE5VTEw7IG0gPSBtbmV4dCkgeworICAgICAgICAgICAgICAgIG1uZXh0ID0gbS0+ bV9uZXh0cGt0OworICAgICAgICAgICAgICAgIG0tPm1fbmV4dHBrdCA9IE5VTEw7CisgICAgICAg ICAgICAgICAgaXA2X291dHB1dChtLCBOVUxMLCBOVUxMLCAwLCBOVUxMLCBOVUxMLCBOVUxMKTsK KyAgICAgICAgfQorI2VuZGlmCiBkb25lOgogCWNhbGxvdXRfcmVzZXQoJlZfaXBmd190aW1lb3V0 LCBWX2R5bl9rZWVwYWxpdmVfcGVyaW9kICogaHosCiAJCSAgICAgIGlwZndfdGljaywgTlVMTCk7 Cg== ------=_20090621233511_54797-- From bugmaster at FreeBSD.org Mon Jun 22 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 22 11:08:29 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200906221106.n5MB6vq9018066@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/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 59 problems total. From rizzo at iet.unipi.it Mon Jun 22 16:50:18 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Jun 22 16:50:25 2009 Subject: ipfw and dummynet for linux now available Message-ID: <20090622163619.GA27560@onelab2.iet.unipi.it> With Marta Carbone we have recently completed a port to Linux of ipfw and dummynet, and we also took the chance to put online some updated picobsd images for FreeBSD. Code, papers and binary modules are available at http://info.iet.unipi.it/~luigi/dummynet/ cheers luigi From on at cs.ait.ac.th Tue Jun 23 10:50:46 2009 From: on at cs.ait.ac.th (Olivier Nicole) Date: Tue Jun 23 10:50:53 2009 Subject: PCI-X SATA card for FreeBSD Message-ID: <200906231021.n5NALD27006751@banyan.cs.ait.ac.th> Hi, I am not sure if any card of the type exists, but I am looking for a PCI-X card with external SATA connector (1 or 2) to supports port multiplier. Idea is to attach a bank of disk to use a backup media. TIA, Olivier From on at cs.ait.ac.th Wed Jun 24 04:13:58 2009 From: on at cs.ait.ac.th (Olivier Nicole) Date: Wed Jun 24 04:14:05 2009 Subject: security/pgp on amd64 Message-ID: <200906240413.n5O4DpZg004113@banyan.cs.ait.ac.th> Hi, Is the port security/pgp working on amd64 system? I copied my public and private keyrings from i386 to amd64 system and I cannot decipher any file, it keeps on complaining that the pass phrase is bad. TIA, Olivier From max at love2party.net Wed Jun 24 05:00:20 2009 From: max at love2party.net (Max Laier) Date: Wed Jun 24 05:00:27 2009 Subject: security/pgp on amd64 In-Reply-To: <200906240413.n5O4DpZg004113@banyan.cs.ait.ac.th> References: <200906240413.n5O4DpZg004113@banyan.cs.ait.ac.th> Message-ID: <200906240647.43334.max@love2party.net> On Wednesday 24 June 2009 06:13:51 Olivier Nicole wrote: > Is the port security/pgp working on amd64 system? > > I copied my public and private keyrings from i386 to amd64 system and > I cannot decipher any file, it keeps on complaining that the pass > phrase is bad. Clearly the wrong mailing list. The file format might be different. Try exporting an ascii armored version on i386 and importing it on amd64. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From holger.rauch at empic.de Fri Jun 26 08:54:51 2009 From: holger.rauch at empic.de (Holger Rauch) Date: Fri Jun 26 08:54:58 2009 Subject: Any *Working* Examples of kernel-based (IPFW2-based) NAT onFreeBSD 7.1-STABLE? Message-ID: <20090626085530.GA2623@heitec.de> Hi, I'm having trouble setting up "hide NAT" (hiding several internal addresses "behind" an external one) and "1:1 NAT" (one certain external IP address for each corresponding internal one) on a FreeBSD 7.1-STABLE system (AMD64 architecture). My questions: - Does kernel-based (IPFW2-based) NAT work at all with FreeBSD 7.1-STABLE? - If so, can someone please provide some working examples? - In case it doesn't, do you recommend me to use user-space natd instaed? - For user-space natd, it's probably best to run two instances like the natd man page suggests? In case someone is interested in further details, please take a look at my previous message posted to this list: http://lists.freebsd.org/pipermail/freebsd-ipfw/2009-June/003909.html Thanks in advance for any advice! Kind regards, Holger -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20090626/75fe9edd/attachment.pgp From max at love2party.net Fri Jun 26 09:04:11 2009 From: max at love2party.net (Max Laier) Date: Fri Jun 26 09:04:29 2009 Subject: pfsync rc script breaks pfsync on cloned interfaces In-Reply-To: <4A444BC2.4010606@FreeBSD.org> References: <4A444BC2.4010606@FreeBSD.org> Message-ID: <200906261104.07597.max@love2party.net> On Friday 26 June 2009 06:17:06 Doug Barton wrote: > I have reverted the change that caused pf and ipfw to appear before > netif in the rcorder. While I still feel strongly that it is the > "right thing" to configure the firewalls first, the changes caused too > many problems for too many users, and it's too late in the release > cycle to make a change like this that has significant side effects. > > I would like to strongly encourage those who use pf and ipfw to > consider doing the work required to make this change possible. With > ipfw it's not quite as urgent since by default it does not pass > packets till it is configured. This is not the case with pf, as its > default is wide open until it is configured. It's not a simple problem and I'm not sure we can really come up with a "one-size-fits-all" solution. That does not mean we shouldn't try, though. My idea how this should work is something along the following lines: 1) Very early in the boot (just after the necessary firewall configuration tools are available [NFS-root might be a problem here!]) setup an "initial firewall" configuration. For most users this could be a default (allow dhcp, outgoing DNS, maybe ssh in/out, NFS(???), ...). 2) After setting up the interfaces have the option to start a more involved firewall that is fully user supplied. At this point we should be able to look up DNS (though this is clearly a bad idea from the security PoV unless you have DNSSEC), get interface configurations and maybe even routing information. The latter could be another chicken-egg-problem as we might need a routing daemon active to get this. However, people who really need that should be able to modify the early setup accordingly. It is unclear to me where stage 2 should be located. I would argue that with a reasonable default setup we can easily get away with putting stage 2 at the very end of the start up procedure. If people need early holes in the firewall (e.g. for smbfs, routing daemons, ...) they can place them in the early stage. I would like input about how a very simple "save default" setup could look like. A ruleset for pf or ipfw that allows most of the boot process to complete without opening the host to the outside world, yet. For extra points this ruleset is aware of the rc.conf variables and adjusts accordingly (e.g. opening access to sshd iff it is configured). In addition there might be *one or two* configuration variables for the early stage to open additional ports or to select a default interface. However, the fewer the better. Input greatly appreciated! -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From dimitry at andric.com Fri Jun 26 11:58:24 2009 From: dimitry at andric.com (Dimitry Andric) Date: Fri Jun 26 11:58:42 2009 Subject: pfsync rc script breaks pfsync on cloned interfaces In-Reply-To: <200906261104.07597.max@love2party.net> References: <4A444BC2.4010606@FreeBSD.org> <200906261104.07597.max@love2party.net> Message-ID: <4A44B7DE.2090503@andric.com> On 2009-06-26 11:04, Max Laier wrote: > I would like input about how a very simple "save default" setup could look > like. A ruleset for pf or ipfw that allows most of the boot process to > complete without opening the host to the outside world, yet. For extra > points this ruleset is aware of the rc.conf variables and adjusts > accordingly (e.g. opening access to sshd iff it is configured). In > addition there might be *one or two* configuration variables for the early > stage to open additional ports or to select a default interface. However, > the fewer the better. If you look at how OpenBSD implements their /etc/rc script, you will see it first loads a simple PF ruleset, which allows ssh, dns, icmp echo and (if applicable) IPv6 routing and neighbor advertisements. Then it does the regular network setup (/etc/netstart), followed by loading the full PF rules. Relevant excerpt: ###################### if [ X"${pf}" != X"NO" ]; then RULES="block all" RULES="$RULES\npass on lo0" RULES="$RULES\npass in proto tcp from any to any port 22 keep state" RULES="$RULES\npass out proto { tcp, udp } from any to any port 53 keep state" RULES="$RULES\npass out inet proto icmp all icmp-type echoreq keep state" if ifconfig lo0 inet6 >/dev/null 2>&1; then RULES="$RULES\npass out inet6 proto icmp6 all icmp6-type neighbrsol" RULES="$RULES\npass in inet6 proto icmp6 all icmp6-type neighbradv" RULES="$RULES\npass out inet6 proto icmp6 all icmp6-type routersol" RULES="$RULES\npass in inet6 proto icmp6 all icmp6-type routeradv" fi RULES="$RULES\npass proto carp keep state (no-sync)" case `sysctl vfs.mounts.nfs 2>/dev/null` in *[1-9]*) # don't kill NFS RULES="set reassemble yes no-df\n$RULES" RULES="$RULES\npass in proto { tcp, udp } from any port { 111, 2049 } to any" RULES="$RULES\npass out proto { tcp, udp } from any to any port { 111, 2049 }" ;; esac echo $RULES | pfctl -f - pfctl -e fi # Fill net.inet.(tcp|udp).baddynamic lists from /etc/services fill_baddynamic udp fill_baddynamic tcp sysctl_conf # set hostname, turn on network echo 'starting network' ifconfig -g carp carpdemote 128 if [ -f /etc/resolv.conf.save ]; then mv /etc/resolv.conf.save /etc/resolv.conf touch /etc/resolv.conf fi . /etc/netstart if [ X"${pf}" != X"NO" ]; then if [ -f ${pf_rules} ]; then pfctl -f ${pf_rules} fi # bring up pfsync after the working ruleset has been loaded if [ -f /etc/hostname.pfsync0 ]; then . /etc/netstart pfsync0 fi fi ###################### Perhaps this approach can be molded into /etc/rc.d form? :) From dougb at FreeBSD.org Fri Jun 26 15:21:22 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jun 26 15:21:29 2009 Subject: pfsync rc script breaks pfsync on cloned interfaces In-Reply-To: <4A44B7DE.2090503@andric.com> References: <4A444BC2.4010606@FreeBSD.org> <200906261104.07597.max@love2party.net> <4A44B7DE.2090503@andric.com> Message-ID: <4A44E198.3050004@FreeBSD.org> Dimitry Andric wrote: > On 2009-06-26 11:04, Max Laier wrote: >> I would like input about how a very simple "save default" setup could look >> like. A ruleset for pf or ipfw that allows most of the boot process to >> complete without opening the host to the outside world, yet. For extra >> points this ruleset is aware of the rc.conf variables and adjusts >> accordingly (e.g. opening access to sshd iff it is configured). In >> addition there might be *one or two* configuration variables for the early >> stage to open additional ports or to select a default interface. However, >> the fewer the better. > > If you look at how OpenBSD implements their /etc/rc script, you will see > it first loads a simple PF ruleset, which allows ssh, dns, icmp echo and > (if applicable) IPv6 routing and neighbor advertisements. > > Then it does the regular network setup (/etc/netstart), followed by > loading the full PF rules. I think that would be a great approach, it's just waiting for someone familiar with pf to implement it. :) I also forgot to mention, there is no need to include me on future cc's for this topic. Regards, Doug -- This .signature sanitized for your protection From mailinglistmember at mgwigglesworth.net Mon Jun 29 03:25:26 2009 From: mailinglistmember at mgwigglesworth.net (Systems Engineering Group) Date: Mon Jun 29 03:25:38 2009 Subject: Any *Working* Examples of kernel-based (IPFW2-based) NAT onFreeBSD 7.1-STABLE? References: <20090626085530.GA2623@heitec.de> Message-ID: <1246244218.8710.237.camel@localhost> I don't know why you are attempting to be so "eligant" which is a smart-guy way of saying making something more complex by leaving out certain things that are still relivant, but "messy" as an experienced person would see it) if you are new to the methods. First, you need to make sure that natd is doing its job, by making sure that you have natd turned on, and that it is using the correct interface. Second, when you have verified that the natd configuration is accurate, and usable, the kernel needs to be verified to have the correct options, and that the ipfw rules, setup. You only need divert, and ipfirewall, with ipfirewall_verbose if you want logging. With these kernel options in place, you need to compile and install the kernel correlative to these installed kernel options for the firewalling functionality, with divertion to work. Given these aspects of the system are installed, then you only need to place a natd divert rule into the script for your ipfw-centric firewall. An example would be to start natd with the following included in either commandline options, or config file referenced at commandline call to natd (natd -f /path/to/natd/config) at the commandline, or requisite init script: natd -i $divert_iface -d This should start natd with the -i switch giving indication to natd what device is used to be translated (from/to). After verfication of initialization of the natd daemon via `sockstat | grep natd` you should then test divert rules within your ipfw script, or via dynamic rules that you sent at commandline. The simplest way to test the operation of the divert rules is to do the following. ipfw add 100 pass log tcp from any to any in via $divert_iface #The traffic coming into the external ip addresss will be "diverted" to the internal network ip range. ipfw add 200 divert natd ip from any to any in via $divert_iface ## #Rules 201-499 will be used to filter on the internal addresses after being mangled by the kernel. #They will now look like they are going to #the internal address, not the external ip address, so internal-ip-based #rules will be affective at this time. ## #This rule will divert traffic going from the internal network to the external network ipfw add 500 divert natd ip from any to any out via $divert_iface This is a very brief view of an example that works with freebsd. I would stay away from the complex "elegant" solutions that you referenced in your original post, on or about June 14th, until you verify that your solution is working properly. Check out the handbook, and the information on firewalling on onlamp.org and the freebsd handbook. I am just doing a datadump of my own experience right now, so if you have any further questions, then just post them and we can take a look. The setup is not very difficult, once you have the basics down. I have about thirty rules in my script, but about 20 of them have to do with filtering different stuff, which is merely skipto to a deletion rule with logging. ipfw and natd are not very difficult to use, however, that simplicity is also what makes it such a powerful network appliance solution. I have heard the ipnat + netfilter is supposedly more powerful solution, because ipnat does certain things better than natd, however, that is something for further exploration, and I have not had a need to do so, as of yet. I hope this assists your in your setup endeavor. Respectfully, Martes -- Systems Engineering Group M. G. Wigglesworth Holdings, LLC From mailinglistmember at mgwigglesworth.net Mon Jun 29 03:39:40 2009 From: mailinglistmember at mgwigglesworth.net (Systems Engineering Group) Date: Mon Jun 29 03:39:52 2009 Subject: Any *Working* Examples of kernel-based (IPFW2-based) NAT onFreeBSD 7.1-STABLE? References: <20090626085530.GA2623@heitec.de> <1246244218.8710.237.camel@localhost> Message-ID: <1246246885.8710.239.camel@localhost> The natd command should use the -interface switch, or -n however, the best ways to become informed about natd is to simply run a man natd and read the part about "Running natd," because you will get more out of it. man ipfw is also very informative. On Sun, 2009-06-28 at 22:56 -0400, Systems Engineering Group wrote: > I don't know why you are attempting to be so "eligant" which is a > smart-guy way of saying making something more complex by leaving out > certain things that are still relivant, but "messy" as an experienced > person would see it) if you are new to the methods. > > First, you need to make sure that natd is doing its job, by making sure > that you have natd turned on, and that it is using the correct > interface. > > Second, when you have verified that the natd configuration is accurate, > and usable, the kernel needs to be verified to have the correct options, > and that the ipfw rules, setup. > > You only need divert, and ipfirewall, with ipfirewall_verbose if you > want logging. > > With these kernel options in place, you need to compile and install the > kernel correlative to these installed kernel options for the firewalling > functionality, with divertion to work. > > Given these aspects of the system are installed, then you only need to > place a natd divert rule into the script for your ipfw-centric firewall. > > An example would be to start natd with the following included in either > commandline options, or config file referenced at commandline call to > natd (natd -f /path/to/natd/config) > > at the commandline, or requisite init script: natd -i $divert_iface -d > > This should start natd with the -i switch giving indication to natd what > device is used to be translated (from/to). > > After verfication of initialization of the natd daemon via `sockstat | > grep natd` you should then test divert rules within your ipfw script, or > via dynamic rules that you sent at commandline. > > The simplest way to test the operation of the divert rules is to do the > following. > > ipfw add 100 pass log tcp from any to any in via $divert_iface > > #The traffic coming into the external ip addresss will be "diverted" to > the internal network ip range. > ipfw add 200 divert natd ip from any to any in via $divert_iface > > ## > #Rules 201-499 will be used to filter on the internal addresses after > being mangled by the kernel. > #They will now look like they are going to #the internal address, not > the external ip address, so internal-ip-based > #rules will be affective at this time. > ## > > #This rule will divert traffic going from the internal network to the > external network > ipfw add 500 divert natd ip from any to any out via $divert_iface > > This is a very brief view of an example that works with freebsd. > I would stay away from the complex "elegant" solutions that you > referenced in your original post, on or about June 14th, until you > verify that your solution is working properly. > > Check out the handbook, and the information on firewalling on onlamp.org > and the freebsd handbook. > > I am just doing a datadump of my own experience right now, so if you > have any further questions, then just post them and we can take a look. > > The setup is not very difficult, once you have the basics down. > > I have about thirty rules in my script, but about 20 of them have to do > with filtering different stuff, which is merely skipto to a deletion > rule with logging. > > ipfw and natd are not very difficult to use, however, that simplicity is > also what makes it such a powerful network appliance solution. I have > heard the ipnat + netfilter is supposedly more powerful solution, > because ipnat does certain things better than natd, however, that is > something for further exploration, and I have not had a need to do so, > as of yet. > > I hope this assists your in your setup endeavor. > > Respectfully, > > Martes > From bugmaster at FreeBSD.org Mon Jun 29 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 29 11:08:29 2009 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200906291107.n5TB70sP046373@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/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 59 problems total. From niteshbharti123 at gmail.com Mon Jun 29 14:08:48 2009 From: niteshbharti123 at gmail.com (Nitesh. Bharti) Date: Mon Jun 29 14:08:55 2009 Subject: AstroWix Solutions Message-ID: <4a48af94.1a36720a.143f.6ef1@mx.google.com> AstroWix is a forward thinking Program and Project Management Solutions Company. With its strong adherence to Project Management norms, AstroWix facilitates organizations to excel in their respective business domains by achieving their desired organizational goals at the right time and at minimum budget. Our services range from helping organizations select the right projects, programs and portfolios to effectively drive business value and achieve sustainable competitive advantage. For the balanced and effective execution of these solutions, we blend a series of services which include Project Management Consulting, Project Management Competency Development, Setup and Support of Project Management Office, Collaboration and SharePoint Deployment and End-to-End Project Management Support. As a registered Education Provider of PMI, AstroWix is a leading provider for Project Management Training in helping professionals with their PMPR Certification India . PMP certification preparation involves rigorous training but our PMP training program ensures every PMP aspirant a comprehensive, quality and up to date training. For PMPR Certification India, AstroWix is a very popular choice for PMP professionals and PMP aspirants, providing training and end-to-end support for professionals to prepare for PMPR Certification examination. To know more about Project Management Training , PMP R Certification India Visit : www.astrowix.com Nitesh Ranjan AstroWix Project Solutions Pvt Ltd From niteshbharti123 at gmail.com Mon Jun 29 14:17:44 2009 From: niteshbharti123 at gmail.com (Nitesh. Bharti) Date: Mon Jun 29 14:17:50 2009 Subject: AstroWix Solutions Message-ID: <4a48af9c.1a36720a.143f.6efc@mx.google.com> AstroWix is a forward thinking Program and Project Management Solutions Company. With its strong adherence to Project Management norms, AstroWix facilitates organizations to excel in their respective business domains by achieving their desired organizational goals at the right time and at minimum budget. Our services range from helping organizations select the right projects, programs and portfolios to effectively drive business value and achieve sustainable competitive advantage. For the balanced and effective execution of these solutions, we blend a series of services which include Project Management Consulting, Project Management Competency Development, Setup and Support of Project Management Office, Collaboration and SharePoint Deployment and End-to-End Project Management Support. As a registered Education Provider of PMI, AstroWix is a leading provider for Project Management Training in helping professionals with their PMPR Certification India . PMP certification preparation involves rigorous training but our PMP training program ensures every PMP aspirant a comprehensive, quality and up to date training. For PMPR Certification India, AstroWix is a very popular choice for PMP professionals and PMP aspirants, providing training and end-to-end support for professionals to prepare for PMPR Certification examination. To know more about Project Management Training , PMP R Certification India Visit : www.astrowix.com Nitesh Ranjan AstroWix Project Solutions Pvt Ltd