pfSense 2.5 Release Date News
-
@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
-
@qsystems Thankfully I'm not running any IPv6 yet (I know it's 2021 but the ISP doesn't offer it - shock horror!)
Hopefully you can get it sorted out. If you can lab it up in GNS3 and replicate, I'm sure the devs would appreciate the bug report. -
@Gcon said in pfSense 2.5 Release Date News:
Thankfully I'm not running any IPv6 yet
Why "thankfully". You should be using it. If your ISP is stuck in the dark ages, you can always use a tunnel to get it. He.net is popular for that.
-
@JKnott said in pfSense 2.5 Release Date News:
Why "thankfully". You should be using it.
I meant "thankfully" in terms of not hitting any IPv6-specific bugs, in case that wasn't clear. But to be totally clear it's not about me but rather the corporate networks I support, and not one of them require IPv6 in any way, shape or form. Support time and effort is a fair deal lower supporting single stack vs dual stack. That's the cold hard corporate reality. Thankfully I only have to support IPv4 for these networks. I am a fan of IPv6 (and have been a tech evangelist for it for over a decade), but when it comes down to it, the path of least resistance is best and if it's not needed, it tends not to get implemented.
-
@qsystems said in pfSense 2.5 Release Date News:
As I was wanting to have access to ipv6 port forwarding
Sorry you want to do what? IPv6 port forwarding!?
-
@jegr said in pfSense 2.5 Release Date News:
rry you want to do what? IPv6 port forwarding!?
Haha port forwarding with IPv6.... gotta conserve that IPv6 address space right? ROTFL
-
@gcon
it is needed for example to intercept dns or ntp traffic and silently forward to another device -
No it's not. I redirected NTP by adding the host name of the server being used and adding it to my DNS server, so that it now pointed to pfsense.