@beingmoody2 Tnx for the reply. Some more info... I've added a new interface to pfSense, and put it "directly" in the network/subnet of the DHCP server. DHCP relay now starts from the GUI(it will probably use that interface for relaying as it's closest to the DHCP server). I recon this is the most used option, so maybe that is why no a lot of people have problems. However, I do not want this interface there. If i disable this new interface from pfSense gui. DNS resolver won't start anymore.

@jimp Yep, I'm using Avahi, how did you know ? ;) But, mine is there so Captive portal user can 'find' our printers, so they can print something like a plain ticket or whatever. Knowing that the captive portal is IPv4-only land, I don't need that extra rule.

I never managed to disable compression with our type of traffic tbh, still stuck with lz4-v2 and some Sites comp-lzo. The day I disabled it turned out into horror with my phone ringing the whole day and people asking why the network is so terrible slow. -Rico

@behemyth said in 2.5.x status?: Yeah, check the redmine page. Keep a eye on the new/confirmed sub page for how many bugs there still are. When they hit 0 I bet they release an RC version. I will say for the past month or so they are absolutely crushing the bugs, they only have a small handful left. They also updated that page and removed all mentions of anything except for the latest 2.4.5_P1 and 2.5, so I'd imagine it wont be that much longer. looking at the overview they are definitely flying through it, exciting news.

Hmm, sounds like you may have hit a known upgrade issue that will require some uboot envs to be reset. Unfortunately that means rebooting. Though there is no urgency since is will boot an run fine with the default values as you have found. You will probably need to set at a minimum the envs for ethaddr and serial. Both of which are written on the bottom of the device. To do so connect to the serial console and reboot the device. Interrupt the boot were you see Hit any key to stop autoboot to reach the 'Marvell>>' prompt (uboot). At that prompt enter the following commands: setenv ethaddr=f0:ad:4e:XX:XX:XX setenv serial NTGXXXXXXXXXX saveenv reset Replacing those values with those from your own device obviously. It should then boot back up to the expected MAC. Steve

Well I spoke too soon. I just completely lost network connectivity, and the console port froze up. Definitely something going on here.. I must have hit the 12 hour mark, if not its pretty close. Had been working good up until just now.

Same for me on 2.5 with a Proxmox vm. https://redmine.pfsense.org/issues/11077

Fixed in the latest snapshot

yes, it's pfSense 2.5

forgot to update the widget was actually there to turn back on, thanks.

yes, it's ok now [2.5.0-DEVELOPMENT][root@pfSense.kiokoman.home]/root: cat /var/etc/openvpn/server1/config.ovpn dev ovpns1 verb 1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local xxx.xxx.xxx.xxx engine rdrand ifconfig 10.0.8.1 10.0.8.2 lport 1194 management /var/etc/openvpn/server1/sock unix route 192.168.1.0 255.255.255.0 route 172.16.0.0 255.255.255.0 secret /var/etc/openvpn/server1/secret data-ciphers AES-256-CBC:AES-256-CFB:AES-256-CFB1:AES-256-CFB8:AES-256-GCM:AES-256-OFB data-ciphers-fallback AES-256-CBC allow-compression asym sndbuf 524288 rcvbuf 524288 fragment 1450 mssfix 1450

Ah, cool! Well for the benefit of anyone else hitting this before we get a fix in.

My IPv6 works for everything fine and has but the monitor still shows unknown because it's failing to add the gateway to monitor it. I am on the latest snapshot as of this post. My ISP doesn't give a routable address to the WAN so I disable that and could be why we have different results but the monitor part needs fixing still for sure and not sure what, if any other impact that may be having.

for future reference if anyone searches for this even if the patch from https://redmine.pfsense.org/issues/10270 has been merged Adding a control to DHCP in general or per-interface for this seems like it would be excessive and confusing https://redmine.pfsense.org/issues/11003 my understanding is that they are probably meant to be used only on a HA sync. it's probably a lot of work as other stuff need to be rearranged like "Status / DHCP Leases" maybe in the future

Well, yes and no. It's just hypervisors are intended to replicate the hw level. So if something is removed from HW support, for example with Intel, it means it goes away for drivers and other things also and that stuff does play a role on hypervisors. The same is true for OS's. Why would OS's want to support something legacy EOL'd by the hardware OEMs? It just adds complexity and risk. If a vulnerability or flaw comes out they now must deal with/address that simply because they didn't want to move on with the world. Otherwise I agree, the same rules don't always apply. These sorts of issues end up existing purely because the legacy stuff still being around. This is because it creates more test cases and more of a chance for things to be missed. Imagine if EFI was the only option today. This bug would have never made it out the gate hah. Instead it wasn't caught in testing and made it downstream. But for now the options are what they are. BIOS, use older HW version or swap the controller. I'll stick with the older HW ver I think since that works and I don't "need" to run the newer ones anyway.

tested now for 24 hours without any problem, rules and redirect work as expected, at least for dns ; <<>> DiG 9.16.8 <<>> -6 @abcd:1234:abcd::1234 google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20698 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1432 ; COOKIE: b4478e1af406b0c4010000005f91fd06f6450beac9f0f72e (good) ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 264 IN A 216.58.206.78 ;; Query time: 2 msec ;; SERVER: abcd:1234:abcd::1234#53(abcd:1234:abcd::1234) ;; WHEN: Thu Oct 22 23:43:34 ora legale Europa occidentale 2020 ;; MSG SIZE rcvd: 83 [2.5.0-DEVELOPMENT][root@pfSense.kiokoman.home]/tmp: cat rules.debug | grep DNSv6 table <DNSv6> { 2001:470:b682:ffff:ffff:ffff:ffff:fffe 2001:470:26:5dc:ffff:ffff:ffff:fffd } DNSv6 = "<DNSv6>" rdr on vmx0 inet6 proto { tcp udp } from ! $DNSv6 to ! $DNSv6 port 53 -> 2001:470:b682:ffff:ffff:ffff:ffff:fffe pass in log quick on $LAN inet6 proto { tcp udp } from ! $DNSv6 to 2001:470:b682:ffff:ffff:ffff:ffff:fffe port 53 tracker 1603300825 keep state label "USER_RULE: NAT "