pfSense 2.5 Release Date News
-
@PhlMike said in pfSense 2.5 Release Date News:
They have been hammering out code all week from what I can see, but not 70 before COB on Friday.
Note that the number of issues open against 2.4.5 are about 90% (60/68) issues waiting for testing and confirmation of fixes already in place. There are only 4 actual issues remaining to work on, and four release-related tasks (updating release notes, docs, etc). I still doubt it will happen before Christmas, but it's certainly not going to be months.
Edit: As always, if you want to see a release happen faster, then help test issues in the feedback state:
-
I have two rules I strictly follow in these situations. First keeps me from being constantly disappointed or agitated. The second keeps me from appearing privileged.
- If a product doesn't do something now it never will.
- If you jumped on the bus through the back door don't complain about the driver.
-
@jimp said in pfSense 2.5 Release Date News:
@PhlMike said in pfSense 2.5 Release Date News:
They have been hammering out code all week from what I can see, but not 70 before COB on Friday.
Note that the number of issues open against 2.4.5 are about 90% (60/68) issues waiting for testing and confirmation of fixes already in place. There are only 4 actual issues remaining to work on, and four release-related tasks (updating release notes, docs, etc). I still doubt it will happen before Christmas, but it's certainly not going to be months.
Edit: As always, if you want to see a release happen faster, then help test issues in the feedback state:
More than 3 months xD for 2.4.5
So what is the expected date for 2.5?
-
There is no ETA for 2.5.0.
-
@l0rdraiden To get an idea, this is how I determined an estimate for myself...I estimate that FreeBSD 12.1 will be stable somewhere around August where pfSense include it September and 2.5RC October...final release December. If it's earlier than that, alleluia...if it’s later, then I readjust my expectation. I won't have to ask anyone when it's releasing...I already have an idea. Meanwhile, I am enjoying it.
-
I would say 16 months. Looks like in the past 13 months they closed 159 issues, with another 164 to go so add an extra month for those, plus adding two-extra months because I was off two months the last time.
So May 2021. TNSR should be at version 100 by then, though...
But, No need to beat a dead horse. They refused to listen thus far and vehemently oppose our viewpoint. They did a partner survey back in February. I was talking to the other larger netgate parters, we all said the same exact thing. What we hear back? crickets....
-
Even though TNSR is basically Cisco and I know it well from decades of use, until it has OpenVPN (Or Ahem Wireguard, lol), Snort, and the pfSense front end I'm sticking with pfSense. The pfSense front end has totally spoiled me from CLI.
Netgate, you make that happen with TNSR and I'll gladly buy it. :)
-
@Zermus I concur - I have zero need for TNSR, everything I do maxes out at 10 Gb/s and I only run 1 Gb/s internet lines.
I want:
- A real central management platform that I can get fora reasonable price (< $1/firewall/month for 500+ firewalls and/or host myself that can handle 1,000 firewalls+ at under $500/month.
- A web interface on the firewall, preferably HTML5 and some nice python action in the back.
- SSLVPN, Site2Site VPN (not married to IPSEC, SSL S2S will work), pfBlockerNG and Suricata
- Updates on a 3-6 month schedule
- A wall-mount for the SG-3100.
-
Regarding pfSense 3.0, has the roadmap changed since this Reddit post?
https://www.reddit.com/r/networking/comments/6upchy/can_a_bsd_system_replicate_the_performance_of/
I'm doing some googling about potential performance bump in pfsense 3.0 and there seems to be quite lot of noise: VPP, DPDK, netmap or moving to Linux base. Would that basically mean pfsense is gonna be TNSR Lite?
Netgate seems to be very tight-lipped about roadmap, but they have every right to do so.
-
@nva Interesting read, indeed ... really wish pfSense had not drop the original plans for v2.5. Thank you for sharing!
-
@NollipfSense I can understand why they dropped a lot of things for 2.5.0 - particularly the RESETCONF API and AES-NI requirement.
The rebase to FreeBSD 12.x is a pretty big deal. Any software rebase is a big deal. Just look at Ubiquti's EdgeRouters going from 1.x to 2.x rebasing Ubuntu versions. It's a similar thing.
Gall's Law, states that, "A complex system that works is invariably found to have evolved from a simple system that worked". So with pfSense you have a complex system. Change the underpinnings with a rebase is going from "complex system > complex system" and basically flies in the face of Gall's Law. This is why it takes a long time.
You basically have to strip the complexity back, test a massive amount of features, and build the complexity back in. So it's no wonder a lot of "new feature" things were stripped out.
I would really love to see the RESTCONF API (and any reliance on AES-NI is fine), after 2.5.x series is out in the wild and solid. Perhaps a 2.6 feature.
-
Redmine has the 2.5.0 currently at 90%, which is encouraging.
https://redmine.pfsense.org/projects/pfsense/roadmap -
Yeah it's amazing how fast 2.5 is coming, but I think they've been working on it on the back burner over the last few 2.4 releases.
-
I predicted 16 months in April with 3 month padding. They still have 13 features, 4 To-Dos plus the 66 bugs. However, in the past 6 months they have exhibited a 10.6% increase in productivity.
If that sustains, we could see a release in May/June 2021. Otherwise I still think with the Holidays around the corner that August 2021 is more likely.
What would the Vegas odds be on that? I don't gamble but I used to use insane amounts of math to cheat at fantasy football.
-
It'll be out soon. Not that long.
-
now i'm happy, this is good news !
-
@jimp said in pfSense 2.5 Release Date News:
It'll be out soon. Not that long.
Gives me goose bumps that my estimate on April 6, 2020 above was awesome intuition.
-
Redmine has the 2.5.0 currently at 94% - go you good thing!
https://redmine.pfsense.org/projects/pfsense/roadmapI absolutely cannot wait for this. I have been stressing over a bug for months (in 2.4.5p1 and the 2.5.0 development branch as of a few months ago) where if you run multi-WAN OSPF (FRR or even Quagga) between two sites, if one of the links drops then routing is still fine, but when that dropped link reestablishes - wow look out! All OSPF routes disappear, like... the whole OSPF process or Zebra or whatever restarts. VoIP calls drop. Chaos ensues. Nasty nasty stuff. OPNsense behaved fine back then (July 2020) when I tested this bug on pfSense, but migrating to that seemed a bridge too far.
But now after all the work they've done with https://redmine.pfsense.org/issues/10789 I tested last night with the latest 2.5.0 development, and low and behold - OSPF multiWAN works perfectly for me now! I can't tell you how happy that makes me - to finally be able to implement a sane multiWAN solution with pfSense.
The main thing that concerns me is the Bug #10943 with UEFI. I've been using that, and also Coreboot. I really hope Coreboot is supported and working fine! (I can get VMs switched from UEFI to BIOS, but I need Coreboot).
Anyways thanks for the update Jim - awesome stuff! Can't wait!
-
pfSense 2.5 doesn't appear anywhere close to ready as of yet. As I was wanting to have access to ipv6 port forwarding I went ahead and updated the gateway. At first glance, everything seemed to go smoothly. I then went to set the port forwards for ipv6 for ports 53 and 853.
Firstly, part of the time while I could successfully create the port forwards when going to apply the changes the changes would not apply and pfsense would provide notifications that the rules were not successful combinations even though they were set up as purely ipv6. It seemed to be mixing the ipv4 network for the interface into the rule from the message presented. When the rule is deleted (no amount of editing the rule resulted in the rule applying successfully) and carefully recreating I was able to apply. However, pfsense was now forwarding ports 53 and 853 straight back to the dns servers....even queries from the dns servers! This despite specifying source as an inverted alias DNSExceptions.
From the behavior and the previous notifications it appears the rules are intercepting on all interfaces and completely ignoring the inverted alias or even if the ipv6 of the dns severs were directly specified as an inverted host.
radvd also now seemed to be no longer staying on the specified interfaces as on the main network I was now getting ipv6 addresses for the guest network (69::x) and the normal (1::x).
As I made a config backup before going forward I wiped out the gateway and reinstalled the stable branch.
The problems with rules/port forwards may well exist on ipv4 as well as with the preexisting carried over rules from 2.4 were sufficient to break my dns as well as most of my queries from bind still go over ipv4. DNS was not reliable again until going back to 2.4.
Mutiple interfaces, mostly intel with two 10 gig solarflare interfaces. No vlans from pfsense's perspective.
I'd file a bug report or multiple but I do not have screenshots, logs, or packet captures and as such is left to others to formally replicate.
-
IDK, it works for me, and without any proof, I can only say that you must have done something wrong or your upgrade to 2.5 didn't go well.
c:\bind>dig @2001:1234:5678:aaaa:bbbb:cccc:aaaa:fffe A google.com ; <<>> DiG 9.16.8 <<>> @2001:1234:5678:aaaa:bbbb:cccc:aaaa:fffe A google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54234 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1432 ; COOKIE: c000adaeeacc4270010000005fc4d3282db34a188b047f3d (good) ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 80 IN A 216.58.209.46 ;; Query time: 4 msec ;; SERVER: 2001:1234:5678:aaaa:bbbb:cccc:aaaa:fffe#53(2001:1234:5678:aaaa:bbbb:cccc:aaaa:fffe) ;; WHEN: Mon Nov 30 12:10:33 ora solare Europa occidentale 2020 ;; MSG SIZE rcvd: 83
kiokoman@MediaServer:~$ ifconfig ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 < LAN RADVD RUNNING inet 192.168.10.210 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::20c:29ff:fe65:9f60 prefixlen 64 scopeid 0x20<link> inet6 2001:470:26:5dc:ffff:ffff:ffff:fff8 prefixlen 128 scopeid 0x0<global> ether 00:0c:29:65:9f:60 txqueuelen 1000 (Ethernet) RX packets 654498 bytes 820805002 (820.8 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 286100 bytes 91682575 (91.6 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ens224: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 < IOT RADVD NOT RUNNING inet 192.168.20.210 netmask 255.255.255.0 broadcast 192.168.20.255 inet6 fe80::20c:29ff:fe65:9f6a prefixlen 64 scopeid 0x20<link> ether 00:0c:29:65:9f:6a txqueuelen 1000 (Ethernet) RX packets 2874084 bytes 683255485 (683.2 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2152262 bytes 1406430588 (1.4 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0