The cert hashing issue is a known bug in 2.7.0. It's fixed in 2.7.1 and later: https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#troubleshooting

Well I would certainly test with Squid disabled. That traffic may not be leaving the WAN.

@kevdog said in Stack trace when starting pfSense - System wont start: /cf/conf/config.xml -- contents of this file are nothing -- it's an empty file That's scary. [24.03-RELEASE][root@pfSense.bhf.tld]/root: ll /cf/conf/config.xml -rw-r--r-- 1 root wheel 1455699 Jul 3 00:47 /cf/conf/config.xml It is the currently used main pfSense config file. It contains all my settings, without it, pfSense "won't work".

I realize this is an old issue, but I have experienced the same problem. I was able to fix the issue by accessing the WAN interface, press save, then press apply.

Hmm, sounds like it's pulled in some invalid signatures. Or doesn't have pre-processors enabled for the signatures it has. And just did it again from the older BE. Try disabling OpenAppID.

Re: Certain characters are being improperly displayed in Google Chrome yet properly displayed in Microsoft Edge Thanks for your responses and suggestions. The problem was solved by thoroughly removing Chrome and ALL its configuration data. I then reinstall Chrome and all is back to normal.

Yes 24.08 will have an updated openssh version.

@ebj29 said in pfsense cannot ping router unless router is pinging pfsense: with the same ip /28 address I am with @viragomann and @stephenw10 on this - while it might work in some scenarios.. .128 is the wire on a /28 cidr.. Shouldn't really be used as a host address. Same with .143 in that /28 being the "broadcast" while both wire/network address, broadcast address can sometimes be used as actual host address.. Wire/Network address and broadcast shouldn't really be used as host addresses. Glad you got it sorted, but using those addresses as host when they are not meant as that is bad practice..

Hmm, that would be interesting. Is it reported anywhere? Different PCI ID?

Unfortunately not. The redmine site pre-dates much of the current Netgate infrastructure.

Some more IPv6 things to learn / play with. Better dhcpc6 status information (the PD_PREFIX is only printed once in the logs when debugging is enabled) Option to use a PD_PREFIX "template" in other configuration fields (eg rules/wireguard) instead of hardcoding a IPv6 address in those. (might already be possible for rules?) Make IPv6 the primary stack vs IPv4 (UI / design / thinking wise) NAT64 / 464XLAT support so that IPv6 only networks are possible (Should be feasible for most big OS'es, expect Windows although CLAT support for non WWAN interfaces was announced, no timeline yet tho) Better (UI) way to handle manual DNS registrations (IPv4/6) versus automatic DHCP ones (no need for DHCPv6 in my use case, SLAAC is great and the latest Windows 24H2 works with RDNSS on dual-stack)

@jshoe It could be either if filtering is on the member interfaces. I would probably move filtering to the bridge interface and apply it there for logical simplicity.

@stephenw10 I was able to figure it out. There was a problem on my Netgear switch. Old MTU and VLANs were not removed.

You don't have to put the modem in bridge mode. But doing so avoids double NAT which is preferred.

In what pfSense version? It's failing to load the font awesome characters. A force refresh or clearing the cache usually fixed that.

@Gertjan Thanks!

@stephenw10 Straightforwardly, AFAICT (see below). This configuration is translated straight from my working OpenWRT configuration, double-checked, etc. For he.net, hostname and username are the same (the domain to use). The 'Interface to monitor' dropdown only has WAN and my other LAN interfaces, no special separate interface for 6rd. Even if these details were wrong, I would expect to see something other than 'Couldn't connect to server' in the logs. It seems like there is some deeper issue preventing the DDNS handler from even contacting the he.net server. [image: 1719851278371-screenshot-2024-07-01-at-9.24.05-am-resized.png] [image: 1719851287314-screenshot-2024-07-01-at-9.24.12-am-resized.png]

@stephenw10 sdwan company we used for few customers at last gig used the documentation network... 192.0.2.0/24 For the tunnels to make didn't overlap with sites of the customer network.