What's new in 2.1?
-
Maybe I'm blind, but is there a list of what's new in 2.1?
I understand from reading around here a bit, that it's a different version of BSD, and that there's an emphasis on IPv6. Is that it? (Not trying to imply it's not enough, I just would like to know…)
Maybe a short list of what's new and needs testing in particular would be useful up in the sticky threads section, unless i just missed such a list elsewhere. (If so, pointers appreciated). -
FreeBSD 8.3 and all the things that brings in terms of hardware support. I'm having to run it due to support for the RealTek 8111e for example.
-
Mostly it's IPv6 and the newer base OS, but there are some other things that have been updated. Switched from Prototype to jQuery, a lot more gettext strings added/fixed, tons of bugs fixed, also multi-instance CP so you can have different portal pages for different portal "zones" which can include one or more interfaces.
This isn't 100% complete since not all things had tickets and not all tickets were marked as for 2.1, but it's a good rough idea:
http://redmine.pfsense.org/versions/5 -
Just to add a point about IPv6, it's not "just" IPv6, there is a ton of work involved in adding support for IPv6.
This spreadsheet goes over the majority of the points, and where the IPv6 progress is:
https://docs.google.com/spreadsheet/ccc?key=0AojFUXcbH0ROdHlKV2F5SENULWk2NTVvQTBtQ2M0dEE#gid=0
And it's not just in our GUI, we've had to fix several things in the OS and supporting programs because they either did not support a feature properly (or the way we needed it) or things were broken in some way. Still have a bit left to go, as you can see.
-
Just to add a point about IPv6, it's not "just" IPv6, there is a ton of work involved in adding support for IPv6.
Oh, I'm fully aware of that…. That's why I wrote
(Not trying to imply it's not enough, I just would like to know…)
So the "just" was just referring to the length of the new feature list, not to the amount of work involved.
I know the problem, like: "I like this web site, could just "just" add a button here that does….?" (and that button is about ten times more work than the web site in the first place).IPv6 is anyway a nightmare, because everyone pushed it out as long as they could (OS vendors, ISPs, etc.) that I expect quite a few hidden bugs and tons of exploits as IPv6 gets battle-hardened. So IPv6 in a firewall is extra trouble.
-
Not sure I'd say it's extra trouble. There may be some areas that don't work quite as well as v4 yet (see the sheet) but pf will still lock things down just as well.
The real problem is going to be getting everyone out of the "nat as a firewall mechanism" mentality where people believe that their internal networks are "protected" by NAT, since that won't really exist in the same way on IPv6. If you add a "pass all" rule for IPv6 on your WAN, you aren't just exposing the firewall, you're exposing everything.
-
One more thing: are 2.0 packages supposed to "just work" or is there some place that tracks which packages are adapted to 2.1 and/or are known to work?
Yes, NAT and IPv6 :(
I was always hoping they'd do a standard where IPv4 Addresses would map in the IPv6 address space in such a way that they would have a prefix, and then a 16-bit postfix, which could be arbitrary. This, if I have an IPv4 host, its address would be the IPv6 map prefix followed by its IPv4 address, followed by arbitrary 16 bits, which are ignored.
If I have an IPv4 web server or NAT gateway, there would then be for each such host or server an entire class-B net's worth of virtual web servers or private IPv4 addresses that could be mapped one to one into the IPv6 address space.
Further, there would have been no need for anyone to apply for an IPv6 address space, anyone who already has an IPv4 net assigned to them would automatically have that corresponding IPv6 space without further ado.
That sort of thing could have made things much easier in terms of maintenance and transition in mixed nets. -
One more thing: are 2.0 packages supposed to "just work" or is there some place that tracks which packages are adapted to 2.1 and/or are known to work?
Some will work, some won't. We are trying to switch to PBI-based packages. Packages that don't have a PBI spec in the package xml may just work as-is.
-
Cool. I assume that includes support for PBP files? That would make upgrades a lot faster. One of the few drags with pfSense so far is that, particularly if doing the snapshots thing, even minor upgrades can take forever, between downloads and then all the packages getting reinstalled, etc.
-
I don't know on that - I haven't done much work in the new PBI package system yet so I have no idea what all it includes.
-
IPv6 is anyway a nightmare, because everyone pushed it out as long as they could (OS vendors, ISPs, etc.) that I expect quite a few hidden bugs and tons of exploits as IPv6 gets battle-hardened. So IPv6 in a firewall is extra trouble.
Not sure if I completely agree with "everyone". FreeBSD (the OS basis for pfSense) has had IPv6 support in its base system for over ten years now, and this support originally came from the KAME IPv6 stack, which is one of the oldest production IPv6 stacks on the net. Much of the FreeBSD Project's infrastructure has been dual-stack for at least five years. One of my ISPs offered IPv6 to its customers starting around 2003.
So while it's probably true that a lot of people ignored IPv6 for much longer than they should have, this isn't universally true.
Bruce.
PS. The FreeBSD examples I cited above are not intended to detract from any other open-source project. It's just that those are the cases with which I happen to have personal experience.
-
IPv6 is anyway a nightmare, because everyone pushed it out as long as they could (OS vendors, ISPs, etc.) that I expect quite a few hidden bugs and tons of exploits as IPv6 gets battle-hardened. So IPv6 in a firewall is extra trouble.
Not sure if I completely agree with "everyone". FreeBSD (the OS basis for pfSense) has had IPv6 support in its base system for over ten years now, and this support originally came from the KAME IPv6 stack, which is one of the oldest production IPv6 stacks on the net. Much of the FreeBSD Project's infrastructure has been dual-stack for at least five years. One of my ISPs offered IPv6 to its customers starting around 2003.
I'm aware of that, but my point is a different one. e.g. Mac OS X has been around for a while, and while it's in many respects indeed more secure than say Windows, the fact that there were close to zero exploits was less a function of it being more secure, than of it not being widely enough used to be an attractive target. Now, that it's getting more and more wide-spread, one hears more and more about exploits, and that even though OS X is getting more secure than it used to be. So the security of a product is only one part, the other is whether it's commonly used enough to make an attractive target.
I believe that there will be a similar dynamic with IPv6: right now there are just not enough attractive targets for IPv6, and whatever targets there are pretty much all run dual-stack connectivity, so they might as well be attacked over the known IPv4 access.
The expertise on IPv6 is much more thinly spread, on both sides of the cat & mouse game, than IPv4.
So in that sense even the old IPv6 stacks in BSD haven't seen the kind of attention from hackers as IPv4 has seen over the years, and so I expect vulnerabilities of which currently nobody even thinks about to rear their ugly heads as IPv6 becomes common and starts to become the norm.
I bet, there will be exploits that are even based on things like people not being familiar with the IPv6 address format, where people get duped into entering false information, etc. Heck, I might be a good target, because IPv6 address to me still look strange… Got catching up to do, I'm sure I'm not the only one out there.But that's just my guessing, based on historical patterns, so I may be totally off...
-
I dont know….for me its only a public IP address problem....
I think IPv4 would exist for many years on internal networks and be translated to IPv6 when passing through a firewall or router.
-
I believe that there will be a similar dynamic with IPv6: right now there are just not enough attractive targets for IPv6, and whatever targets there are pretty much all run dual-stack connectivity, so they might as well be attacked over the known IPv4 access.
The expertise on IPv6 is much more thinly spread, on both sides of the cat & mouse game, than IPv4.I'd agree with most of that. Past experience shows that those operating on the black hat side of things are able to move much faster than those trying to stop them.
I suspect that right now there are large number of juicy misconfigured IPv6 targets out there. There have got to be plenty of people running IPv6 who don't even know they are.Steve
-
IPv6 is anyway a nightmare, because everyone pushed it out as long as they could (OS vendors, ISPs, etc.) that I expect quite a few hidden bugs and tons of exploits as IPv6 gets battle-hardened. So IPv6 in a firewall is extra trouble.
Not sure if I completely agree with "everyone". FreeBSD (the OS basis for pfSense) has had IPv6 support in its base system for over ten years now, and this support originally came from the KAME IPv6 stack, which is one of the oldest production IPv6 stacks on the net. Much of the FreeBSD Project's infrastructure has been dual-stack for at least five years. One of my ISPs offered IPv6 to its customers starting around 2003.
I'm aware of that, but my point is a different one. e.g. Mac OS X has been around for a while, and while it's in many respects indeed more secure than say Windows, the fact that there were close to zero exploits was less a function of it being more secure, than of it not being widely enough used to be an attractive target. Now, that it's getting more and more wide-spread, one hears more and more about exploits, and that even though OS X is getting more secure than it used to be. So the security of a product is only one part, the other is whether it's commonly used enough to make an attractive target.
So that's true, but I just didn't want you to forget that there have been developers, admins, and users deploying and running IPv6 for a number of years now, and some of us actually have real operational experience with it. We have learned some things along the way (such as the "type 0 routing header" issue). I appreciate your comparison with MacOS and visibility.
The fact that there are some different attacks against IPv6-connected targets is a reason why having IPv6 support in your firewall is actually a good thing (I'm thinking of your comment along the lines of "IPv6 in a firewall is extra trouble"), assuming you have IPv6 connectivity or think you might be getting it. It's useful to mitigate against some of these attacks (note I didn't say "prevent", just as I wouldn't say that an IPv4 firewall makes you completely safe from IPv4-based attacks). As I'm sure you know there are quite a few attacks against users ("click on the link in this email!") that are independent of what layer 3 network protocol you have.
Bruce.
-
Thats why you need L7 firewall as a complement to you normal frontend!
-
Thats why you need L7 firewall as a complement to you normal frontend!
Maybe so. Anyway, we probably dragged this conversation way too far afield from what new features there are in pfSense 2.1. :-)
(To sort of bring things back on track, I upgraded to a snapshot from a couple days ago…I very much like the change from openntp to the stock ntp.org ntpd daemon, at least I can understand what it's doing now, especially with the new status page...thanks developers for making that switch.)
Bruce.
-
I'm happy with the change to ntpd also (and I'm the one that did it :-) but I did hit some issues along the way. OpenNTPD had been causing us more and more trouble lately, and this way we not only get a good status output, but also it's IPv6-ready. (There may be a new version of open that is as well, but given the choice I'd rather go the way we did).
Still planning on adding support for the new per-interface listen/binding options that are in the ntpd from ports, haven't gotten to that yet. Also the status page uses ntpq now, but I was toying with the idea of using ntpdc instead.
They seem to provide different status code for the same peers at the same time, though. I need to read more on ntpdc to find out why.
-
I'm happy with the change to ntpd also (and I'm the one that did it :-) but I did hit some issues along the way. OpenNTPD had been causing us more and more trouble lately, and this way we not only get a good status output, but also it's IPv6-ready. (There may be a new version of open that is as well, but given the choice I'd rather go the way we did).
Thanks Jim. :-)
And yes the NTP-over-IPv6 is nice too…one of my timeservers is dual-stack and that works just great. I also liked the way you interpreted the various ntpdc status characters in the NTP status display for a more user-friendly interface...I wish the NTP status display in my product at ${REALJOB} looked this good.
Bruce.
-
I'm still trying to poke at ntpdc a little and figure out why the status is different. Still using ntpq now, and it's tally codes don't line up 100% with ntpdc's peer modes.
For instance:
From ntpdc(8):
The character in the left margin indicates the mode this peer entry is operating in. A `+' denotes symmetric active, a `-' indicates symmetric passive, a `=' means the remote server is being polled in client mode, a `^' indicates that the server is broadcasting to this address, a `~' denotes that the remote peer is sending broadcasts and a `*' marks the peer the server is cur- rently synchronizing to.And from ntpq(8):
Tally Codes The character in the left margin in the `peers' billboard, called the tally code, shows the fate of each association in the clock selection process. Following is a list of these characters, the pigeon used in the rv command, and a short explanation of the condition revealed. space (reject) The peer is discarded as unreachable, synchronized to this server (synch loop) or outrageous synchronization distance. x (falsetick) The peer is discarded by the intersection algorithm as a falseticker. . (excess) The peer is discarded as not among the first ten peers sorted by synchronization distance and so is probably a poor can- didate for further consideration. - (outlyer) The peer is discarded by the clustering algorithm as an outlyer. + (candidat) The peer is a survivor and a candidate for the combin- ing algorithm. # (selected) The peer is a survivor, but not among the first six peers sorted by synchronization distance. If the association is ephemeral, it may be demobilized to conserve resources. * (sys.peer) The peer has been declared the system peer and lends its variables to the system variables. o (pps.peer) The peer has been declared the system peer and lends its variables to the system variables. However, the actual sys- tem synchronization is derived from a pulse-per-second (PPS) sig- nal, either indirectly via the PPS reference clock driver or directly via kernel interface.So while the ntpq codes give more accurate information on some areas, ntpdc seems to give more in others. I think we'll stick with ntpq for now, though I do need to see a little more about how both of them give info about clients syncing from this ntpd as a server.
…and now we're straying properly off topic. :-)
