Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 2014-07-29 0:07, Kevin Oberman wrote: And all IPv6 NAT is evil and should be cast into (demonic residence of your choosing) on sight! NAT on IPv6 serves no useful purpose at all. It only serves to complicate things and make clueless security officers happy. It adds zero security. It is a great example of people who assume that NAT is a security feature in IPv4 (it's not) so it should also be in IPv6. .. > So putting support for NAT66 or any IPv6 NAT into a firewall is just > making things worse. Please don't do it! Well said I'm actually rather relieved that natd can/should go away. Stops giving me migraines with all those special protocl cases that don't like to be natted.. Which of course started as early as FTP. --WjW ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 29/07/2014 8:07 AM, Kevin Oberman wrote: ... > And all IPv6 NAT is evil and should be cast into (demonic residence > of your choosing) on sight! For the most part, I agree with you but the problem is "checkbox" comparisons. That IPv6 shouldn't be NAT'd is why I didn't implement it for such a long time. However given the problem that EIDs pose for privacy, I'm of the opinion that maybe NAT66 does have a place but not in the way that the NAT66 RFC prescribes. Darren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Darren, On Sat, Jul 19, 2014 at 09:36:06PM -0700, Darren Pilgrim wrote: D> Never mistake silence for consent. D> D> The vast majority of people don't know pf is outdated and broken on D> FreeBSD because they don't know what they're missing and likely aren't D> using IPv6 yet. The moment you turn on IPv6 and restart a validating D> unbound, you run full-speed into pf's broken behaviour. Make an D> EDNS0-enabled query for a signed zone and you'll get a fragmented UDP D> packet that will never make it through unless you tell pf to allow all D> fragments unconditionally. They'll simply think something is wrong with D> unbound, turn off EDNS0 and/or validation, hurt peformance and/or D> security in the process, and never realize their firewall is doing D> literally the worst possible thing it could do. D> D> All because over half a decade ago some folks got all butthurt over a D> config file format change. Do I understand you right, that you propose a tens thousands lines of untrivial code bulk update in order to fix a particular bug, that can be nailed down separately? Do you also say that breaking configuration files for a large number of people is okay if the update is expected to fix a bug unrelated to configuration? For me sounds like hunting a sparrow with a cannon. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, Jul 20, 2014 at 12:30:59PM -0400, Mike. wrote: M> |> imho, the root problem here is that an effort to implement a M> single M> |> feature improvement (multi-threading) has caused the FreeBSD M> version M> |> of pf to apparently reach a near-unmaintainable position in the M> |> FreeBSD community because improvements from OpenBSD can no longer M> be M> |> ported over easily. FreeBSD's pf has been put in a virtual M> |> isolation chamber due to the multi-threaded enhancement. M> |> M> |> Was it worth it? M> | M> |Yes. This happened *three times* in BSD land now. How much more M> |proof does it take to make that clear? M> |[snip] M> M> In this instance, more proof would consist of pf development not M> wallowing in inactivity. M> M> imo, tactical changes were implemented in pf without the strategic M> negative consequences affecting the decision process guiding the M> implementation of those tactical features.And that's backwards. M> Strategies direct tactics, not vice versa. I would strongly disagree with you. I would claim that directions I've put in pf in 2012 are strategically correct, while previous life of pf in FreeBSD was not. History: pf appeared in FreeBSD in 2004 in 5.3-RELEASE. It was already outdated. It isn't possible otherwise. While Max spent time on porting some stable version, the OpenBSD moved forward. It was later updated again by Max, and again right after update it was outdated. I mean that people who a) believe that OpenBSD pf is the one true b) eager for bleeding edge version, these people simply cannot be satisfied. A porter needs to take latest stable version from OpenBSD and spend some time working on it. So, pf in FreeBSD was always "outdated", even before my SMP work on it. Further history: in 2012 Ermal updates pf and 9.0-RELEASE is shipped. In 2004 we've got 10 years of diverging developement between FreeBSD and OpenBSD. In 2012 it was 18 years. Porting got harder. The pf in 9.x is again outdated and introduces a number of bugs that were not present in 8.x (regressions). Most regressions didn't came from OpenBSD, but were artifacts of porting. Also, the number of #ifdefs in code became so unbearable that no one would want to go through code fixing bugs. In 2012 for me it was obvious that following this route is strategically incorrect. You are never "up to date". You need more efforts to port pf, and you yield in a port of worse and worse quality over time. So, in 2012 I put a lot of efforts to not only bring pf out of a single mutex, but also make it more native to FreeBSD. You can read this through commit logs. The net result is that we got our own pf, that can be maintained further. Unfortunately, still no person is seen on horizon who can take maintainership. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT/CFR] machine independent sf_bufs
Hi!
Sorry for top quoting, this is to annoy you :) I got zero
replies on the below email during a week. I'd really appreciate
testing on different platforms. Any takers?
On Sat, Jul 19, 2014 at 10:27:25AM +0400, Gleb Smirnoff wrote:
T> Hi!
T>
T> we've got a lot of common code in sys/*/*/vm_machdep.c wrt the
T> sf_buf allocation. I have gathered it into kern/subr_sfbuf.c.
T>
T> o No MD code left in sys/*/*/vm_machdep.c.
T> o The arches that have physical map have their implementation in
T> machine/sf_buf.h
T> o The arches that needs sf_bufs use subr_sfbuf.c, optionally having
T> some stuff in machine/sf_buf.h
T>
T> I can test only i386. I'd be grateful for testing:
T>
T> arm
T> mips
T> mips64
T> sparc64
T> powerpc
T> i386 XEN
T>
T> The test is a simple use of any applcation or test that uses sendfile(2).
T> The box shouldn't crash :) of course, and after end of a test there
T> should be no evidence of sf_buf leak (observed via netstat -m).
T>
T> --
T> Totus tuus, Glebius.
T> Index: sys/amd64/include/sf_buf.h
T> ===
T> --- sys/amd64/include/sf_buf.h (revision 268750)
T> +++ sys/amd64/include/sf_buf.h (working copy)
T> @@ -29,10 +29,6 @@
T> #ifndef _MACHINE_SF_BUF_H_
T> #define _MACHINE_SF_BUF_H_
T>
T> -#include
T> -#include
T> -#include
T> -
T> /*
T> * On this machine, the only purpose for which sf_buf is used is to
implement
T> * an opaque pointer required by the machine-independent parts of the
kernel.
T> @@ -39,21 +35,7 @@
T> * That pointer references the vm_page that is "mapped" by the sf_buf. The
T> * actual mapping is provided by the direct virtual-to-physical mapping.
T> */
T> -struct sf_buf;
T> -
T> -static inline struct sf_buf *
T> -sf_buf_alloc(struct vm_page *m, int pri)
T> -{
T> -
T> -return ((struct sf_buf *)m);
T> -}
T> -
T> -static inline void
T> -sf_buf_free(struct sf_buf *sf)
T> -{
T> -}
T> -
T> -static __inline vm_offset_t
T> +static inline vm_offset_t
T> sf_buf_kva(struct sf_buf *sf)
T> {
T>
T> @@ -60,11 +42,10 @@ sf_buf_kva(struct sf_buf *sf)
T> return (PHYS_TO_DMAP(VM_PAGE_TO_PHYS((vm_page_t)sf)));
T> }
T>
T> -static __inline vm_page_t
T> +static inline vm_page_t
T> sf_buf_page(struct sf_buf *sf)
T> {
T>
T> return ((vm_page_t)sf);
T> }
T> -
T> #endif /* !_MACHINE_SF_BUF_H_ */
T> Index: sys/arm/arm/vm_machdep.c
T> ===
T> --- sys/arm/arm/vm_machdep.c (revision 268750)
T> +++ sys/arm/arm/vm_machdep.c (working copy)
T> @@ -50,7 +50,6 @@ __FBSDID("$FreeBSD$");
T> #include
T> #include
T> #include
T> -#include
T> #include
T> #include
T> #include
T> @@ -83,43 +82,7 @@ __FBSDID("$FreeBSD$");
T> CTASSERT(sizeof(struct switchframe) == 24);
T> CTASSERT(sizeof(struct trapframe) == 80);
T>
T> -#ifndef NSFBUFS
T> -#define NSFBUFS (512 + maxusers * 16)
T> -#endif
T> -
T> -static int nsfbufs;
T> -static int nsfbufspeak;
T> -static int nsfbufsused;
T> -
T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, 0,
T> -"Maximum number of sendfile(2) sf_bufs available");
T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, &nsfbufspeak, 0,
T> -"Number of sendfile(2) sf_bufs at peak usage");
T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, &nsfbufsused, 0,
T> -"Number of sendfile(2) sf_bufs in use");
T> -
T> -static void sf_buf_init(void *arg);
T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL);
T> -
T> -LIST_HEAD(sf_head, sf_buf);
T> -
T> /*
T> - * A hash table of active sendfile(2) buffers
T> - */
T> -static struct sf_head *sf_buf_active;
T> -static u_long sf_buf_hashmask;
T> -
T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask)
T> -
T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist;
T> -static u_intsf_buf_alloc_want;
T> -
T> -/*
T> - * A lock used to synchronize access to the hash table and free list
T> - */
T> -static struct mtx sf_buf_lock;
T> -
T> -/*
T> * Finish a fork operation, with process p2 nearly set up.
T> * Copy and update the pcb, set up the stack so that the child
T> * ready to run and return to user mode.
T> @@ -184,107 +147,7 @@ cpu_thread_swapout(struct thread *td)
T> {
T> }
T>
T> -/*
T> - * Detatch mapped page and release resources back to the system.
T> - */
T> void
T> -sf_buf_free(struct sf_buf *sf)
T> -{
T> -
T> - mtx_lock(&sf_buf_lock);
T> - sf->ref_count--;
T> - if (sf->ref_count == 0) {
T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry);
T> - nsfbufsused--;
T> - pmap_kremove(sf->kva);
T> - sf->m = NULL;
T> - LIST_REMOVE(sf, list_entry);
T> - if (sf_buf_alloc_want > 0)
T> - wakeup(&sf_buf_freelist);
T> - }
T> - mtx_unlock(&sf_buf_lock);
T> -}
T> -
T> -/*
T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you prefer.
:-))
Re: local_unbound: since update sporadic hangs in connections
Am Mon, 28 Jul 2014 10:19:50 -0700 Peter Wemm schrieb: > Are you using pf and IPv6 by any chance? Since you mentioned the FreeBSD.org > domain, > DNSSEC and IPv6 triggers fragments. Just a thought. > > -- > Peter Wemm. pe...@wemm.org > > > > On 28 Jul 2014, at 6:50 am, O. Hartmann wrote: > > > > > > Since local_unbound update and the suggested update procedure as requested > > with TAG > > 20140719 the connection to the net hangs (DNS resolving). This is very > > often with the > > freebsd.org domain the case, while domestic domains rarely show this strange > > behaviour. > > > > The problem occurs on ALL CURRENT systems with updated unbound! > > > > Updates via svn also show those hangs (FBSD SVN server). > > > > This is nasty ... > > > > oh At the moment, it is a pain in the ass connecting to the net (not even FreeBSD related sites). The connect seems sporadic, then many times I get timeouts. What is this cuased by? What is the solution? signature.asc Description: PGP signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Replying to the top of the thread, but the text is actually reply to those people in the thread, who eager for import of new pf from OpenBSD. So, I claim that there is a vast and silent majority of people who simply use pf and do not want the hassle with broken pf.conf. I also claim that there is number of people who utilize pf at larger installations and they were very glad to see pf to scale on multiple CPUs and at least not to freeze the entire traffic for seconds during expiry run. And you claim that there is another large number of people, who want to run newest pf from OpenBSD on FreeBSD, and they do not care about syntax change problems. Unfortunately, we cannot compare our large numbers. Well, you can tell that your number is at least four times bigger than mine, but you will not provide details on how can we check that. :) What can we do in this situation? Thanks to the pfil(9) framework, we can have as much firewalls as we want. You can import new pf keeping the current version intact. There could be some minor problems on decision how to manage two different pfctls, and other utilities, but these are solvable. Let me restate. The FreeBSD version of pf IS NOT on your way of putting OpenBSD version of pf to FreeBSD. What IS your main obstacle in this task is the porting process itself. Try it. Fork FreeBSD in git, mercurial, or simply checkout subversion working directory, then: # cd sys/netpfil # mkdir openbsd-pf # cd openbsd-pf And start working. When you got a buildable and working version[*], post call for testing email to current@ and pf@. After several rounds of testing you will end up with something working. And if we see that the demand for second pf in FreeBSD is real, and you are willing to take maintainership of it, you will be welcome as committer and second pf will be welcome to the tree[**]. Any takers? === [*] Spoiler: usually by that time both FreeBSD tree and pf taken from OpenBSD would diverge and you would need to sync up :) [**] This is my personal opinion, not an official project statement, neither a core team member statement. I expect that there would be resistance against yet-another-packet-filter, that you would need to deal with. But if you got a working code, and you got a userbase of the code, then you have chances to overcome the resistance. And please don't start bikeshedding right now with no code at hand. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Yet another top reply to everyone. If anyone is interested in maintaining our FreeBSD version of pf and taking strategically right (my opinion!) steps in its life, here is a short TODO list: 1) Make Peter and FreeBSD cluster happy. Work on the IPv6 fragments handling. IMHO, the right way would be understanding the problem in its depth and writing code yourself taking ideas or code snippets from OpenBSD. Do not try blindly to replay all their commits over our tree. 2) Do massive API/ABI cleanup. I had started the process, but did less than 10% of it. We need to stop sharing structures between pf internals and ioctls. All kernel structures should live in pfvar.h, and all API in pf.h. The userland utilities should forget pfvar.h. This is huge task. No performance benefit, no new shiny features. But this is strategically correct, if we want a good support of pf in stable branches. Right now we can't merge any feature back due to breaking ABI. Even fixing bugs usually would require ABI breakage. Also, after completing the cleanup and header split further development would become easier. 3) Right now the hot point of contention is the pf_rules_rwlock. It is reader-vs-reader contention on the cache line. Eliminating it would bring a good performance gain on SMP. This would probably require an RCU-like management of rules. Fortunately, the rules in pf a changed in "one commit", unlike in ipfw rule by rule. 4) Convert all counters in pf to counter(9). That would be next point of contention once 3) is done. *) Cherry pick any feature you need from OpenBSD. This requires understanding code. Replaying commits won't work. P.S. I'm sorry for saying what should be done without doing that myself. I've spent quite a lot of time on pf, I was promised funding for that and later deceived. Real life changes like new job, children, etc. shifted my focus away from pf and I simply can't dedicate the amount of time to pf that I used before. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT/CFR] machine independent sf_bufs
On 29 Jul 2014, at 12:41, Gleb Smirnoff wrote:
> Hi!
>
> Sorry for top quoting, this is to annoy you :) I got zero
> replies on the below email during a week. I'd really appreciate
> testing on different platforms. Any takers?
I can try to test it on a raspberry pi, building a patched kernel
right now.
Best regards
Michael
>
> On Sat, Jul 19, 2014 at 10:27:25AM +0400, Gleb Smirnoff wrote:
> T> Hi!
> T>
> T> we've got a lot of common code in sys/*/*/vm_machdep.c wrt the
> T> sf_buf allocation. I have gathered it into kern/subr_sfbuf.c.
> T>
> T> o No MD code left in sys/*/*/vm_machdep.c.
> T> o The arches that have physical map have their implementation in
> T> machine/sf_buf.h
> T> o The arches that needs sf_bufs use subr_sfbuf.c, optionally having
> T> some stuff in machine/sf_buf.h
> T>
> T> I can test only i386. I'd be grateful for testing:
> T>
> T> arm
> T> mips
> T> mips64
> T> sparc64
> T> powerpc
> T> i386 XEN
> T>
> T> The test is a simple use of any applcation or test that uses sendfile(2).
> T> The box shouldn't crash :) of course, and after end of a test there
> T> should be no evidence of sf_buf leak (observed via netstat -m).
> T>
> T> --
> T> Totus tuus, Glebius.
>
> T> Index: sys/amd64/include/sf_buf.h
> T> ===
> T> --- sys/amd64/include/sf_buf.h (revision 268750)
> T> +++ sys/amd64/include/sf_buf.h (working copy)
> T> @@ -29,10 +29,6 @@
> T> #ifndef _MACHINE_SF_BUF_H_
> T> #define _MACHINE_SF_BUF_H_
> T>
> T> -#include
> T> -#include
> T> -#include
> T> -
> T> /*
> T> * On this machine, the only purpose for which sf_buf is used is to
> implement
> T> * an opaque pointer required by the machine-independent parts of the
> kernel.
> T> @@ -39,21 +35,7 @@
> T> * That pointer references the vm_page that is "mapped" by the sf_buf.
> The
> T> * actual mapping is provided by the direct virtual-to-physical mapping.
> T> */
> T> -struct sf_buf;
> T> -
> T> -static inline struct sf_buf *
> T> -sf_buf_alloc(struct vm_page *m, int pri)
> T> -{
> T> -
> T> - return ((struct sf_buf *)m);
> T> -}
> T> -
> T> -static inline void
> T> -sf_buf_free(struct sf_buf *sf)
> T> -{
> T> -}
> T> -
> T> -static __inline vm_offset_t
> T> +static inline vm_offset_t
> T> sf_buf_kva(struct sf_buf *sf)
> T> {
> T>
> T> @@ -60,11 +42,10 @@ sf_buf_kva(struct sf_buf *sf)
> T>return (PHYS_TO_DMAP(VM_PAGE_TO_PHYS((vm_page_t)sf)));
> T> }
> T>
> T> -static __inline vm_page_t
> T> +static inline vm_page_t
> T> sf_buf_page(struct sf_buf *sf)
> T> {
> T>
> T>return ((vm_page_t)sf);
> T> }
> T> -
> T> #endif /* !_MACHINE_SF_BUF_H_ */
> T> Index: sys/arm/arm/vm_machdep.c
> T> ===
> T> --- sys/arm/arm/vm_machdep.c (revision 268750)
> T> +++ sys/arm/arm/vm_machdep.c (working copy)
> T> @@ -50,7 +50,6 @@ __FBSDID("$FreeBSD$");
> T> #include
> T> #include
> T> #include
> T> -#include
> T> #include
> T> #include
> T> #include
> T> @@ -83,43 +82,7 @@ __FBSDID("$FreeBSD$");
> T> CTASSERT(sizeof(struct switchframe) == 24);
> T> CTASSERT(sizeof(struct trapframe) == 80);
> T>
> T> -#ifndef NSFBUFS
> T> -#define NSFBUFS (512 + maxusers * 16)
> T> -#endif
> T> -
> T> -static int nsfbufs;
> T> -static int nsfbufspeak;
> T> -static int nsfbufsused;
> T> -
> T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, 0,
> T> -"Maximum number of sendfile(2) sf_bufs available");
> T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, &nsfbufspeak, 0,
> T> -"Number of sendfile(2) sf_bufs at peak usage");
> T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, &nsfbufsused, 0,
> T> -"Number of sendfile(2) sf_bufs in use");
> T> -
> T> -static void sf_buf_init(void *arg);
> T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL);
> T> -
> T> -LIST_HEAD(sf_head, sf_buf);
> T> -
> T> /*
> T> - * A hash table of active sendfile(2) buffers
> T> - */
> T> -static struct sf_head *sf_buf_active;
> T> -static u_long sf_buf_hashmask;
> T> -
> T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask)
> T> -
> T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist;
> T> -static u_intsf_buf_alloc_want;
> T> -
> T> -/*
> T> - * A lock used to synchronize access to the hash table and free list
> T> - */
> T> -static struct mtx sf_buf_lock;
> T> -
> T> -/*
> T> * Finish a fork operation, with process p2 nearly set up.
> T> * Copy and update the pcb, set up the stack so that the child
> T> * ready to run and return to user mode.
> T> @@ -184,107 +147,7 @@ cpu_thread_swapout(struct thread *td)
> T> {
> T> }
> T>
> T> -/*
> T> - * Detatch mapped page and release resources back to the system.
> T> - */
> T> void
> T> -sf_buf_free(struct sf_buf *sf)
> T> -{
> T> -
> T> - mtx_lock(&sf_buf_lock);
> T> - sf->ref_count--;
> T> - if (sf->ref_count == 0) {
> T> -
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
In message , Kevin Oberman writes: > On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed wrote: > > > On 27/07/2014 4:43 AM, Cy Schubert wrote: > > > In message <53d395e4.1070...@fastmail.net>, Darren Reed writes: > > >> On 24/07/2014 1:42 AM, Cy Schubert wrote: > > > But, lack of ipv6 fragment processing still causes ongoing pain. > > That'= > > > s our=20 > > > #1 wish list item for the cluster. > > >>> Taking this discussion slightly sideways but touching on this thread a > > >>> little, each of our packet filters will need nat66 support too. Pf > > doesn't > > >>> support it for sure. I've been told that ipfw may and I suspect > > ipfilter > > >>> doesn't as it was on Darren's todo list from 2009. > > >> ipfiler 5 handles fragments for ipv6. > > > Switching gears and leaving the discussion of ipv6 fragments to mention > > > nat66. A lot of people have been talking about nat66. I could be wrong > > but > > > I don't think it can handle nat66. I need to do some testing to verify > > > this. I remember reading on sourceforge that it was on your todo list. It > > > doesn't look like it was checked off as being completed. > > > > IPFilter 5 does IPv6 NAT. > > > > With the import of 5.1.2, map, rdr and rewrite rules will all work with > > IPv6 addresses. > > > > NAT66 is a specific implementation of IPv6 NAT behaviour. > > > > Cheers, > > Darren > > > > And all IPv6 NAT is evil and should be cast into (demonic residence of your > choosing) on sight! That I don't disagree with, IPv6 NAT makes no logical sense. Having said that I've received emails asking about NAT66 specifically. It is on people's minds. > > NAT on IPv6 serves no useful purpose at all. It only serves to complicate > things and make clueless security officers happy. It adds zero security. It > is a great example of people who assume that NAT is a security feature in > IPv4 (it's not) so it should also be in IPv6. Agreed. People think NAT is a security feature (and those same people tout the "security" of reverse proxies too). It's a checkbox item. > > The problem is that this meme is so pervasive that even when people > understand that it is bad, they still insist on it because there will be an > unchecked box on the security checklist for "All systems not pubic servers > are in RFC1918 space? -- YES NO". The checklist item should be (usually) > "All systems behind a stateful firewall with an appropriate rule set? -- > YES NO" as it is a stateful firewall (which is mandatory for NAT that > provides all of the security. Exactly! That's pretty much what people who know better are saying. > > I say "usually" because the major research lab where I worked ran without a > firewall (and probably still does) and little, if any, NAT. It was tested > regularly by red teams hired by the feds and they never were able to > penetrate anything due to a very aggressive IDS/IPS system, but most people > and companies should NOT go this route. I have IPv6 at home (Comcast) and > my router runs a stateful firewall with a rule set functionally the same as > that used for IPv4 and that provides the protection needed. Not part of this discussion: I think you need both. Firewalls and IPS with IDS. OTOH using NAT as a means of securing a network is illogical. I worked at one place where they would NAT already NATted packets, themselves having previously been processed by previous NAT, all for the sake of "security" only terribly broke the network to the point there were issues to numerous to discuss in a quick reply here. > > So putting support for NAT66 or any IPv6 NAT into a firewall is just making > things worse. Please don't do it! -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
me wrote: we are talking about NAT64 (IPv6-only datacenter's path to a legacy world), and NPT66 (prefix transalation). I doubt anyone had a traditional NAT in mind. Kevin Oberman wrote: No, all of the messages in the thread are specific about NAT66, not NPT66. NPT66 may have real value. I hate it, but it may well be better than alternatives. [...] Cy Schubert wrote: That I don't disagree with, IPv6 NAT makes no logical sense. Having said that I've received emails asking about NAT66 specifically. It is on people's minds. My impression is that often the term NAT66 is used indiscriminately, even when NPT66 (static prefix translation) is meant. Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Tue, Jul 29, 2014 at 7:48 AM, Mark Martinec wrote: > me wrote: > >> we are talking about NAT64 (IPv6-only datacenter's path to a legacy >> world), >> and NPT66 (prefix transalation). I doubt anyone had a traditional NAT in >> mind. >> > > Kevin Oberman wrote: > >> No, all of the messages in the thread are specific about NAT66, not NPT66. >> NPT66 may have real value. I hate it, but it may well be better than >> alternatives. [...] >> > > Cy Schubert wrote: > >> That I don't disagree with, IPv6 NAT makes no logical sense. Having said >> that I've received emails asking about NAT66 specifically. It is on >> people's minds. >> > > My impression is that often the term NAT66 is used indiscriminately, > even when NPT66 (static prefix translation) is meant. > > Mark > > I would hope that is not the case. While NAT66 is "well known" and has been a topic of discussion for years, NPT66 is relatively new. It does share many concepts with NAT66 (and, most likely implementations also share code), but does not require any state, making it vastly less complex and no longer breaks point to point networking. The names look similar, which may result in unfortunate confusion, but NPT66 may be the bast solution to a real problem and it does not create the issues of NAT66. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 29 July 2014 09:54, Kevin Oberman wrote: > On Tue, Jul 29, 2014 at 7:48 AM, Mark Martinec > wrote: > >> me wrote: >> >>> we are talking about NAT64 (IPv6-only datacenter's path to a legacy >>> world), >>> and NPT66 (prefix transalation). I doubt anyone had a traditional NAT in >>> mind. >>> >> >> Kevin Oberman wrote: >> >>> No, all of the messages in the thread are specific about NAT66, not NPT66. >>> NPT66 may have real value. I hate it, but it may well be better than >>> alternatives. [...] >>> >> >> Cy Schubert wrote: >> >>> That I don't disagree with, IPv6 NAT makes no logical sense. Having said >>> that I've received emails asking about NAT66 specifically. It is on >>> people's minds. >>> >> >> My impression is that often the term NAT66 is used indiscriminately, >> even when NPT66 (static prefix translation) is meant. >> >> Mark >> >> > I would hope that is not the case. While NAT66 is "well known" and has been > a topic of discussion for years, NPT66 is relatively new. It does share > many concepts with NAT66 (and, most likely implementations also share > code), but does not require any state, making it vastly less complex and no > longer breaks point to point networking. The names look similar, which may > result in unfortunate confusion, but NPT66 may be the bast solution to a > real problem and it does not create the issues of NAT66. Course it will. All those bad protocols that embed IP addresses in them to connect to. Or wait, is everything written these days mindful of NAT/NPT and tries desperately to work around it? Hm... -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT/CFR] machine independent sf_bufs
On 29 Jul 2014, at 12:41, Gleb Smirnoff wrote:
> Hi!
>
> Sorry for top quoting, this is to annoy you :) I got zero
> replies on the below email during a week. I'd really appreciate
> testing on different platforms. Any takers?
OK, it works on an Raspberry pi running r269231 with your patch.
The only suspicious thing I observed was that the number of
'requests for I/O initiated by sendfile' in netstat -m doesn't
always increase. I would expect that. However, I'm not sure if
this is ARM related (I would not think so) or is related to your
patch at all.
Let me know if you need more information.
Best regards
Michael
>
> On Sat, Jul 19, 2014 at 10:27:25AM +0400, Gleb Smirnoff wrote:
> T> Hi!
> T>
> T> we've got a lot of common code in sys/*/*/vm_machdep.c wrt the
> T> sf_buf allocation. I have gathered it into kern/subr_sfbuf.c.
> T>
> T> o No MD code left in sys/*/*/vm_machdep.c.
> T> o The arches that have physical map have their implementation in
> T> machine/sf_buf.h
> T> o The arches that needs sf_bufs use subr_sfbuf.c, optionally having
> T> some stuff in machine/sf_buf.h
> T>
> T> I can test only i386. I'd be grateful for testing:
> T>
> T> arm
> T> mips
> T> mips64
> T> sparc64
> T> powerpc
> T> i386 XEN
> T>
> T> The test is a simple use of any applcation or test that uses sendfile(2).
> T> The box shouldn't crash :) of course, and after end of a test there
> T> should be no evidence of sf_buf leak (observed via netstat -m).
> T>
> T> --
> T> Totus tuus, Glebius.
>
> T> Index: sys/amd64/include/sf_buf.h
> T> ===
> T> --- sys/amd64/include/sf_buf.h (revision 268750)
> T> +++ sys/amd64/include/sf_buf.h (working copy)
> T> @@ -29,10 +29,6 @@
> T> #ifndef _MACHINE_SF_BUF_H_
> T> #define _MACHINE_SF_BUF_H_
> T>
> T> -#include
> T> -#include
> T> -#include
> T> -
> T> /*
> T> * On this machine, the only purpose for which sf_buf is used is to
> implement
> T> * an opaque pointer required by the machine-independent parts of the
> kernel.
> T> @@ -39,21 +35,7 @@
> T> * That pointer references the vm_page that is "mapped" by the sf_buf.
> The
> T> * actual mapping is provided by the direct virtual-to-physical mapping.
> T> */
> T> -struct sf_buf;
> T> -
> T> -static inline struct sf_buf *
> T> -sf_buf_alloc(struct vm_page *m, int pri)
> T> -{
> T> -
> T> - return ((struct sf_buf *)m);
> T> -}
> T> -
> T> -static inline void
> T> -sf_buf_free(struct sf_buf *sf)
> T> -{
> T> -}
> T> -
> T> -static __inline vm_offset_t
> T> +static inline vm_offset_t
> T> sf_buf_kva(struct sf_buf *sf)
> T> {
> T>
> T> @@ -60,11 +42,10 @@ sf_buf_kva(struct sf_buf *sf)
> T>return (PHYS_TO_DMAP(VM_PAGE_TO_PHYS((vm_page_t)sf)));
> T> }
> T>
> T> -static __inline vm_page_t
> T> +static inline vm_page_t
> T> sf_buf_page(struct sf_buf *sf)
> T> {
> T>
> T>return ((vm_page_t)sf);
> T> }
> T> -
> T> #endif /* !_MACHINE_SF_BUF_H_ */
> T> Index: sys/arm/arm/vm_machdep.c
> T> ===
> T> --- sys/arm/arm/vm_machdep.c (revision 268750)
> T> +++ sys/arm/arm/vm_machdep.c (working copy)
> T> @@ -50,7 +50,6 @@ __FBSDID("$FreeBSD$");
> T> #include
> T> #include
> T> #include
> T> -#include
> T> #include
> T> #include
> T> #include
> T> @@ -83,43 +82,7 @@ __FBSDID("$FreeBSD$");
> T> CTASSERT(sizeof(struct switchframe) == 24);
> T> CTASSERT(sizeof(struct trapframe) == 80);
> T>
> T> -#ifndef NSFBUFS
> T> -#define NSFBUFS (512 + maxusers * 16)
> T> -#endif
> T> -
> T> -static int nsfbufs;
> T> -static int nsfbufspeak;
> T> -static int nsfbufsused;
> T> -
> T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, 0,
> T> -"Maximum number of sendfile(2) sf_bufs available");
> T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, &nsfbufspeak, 0,
> T> -"Number of sendfile(2) sf_bufs at peak usage");
> T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, &nsfbufsused, 0,
> T> -"Number of sendfile(2) sf_bufs in use");
> T> -
> T> -static void sf_buf_init(void *arg);
> T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL);
> T> -
> T> -LIST_HEAD(sf_head, sf_buf);
> T> -
> T> /*
> T> - * A hash table of active sendfile(2) buffers
> T> - */
> T> -static struct sf_head *sf_buf_active;
> T> -static u_long sf_buf_hashmask;
> T> -
> T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask)
> T> -
> T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist;
> T> -static u_intsf_buf_alloc_want;
> T> -
> T> -/*
> T> - * A lock used to synchronize access to the hash table and free list
> T> - */
> T> -static struct mtx sf_buf_lock;
> T> -
> T> -/*
> T> * Finish a fork operation, with process p2 nearly set up.
> T> * Copy and update the pcb, set up the stack so that the child
> T> * ready to run and return to user mode.
> T> @@ -184,107 +147,7 @@ cpu_thread_swapou
Re: [CFT/CFR] machine independent sf_bufs
On Tue, Jul 29, 2014 at 07:29:43PM +0200, Michael Tuexen wrote: M> > Sorry for top quoting, this is to annoy you :) I got zero M> > replies on the below email during a week. I'd really appreciate M> > testing on different platforms. Any takers? M> OK, it works on an Raspberry pi running r269231 with your patch. M> The only suspicious thing I observed was that the number of M> 'requests for I/O initiated by sendfile' in netstat -m doesn't M> always increase. I would expect that. However, I'm not sure if M> this is ARM related (I would not think so) or is related to your M> patch at all. Thanks a lot, Michael! The observation on number of I/Os is absolutely okay, since VM cashes pages. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT/CFR] machine independent sf_bufs
On 29 Jul 2014, at 20:00, Gleb Smirnoff wrote: > On Tue, Jul 29, 2014 at 07:29:43PM +0200, Michael Tuexen wrote: > M> > Sorry for top quoting, this is to annoy you :) I got zero > M> > replies on the below email during a week. I'd really appreciate > M> > testing on different platforms. Any takers? > M> OK, it works on an Raspberry pi running r269231 with your patch. > M> The only suspicious thing I observed was that the number of > M> 'requests for I/O initiated by sendfile' in netstat -m doesn't > M> always increase. I would expect that. However, I'm not sure if > M> this is ARM related (I would not think so) or is related to your > M> patch at all. > > Thanks a lot, Michael! > > The observation on number of I/Os is absolutely okay, since VM > cashes pages. Ahh, OK, makes sense. I was transmitting the same file several times... Best regards Michael > > > -- > Totus tuus, Glebius. > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
zdb: specify object_id for dataset of the zpool name
If I do "zdb -dd mypool", It shows me the data from entire pool and all its datasets, when in fact I only want the list from the mypool dataset. The dataset ID is 21, so is there any syntax like: # zdb -dd ID=21 I'm not trying to filter the output - I'm trying to dozdb -d mypool object_id "", which does not work when using the zpool name because zdb looks at the pool-level data and returns error (no such object). - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/zdb-specify-object-id-for-dataset-of-the-zpool-name-tp5933179.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT/CFR] machine independent sf_bufs
On Tue, Jul 29, 2014 at 10:00:43PM +0400, Gleb Smirnoff wrote: > > On Tue, Jul 29, 2014 at 07:29:43PM +0200, Michael Tuexen wrote: > M> > Sorry for top quoting, this is to annoy you :) I got zero > M> > replies on the below email during a week. I'd really appreciate > M> > testing on different platforms. Any takers? > M> OK, it works on an Raspberry pi running r269231 with your patch. > M> The only suspicious thing I observed was that the number of > M> 'requests for I/O initiated by sendfile' in netstat -m doesn't > M> always increase. I would expect that. However, I'm not sure if > M> this is ARM related (I would not think so) or is related to your > M> patch at all. > > Thanks a lot, Michael! > > The observation on number of I/Os is absolutely okay, since VM > cashes pages. Hi Gleb, I tested your patch on FreeBSD/arm (OpenBlocks AX3), it seems to be working fine. > -- > Totus tuus, Glebius. Kevin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT/CFR] machine independent sf_bufs
On Wed, Jul 30, 2014 at 01:34:46PM +0800, Kevin Lo wrote: K> I tested your patch on FreeBSD/arm (OpenBlocks AX3), it seems to be working K> fine. Thanks a lot, Kevin! -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
