pfSense 2.5 Release Date News

NollipfSense

@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.

Gcon

Redmine has the 2.5.0 currently at 94% - go you good thing!
https://redmine.pfsense.org/projects/pfsense/roadmap

I 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!

qsystems

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.

kiokoman

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

Gcon

@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.

JKnott

@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.

Gcon

@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.

JeGr

@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!?

Gcon

@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

kiokoman

@gcon
it is needed for example to intercept dns or ntp traffic and silently forward to another device

JKnott

@kiokoman

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.

kiokoman

@jknott
i prefer to do this way

you can't use host override for IOT device with embedded 2001:4860:4860::8888
i don't use dns of pfsense and i don't use ntp from pfsense i need to redirect to a bind9 dns server
and it was only an example