Re: Future of pf / firewall in FreeBSD ? - does it have one ?
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 ___ 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"
local_unbound: since update sporadic hangs in connections
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 signature.asc Description: PGP signature
net/openldap24-server: lstat(/usr/ports/net/openldap24-server/work/stage/usr/local/libexec/openldap/smbk5pwd.so.0.0.0):
Updating of port net/openldap24-server fails grandios with the following error: ===> Installing for openldap-sasl-server-2.4.39_2 ===> Registering installation for openldap-sasl-server-2.4.39_2 pkg-static: lstat(/usr/ports/net/openldap24-server/work/stage/usr/local/libexec/openldap/pw-sha2.so.0.0.0): No such file or directory pkg-static: lstat(/usr/ports/net/openldap24-server/work/stage/usr/local/libexec/openldap/smbk5pwd.so.0.0.0): No such file or directory *** Error code 74 Great. The OS is FreeBSD 11.0-CURRENT #0 r269157: Sun Jul 27 22:57:48 CEST 2014 signature.asc Description: PGP signature
Re: local_unbound: since update sporadic hangs in connections
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 ___ 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: 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 The gateway uses pf, IPv6 is not used, but configured. The gateway is CURRENT, as well as the boxes inside my LAN (they use ipfw2, also IPv6 not used, but configured and a capable kernel). signature.asc Description: PGP signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
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! 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. 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. 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. So putting support for NAT66 or any IPv6 NAT into a firewall is just making things worse. Please don't do it! -- 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 Mon, Jul 28, 2014 at 2:41 AM, Darren Reed wrote: [...] 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. 2014-07-29 00: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. 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. 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. So putting support for NAT66 or any IPv6 NAT into a firewall is just making things worse. Please don't do it! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com You are missing the point, 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. Consider a small site with uplinks to two service providers: it can use ULA internally and translate prefix on each uplink. Please see these short blogs: - To ULA or not to ULA, That’s the Question http://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question.html - I Say ULA, You Hear NAT http://blog.ipspace.net/2014/01/i-say-ula-you-hear-nat.html - PA, PI or ULA IPv6 Address Space? It depends http://blog.ipspace.net/2014/01/pa-pi-or-ula-ipv6-address-space-it.html - Source IPv6 Address Selection Saves the Day http://blog.ipspace.net/2014/01/source-ipv6-address-selection-saves-day.html 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 Mon, Jul 28, 2014 at 4:21 PM, Mark Martinec wrote: > On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed wrote: >> >>> [...] >>> >>> 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. >>> >> > 2014-07-29 00: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. >> >> 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. >> >> 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. >> >> So putting support for NAT66 or any IPv6 NAT into a firewall is just >> making >> things worse. Please don't do it! >> -- >> R. Kevin Oberman, Network Engineer, Retired >> E-mail: rkober...@gmail.com >> > > You are missing the point, 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. > > Consider a small site with uplinks to two service providers: it can use ULA > internally and translate prefix on each uplink. > > Please see these short blogs: > > - To ULA or not to ULA, That’s the Question > http://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question.html > > - I Say ULA, You Hear NAT > http://blog.ipspace.net/2014/01/i-say-ula-you-hear-nat.html > > - PA, PI or ULA IPv6 Address Space? It depends > http://blog.ipspace.net/2014/01/pa-pi-or-ula-ipv6-address-space-it.html > > - Source IPv6 Address Selection Saves the Day > http://blog.ipspace.net/2014/01/source-ipv6-address- > selection-saves-day.html > > > Mark > Mark, 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. It addresses an issue I have had with many of the IPv6 purists. I do think some of the arguments for it are over-stated. Getting a /48 is trivial, but getting it routed is not, so there is a real issue, but it remains unclear how bit the issue really is. For most users, multi-homing is fine, but not for servers. But smaller companies often farm out their servers, so it's not an issue for them. The one really significant issue I accept as real is the expansion of the routing tables. While the IPv6 table is still fairly small (~17k) , it is growing and has the potential to exceed the size of the IPv4 table (>500K) which continues to grow due to deaggregation. For those not dealing with backbone BGP, the issues include handling large numbers of prefixes and the stability of routing tables (both RIBs and FIBs) with all of the churn . Since I have retired, I have not been involved in IPv6 implementation or technical discussion, but I started dealing with it back in the 1990s and, until I retired in 2011 I had the first computer (a DEC Alpha) that had an ARIN assigned IPv6 address sitting under my desk, hershey.es.net. (No, it was no longer in use.) I also opposed ULA. While I understood the arguments in its favor, I have still do not agree with them. I think ULA is simply a bad idea, but it is there and we will have to deal with it... forever. -- 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"
