Re: kern/173659: PF fatal trap on 9.1 (taskq fatal trap on pf_test_rule)
The following reply was made to PR kern/173659; it has been noted by GNATS. From: Gleb Smirnoff To: bug-follo...@freebsd.org Cc: Subject: Re: kern/173659: PF fatal trap on 9.1 (taskq fatal trap on pf_test_rule) Date: Mon, 19 Nov 2012 14:13:23 +0400 Since Patricks mail server bounces my mail, try to communicate via GNATS. - Forwarded message from Gleb Smirnoff - Date: Sun, 18 Nov 2012 01:59:58 +0400 From: Gleb Smirnoff To: Patrick Tracanelli Subject: Re: kern/173659: PF fatal trap on 9.1 (taskq fatal trap on pf_test_rule) User-Agent: Mutt/1.5.21 (2010-09-15) Patrick, couple of questions on the problem report: 1) Do you have ability to test FreeBSD 10 in the same conditions? pf in 10 differs much from 9. 2) Can you please send me pf rulesets? 3) Can you please provide the below info from the crash dump: P> #7 0x81525888 in pf_addrcpy (dst=0xfe0013942918, src=0x10, P> af=2 '\002') at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:522 P> #8 0x8152fdbf in pf_test_rule (rm=0xff80002e5848, P> sm=0xff80002e5840, direction=1, kif=0xfe0004c9e000, P> m=0xfe0004febd00, off=20, h=0xfe0013331010, P> pd=0xff80002e5780, am=0xff80002e5850, rsm=0xff80002e5838, P> ifq=0x0, inp=0x0) P> at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:3900 P> #9 0x815c in pf_test (dir=1, ifp=Variable "ifp" is not available. P> ) P> at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6884 P> #10 0x8153a9eb in pf_check_in (arg=Variable "arg" is not available. P> ) P> at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:4131 (kgdb) frame 8 (kgdb) info locals -- Totus tuus, Glebius. - End forwarded message - -- Totus tuus, Glebius. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Current problem reports assigned to freebsd-pf@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/173659 pf [pf] PF fatal trap on 9.1 (taskq fatal trap on pf_test o bin/172888 pf [patch] authpf(8) feature enhancement o kern/172648 pf [pf] [ip6]: 'scrub reassemble tcp' breaks IPv6 packet o kern/171733 pf [pf] PF problem with modulate state in [regression] o kern/169630 pf [pf] [patch] pf fragment reassembly of padded (undersi o kern/168952 pf [pf] direction scrub rules don't work o kern/168190 pf [pf] panic when using pf and route-to (maybe: bad frag o kern/166336 pf [pf] kern.securelevel 3 +pf reload o kern/165315 pf [pf] States never cleared in PF with DEVICE_POLLING o kern/164402 pf [pf] pf crashes with a particular set of rules when fi o kern/164271 pf [pf] not working pf nat on FreeBSD 9.0 [regression] o kern/163208 pf [pf] PF state key linking mismatch o kern/160370 pf [pf] Incorrect pfctl check of pf.conf o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 48 problems total. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Routing return NAT traffic based on interface
Thanks for your reply. I've tried the configuration you suggested but it's providing the same issue I was encountering before. My goal is to route all traffic from the tunnel out the external interface nat'ing it on the way out. Any traffic coming in on the external interface should be un-nat'd (if applicable), then sent back down the tunnel unless it's destined for the external interface's IP (post-un-nat). Is such a configuration possible with PF? -Peter On Fri, Nov 16, 2012 at 10:21 AM, Kevin Wilcox wrote: > On 16 November 2012 09:40, Peter McAlpine wrote: > >> data_if = "tap3" >> ext_if = "em0" >> set skip on lo0 >> nat on $ext_if from !$ext_if:network to any -> ($ext_if) >> pass in on $ext_if route-to $data_if from any to !$ext_if:network > >> The issue I'm having is that the 'pass' rule is not being matched (or >> even evaluated?). My default gateway on the router is the ext_if and >> return traffic is being reverse-translated and then the routing table >> is sending it back out ext_if instead of down data_if where I want it >> to go. > > That's because that's what your NAT rule is telling it to do. > > Your rule says "if I see traffic on the external interface that isn't > on the same network as the external interface, NAT it back out the > external interface" > > Your pass rule should never be used. Your external interface should > never see traffic coming into it that isn't destined for it. > > pf is smart enough to handle the return NAT traffic. > > I think you may have a misunderstanding of how NAT works. > > For simplicity sake, I'll use a fake internal network of 10.10.10.0/24 > and an outside Internet IP address of 4.4.4.4. Let's pretend the > internal interface has an IP of 10.10.10.254 and is the gateway for > the 10.10.10.0/24 network and that we will NAT their outbound traffic. > Now let's pretend there is a web-server at 25.25.25.25. > > When a computer inside my internal network, let's say 10.10.10.10, > wants to get to 25.25.25.25, it hits the gateway of 10.10.10.254. That > router then NATs the traffic. 25.25.25.25 sees a connection request > from 4.4.4.4. It sends back a reply. The router at 4.4.4.4 sees the > return traffic and pf checks its state table. It then changes the > destination for that traffic to be 10.10.10.10 and passes it out the > 10.10.10.254 interface. The whole point of RFC-1918 is that anyone can > re-use those IPs internally without conflicting with anyone else > because the IP seen by everyone else on the Internet is the *outside* > IP. > > A pf configuration to do that would look something like: > > == > > int_if=tun0 > ext_if=em0 > set skip on lo > > nat on $ext_if from $int_if:network to any -> $ext_if > pass in on $int_if from $int_if:network to any keep state > pass out on $ext_if from any to any keep state > > == > > Yes, that is being overly verbose and uses a little older syntax (keep > state, from any to any ) but it works on both OpenBSD and FreeBSD, and > it works on every release within the last few years (I still have > early 4.x OpenBSD routers and 7.x FreeBSD routers). > > Keep in mind that that configuration is *wide open*. > > kmw ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Routing return NAT traffic based on interface
On Nov 19, 2012 3:12 PM, "Peter McAlpine" wrote: > > Thanks for your reply. I've tried the configuration you suggested but > it's providing the same issue I was encountering before. > > My goal is to route all traffic from the tunnel out the external > interface nat'ing it on the way out. Any traffic coming in on the > external interface should be un-nat'd (if applicable), then sent back > down the tunnel unless it's destined for the external interface's IP > (post-un-nat). > > Is such a configuration possible with PF? It is. The "pass in" rule I used in my example assumes the inside interface and the other devices it talks to are in the same network. If you want to pass anything that interface sees, change the rules so that they accept traffic from any IP range : "from $int_if:network to any" becomes "from any to any". I have a couple of routers that pass traffic for 10.x.y.z but their inside IPs are 172.16.a.b addresses and they were configured much the same way in early testing, before filters were added. If changing the rule to pass everything doesn't square you away, a network diagram may be useful (as would me actually looking at my pf configs). kmw ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Routing return NAT traffic based on interface
On Nov 19, 2012 5:54 PM, "Kevin Wilcox" wrote: > It is. The "pass in" rule I used in my example assumes the inside interface and the other devices it talks to are in the same network. Correction, the "pass in" and "nat" rules, not just the pass. They both have to be modified. kmw ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Routing return NAT traffic based on interface
Kevin Wilcox wrote: > > On Nov 19, 2012 5:54 PM, "Kevin Wilcox" wrote: > > > It is. The "pass in" rule I used in my example assumes the inside > > interface and the other devices it talks to are in the same network. > > Correction, the "pass in" and "nat" rules, not just the pass. They > both have to be modified. If I understand what you're proposing, it would be: nat on $ext_if from $int_if:network to any -> $ext_if pass in on $int_if from $int_if:network to any keep state pass out on $ext_if from any to any keep state changed to this: nat on $ext_if from any to any -> $ext_if pass in on $int_if from any to any keep state pass out on $ext_if from any to any keep state This doesn't seem right, because even traffic coming in via the external interface will have its target IP changed to be the router, even if it is destined for some other place. Previously you were using "from $int_if:network" to prevent this from happening to other traffic, but without that restriction, every packet would be subject to NAT. If I understand the poster's problem, it is that there could be whole worlds of other networks behind $int_if, and he is not able to predict what IP addresses should be used to match that traffic; in fact, it is merely the fact that the traffic is arriving on $int_if that indicates it shoudl be NAT'd. What I'd suggest is that packet marking be used to mark packets arriving via $int_if, and then apply NAT to the packets that flow to $ext_if: nat on $ext_if tagged NAT -> $ext_if pass in on $int_if tag NAT pass out on $ext_if Untested configuration idea, of course. :) -- David DeSimone == Network Admin == f...@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free. Thank you. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Routing return NAT traffic based on interface
On 19 November 2012 18:56, David DeSimone wrote: > This doesn't seem right, because even traffic coming in via the external > interface will have its target IP changed to be the router, even if > it is destined for some other place. Previously you were using "from > $int_if:network" to prevent this from happening to other traffic, but > without that restriction, every packet would be subject to NAT. My assumption was that the traffic coming in on the external interface is already destined for the outside IP of the router, unless he's doing some really funky stuff on both sides ;) It sounded like he wanted to NAT anything coming from the inside interface and then anything on the outside that wasn't return NAT traffic was supposed to terminate on the router, but I've been known to have clogged ears and awfully poor eyesight. kmw ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Upgrading FreeBSD to use the NEW pf syntax.
Good day all, I am aware this is a much discussed subject since the upgrade of PF, I believe the final decision was that to many users are used to the old style pf and an upgrade to the new syntax would cause to much confusion. There was a recent debate on ##freebsd about this issue and I was inclined to mail in and get your opinions; basically it boiled down to the majority of users wanting either: 1) To move to the newer pf and just add to releases notes what had happened, and 2) my own personal opinion: creating 'pf2-*' as a kernel option tree, basically using the newer pf syntax and allowing users to choose. I would be interested to know the feedback from you guys as to be honest there seems to be quite a few users who actually DO want the new style format and functionality that comes with. I Attached the log of the conversation just for reference. -- Thank you for your time -- Paul G Webster 'daemon' Using Opera's revolutionary email client: http://www.opera.com/mail/* daemonik (~ad...@mail.originate.com) has joined ##freebsd Is the implementation of PF on FreeBSD up to date yet? no * stormcrow (~phyde...@c-24-126-183-121.hsd1.ga.comcast.net) has left ##freebsd and it won't ever be, we (retardedly) forked it with some random guy's patches rather than updating it it's rare that that question asked about *any* part of the base OS will be answered with "yes" doh. booo @ random patches blakkheim that was truly a stupid move i agree any chance of getting them to 'take it back' they think freebsd users are too stupid to adapt to the newer pf syntax and "thousands will upgrade without knowing and be left with an unreachable system" or some bs like that is there anything that pf can do that ipfw cannot do check the freebsd-pf mailing list illuminated (or feel free to post and complain) blakkheim: That's pretty damn . . wow might be worth a few emails to all the lists asking for other users to post into the pf list to support moving to the correct pf maybe we can implement the newer pf as 'pf2' FreeBSD presently doesn't have ALTQ support included in the generic kernel, correct? Is there an alternative to ALTQ? daemon: i think so too daemon: Is it really that hard to shout in the appropriate places to properly inform users? What about release notes? Anybody who doesn't read release notes deserves what's coming to them. that's what i said! * chrisb has learned to read MOVED and UPDATING closely Huh . . that kind of behavior is why no one respects anyone/thing associated with GNOME anymore . . daemonik, I dont see it being that hard to use both the 'ramdon guys patches' version of pf as the default for a few releases putting the newer version of pf as 'pf2' therefor satisfying both channels of thought there certainly should be A WAY of using the newer version posting these thoughts to freebsd-pf@ is much more likely to invoke a change (or at least a poll or something) than on irc daemon: No . . the noobs are the ones who should have to use a pf-something. I bother to read the release notes, I want to use the correct version of the software. Why should I have to suffer? Why should I change when they're the ones who suck? * nightwalk has quit (Ping timeout: 276 seconds) I'll make a post later tonight. I hope that others see these messages and also articulate their thoughts on the mailing list. FreeBSD should hold a high standard for something as important as PF. daemonik, if you did read release notes you would see 'ad the new version of pf is pf2' there is no need to upset users without cause; as the 'patched' pf is the default for the tag 'pf' at the moment making the new version 'pf2' is literally much more sane and certainly a huge degree less antagonistic How do I find the size of a folder? And for that matter how do I search a man page? du -sh dirname and use /string to search Thanks blakkheim I would rather read the release notes seeing that the WRONG version of PF gets deprecated to pf-legacy as it ought to be knowing that those who don't read the release notes will have a bad day. Referring to the CORRECT and latest stable version of PF as "PF2" would make FreeBSD . . well, look about as incompetent as certain Linux distros sometimes do to say the least. daemonik, transistion time should always be taken into account on any system; if we did was I was suggesting then 'pf' would be the new version in -CURRENT but for later 9.x releases it would still have to be as I pointed out above i recall a number of features having 2 tagged to the name UFS2 for one or was it FFS2 and i think IPFW2 its quite a common practice; sudeenly changing a major feature/system is just generally what makes people cry especially when it can be avoided with something as simple as adding a number to the end of the kernel tag kernel option*___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/l
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Mon, Nov 19, 2012 at 9:23 PM, Paul Webster wrote: > Good day all, > > I am aware this is a much discussed subject since the upgrade of PF, I > believe the final decision was that to many users are used to the old > style pf and an upgrade to the new syntax would cause to much confusion. > > There was a recent debate on ##freebsd about this issue and I was inclined > to mail in and get your opinions; basically it boiled down to the majority > of users wanting either: > > 1) To move to the newer pf and just add to releases notes what had > happened, > and > 2) my own personal opinion: creating 'pf2-*' as a kernel option tree, > basically using the newer pf syntax and allowing users to choose. > > I would be interested to know the feedback from you guys as to be honest > there seems to be quite a few users who actually DO want the new style > format and functionality that comes with. My vote is for option 1, but I'll also be happy with option 2 if it costs little to maintain both versions. I'm pretty much for anything that brings pf in sync (or close to it) with OpenBSD. - Max ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
I am not so sure there would be much more maintenance, after all after the split the only updates to the original 'pf-*' tree would be any serious security or stability updates that happen to crop up. All feature updates etc would be to the pf2-* On Tue, 20 Nov 2012 02:52:53 -, Maxim Khitrov wrote: On Mon, Nov 19, 2012 at 9:23 PM, Paul Webster wrote: Good day all, I am aware this is a much discussed subject since the upgrade of PF, I believe the final decision was that to many users are used to the old style pf and an upgrade to the new syntax would cause to much confusion. There was a recent debate on ##freebsd about this issue and I was inclined to mail in and get your opinions; basically it boiled down to the majority of users wanting either: 1) To move to the newer pf and just add to releases notes what had happened, and 2) my own personal opinion: creating 'pf2-*' as a kernel option tree, basically using the newer pf syntax and allowing users to choose. I would be interested to know the feedback from you guys as to be honest there seems to be quite a few users who actually DO want the new style format and functionality that comes with. My vote is for option 1, but I'll also be happy with option 2 if it costs little to maintain both versions. I'm pretty much for anything that brings pf in sync (or close to it) with OpenBSD. - Max -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
Just out of interest, option 3) does not entirely dismiss using the pf2-* chain of kernel options for developing using the new pf tree; sure it would be alot of work but just 'how much' would be required; Our own fork after all means that everything is created from scratch and as its 'vastly different' from the OpenBSD version surely that will also require a vast amount of time. I should probably point that doing both at the same time would by sane observation mean two projects requiring a vast amount of time; but if enough people support the 'pf2' chain then in conjunction with the fact that we should be able to borrow some of the code from OpenBSD, maybe it would be worth the sacrifice. Time will tell which one becomes the more popular. On Tue, 20 Nov 2012 03:02:40 -, Chris Buechler wrote: On Mon, Nov 19, 2012 at 8:23 PM, Paul Webster wrote: Good day all, I am aware this is a much discussed subject since the upgrade of PF, I believe the final decision was that to many users are used to the old style pf and an upgrade to the new syntax would cause to much confusion. There was a recent debate on ##freebsd about this issue and I was inclined to mail in and get your opinions; basically it boiled down to the majority of users wanting either: 1) To move to the newer pf and just add to releases notes what had happened, and 2) my own personal opinion: creating 'pf2-*' as a kernel option tree, basically using the newer pf syntax and allowing users to choose. The line in the sand has been drawn with the SMP-friendly PF now in HEAD. The reality is seeming to be option 3) FreeBSD pf is drastically different and will be a fork from this point, as those SMP changes make future merges impossible without redoing a whole lot of work. There was some discussion and regrets here that it wasn't brought up to the most recent pf before doing all that work, but it's done and committed at this point. There was a good deal of discussion here at that time, check this list's archive from earlier this year. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
On 2012-Nov-20 02:23:07 -, Paul Webster wrote: >I am aware this is a much discussed subject since the upgrade of PF, I >believe the final decision was that to many users are used to the old >style pf and an upgrade to the new syntax would cause to much confusion. FreeBSD deprecation policies mean that the existing (old) pf syntax would need to be supported for at least the duration of the 9.x branch (and possibly the 10.x branch). >1) To move to the newer pf and just add to releases notes what had >happened, Since the new pf syntax is incompatible with the existing syntax, this would not be acceptable on any stable branch (8.x, 9.x). It could be done on 10.x but the incompatibility would make migrating from 9.x to 10.x harder. >2) my own personal opinion: creating 'pf2-*' as a kernel option tree, >basically using the newer pf syntax and allowing users to choose. This would probably be the preferred option as it would allow users to migrate at their leisure. >I would be interested to know the feedback from you guys as to be honest >there seems to be quite a few users who actually DO want the new style >format and functionality that comes with. My understanding is that there are significant differences in locking between OpenBSD and FreeBSD, which would make porting the new pf non- trivial. New feature requests generally come down to finding the man- power to implement and maintain them. -- Peter Jeremy pgpJbqAboto9N.pgp Description: PGP signature
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Tue, Nov 20, 2012 at 5:23 AM, Paul Webster wrote: > Good day all, > > I am aware this is a much discussed subject since the upgrade of PF, I > believe the final decision was that to many users are used to the old > style pf and an upgrade to the new syntax would cause to much confusion. > > There was a recent debate on ##freebsd about this issue and I was inclined > to mail in and get your opinions; basically it boiled down to the majority > of users wanting either: > > 1) To move to the newer pf and just add to releases notes what had > happened, > and > 2) my own personal opinion: creating 'pf2-*' as a kernel option tree, > basically using the newer pf syntax and allowing users to choose. > > I would be interested to know the feedback from you guys as to be honest > there seems to be quite a few users who actually DO want the new style > format and functionality that comes with. > > I Attached the log of the conversation just for reference. > > It's been difficult enough to maintain PF on FreeBSD because of the time needed to be invested in the FreeBSD port. This situation remains to date, from what I understand. I guess someone can look at how many bugs/feature requests still remain open for PF on FreeBSD. I therefore feel that whoever wants to run PF should use a dedicated OpenBSD box as a firewall/whatever they use PF for. There is really no point trying to make FreeBSD be OpenBSD when it comes to such requirements. Look at the advantages of "separation of power" - give to OpenBSD the fireallpower and FreeBSD the serverpower. In keeping with the K.I.S.S principle, please let anyone needing new PF syntax just use OpenBSD. My humble opinion. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler. ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
WAN load balance with PF
With a topology like: - ADSL 1 LAN PF Box - Switch | - ADSL 2 Is there a way to NAT and distribute LAN to internet traffic on the two ADSL links apart from adding a third NIC to PF box? ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Tue, Nov 20, 2012 at 7:46 AM, Odhiambo Washington wrote: > On Tue, Nov 20, 2012 at 5:23 AM, Paul Webster < > paul.g.webs...@googlemail.com > > wrote: > > > Good day all, > > > > I am aware this is a much discussed subject since the upgrade of PF, I > > believe the final decision was that to many users are used to the old > > style pf and an upgrade to the new syntax would cause to much confusion. > > > > There was a recent debate on ##freebsd about this issue and I was > inclined > > to mail in and get your opinions; basically it boiled down to the > majority > > of users wanting either: > > > > 1) To move to the newer pf and just add to releases notes what had > > happened, > > and > > 2) my own personal opinion: creating 'pf2-*' as a kernel option tree, > > basically using the newer pf syntax and allowing users to choose. > > > > I would be interested to know the feedback from you guys as to be honest > > there seems to be quite a few users who actually DO want the new style > > format and functionality that comes with. > > > > I Attached the log of the conversation just for reference. > > > > > It's been difficult enough to maintain PF on FreeBSD because of the time > needed to be invested in the FreeBSD port. > This situation remains to date, from what I understand. I guess someone can > look at how many bugs/feature requests still remain open for PF on FreeBSD. > > I therefore feel that whoever wants to run PF should use a dedicated > OpenBSD box as a firewall/whatever they use PF for. > There is really no point trying to make FreeBSD be OpenBSD when it comes to > such requirements. Look at the advantages of "separation of power" - give > to OpenBSD the fireallpower and FreeBSD the serverpower. > > In keeping with the K.I.S.S principle, please let anyone needing new PF > syntax just use OpenBSD. > > My humble opinion. > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254733744121/+254722743223 > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > I can't hear you -- I'm using the scrambler. > ___ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org" > The truth is that you can add a shim layer between the old syntax to new syntax and maintain the new 'locking' present in 10.x branch. Maybe it would be worth to send a project proposal to the FreeBSD Foundation about this, but i do not know how keen they are to support through funding this. When the locking was changed there were a discussion about keeping both of the versions but it was just thrown to the trash by the guy doing the new 'locking'. Probably it has to be asked to the foundation how keen they are to support this development to have things upgraded. -- Ermal ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
