You do not need to edit the XML. During the import the system/GUI will ask what you want to map to, and it will prompt you with the adapters it can see.

@BiloxiGeek And it has to be ping-able.

@akhuyna It's like I already said that. :)

@stephenw10 are the lists the items under Feeds? where there is white section some gray and green high lighted areas if so i going to try to see if to disable them?

Under steady state conditions I show the ecobee premium connecting to a single ip. [image: 1756308824639-67a13b98-e9e5-4a80-baa2-1464cd5fa15d-image.png] and periodic connections to the dns server (x.y.100.2). Using any packages that may be doing traffic inspection?

@SteveITS Since the Netgate 2100 is at the Methodist local church and I support the firewall, this was a real user issue. They access the site monthly to do retirement account contributions for the church employees. Fortunately the login mechanism (once you can see it) requires two-factor authentication. Glad for that.

@stephenw10 I'll hold on any changes to ZFS for now -- I think the timing and data are pointing more to this observation being an "artifact" and that it is actually caused by the syslogd issue. I think from looking at the change I highlighted in the syslogd thread that when the remote goes down, and perhaps only if there are two destinations, the syslog code does in fact fail on the reconnect attempt. but it the mean time it continues to try to spew output to a destination (1 of 2) that is not available. those messages are still going somewhere, (we know they still go the the other syslog receiver and the local files, (as they should). but I think they are also getting "lost in space". I think it is most likely the flood of "sendto: Host is down" messages that I don't see in the logs during the event, (they actually don't show on either destination or local files, but other messages do) on the production server presumably those messages are going somewhere, and if the remote is down long enough and depending on available memory this is when the memory shift happens. Left unchecked long enough syslog eventually crashes (likely runs out of memory) even restarting syslogd does not recover this memory shift. in the graphs the difference between the large shift and the smaller shift is an indication of how long the remote was down and syslog subsequently restarted. Also explains why the shift takes time to go from high to low. Sad part is that restarting syslog does not seem to reclaim that shifted memory - rebooting does. (unless the shift back would take a really long time, I think that "memory" allocation is "lost in space" - the longest the system ran before I restarting when in the shifted mode was a little over a day. Monday morning was the latest observation and I restarted the system and memory has been at "24.11 normal" levels since - I also noted then that I moved the next scheduled syslog receiver server planned outage from Thursday to Friday Theory being if it doesn't shift until then, (that would be a different day timing ) then syslog has been the cause of this memory observation all along. https://forum.netgate.com/topic/198418/25.07-unbound-pfblocker-python-syslog?_=1756291874803

I'm away at the moment and can't check directly. However I don't believe it includes that. 2.8.1 is intended to be as close to 25.07.1 as possible so that testing/bugs apply similarly to both. It looks like it was the source address binding that was fixed there. I'll be back on this next week.

Like BIOS settings? Not really. It could be an ACPI bug that's exposed by the larger kernel in 25.07 taking up more space. But I'd expect a panic if that was the case.

@wzkds if client doesn't have an IP on the network attached to pfsense - it would never send traffic to pfsense.. You could see some broadcast traffic behind blocked.. Are they clients on a vlan? But yeah I would sniff on pfsense - have client ask for IP from dhcp - if your not seeing the discover all then yeah nothing ever going to work.

@Bob.Dig No worries.

Thanks. I had the same issue, kept failing boot verification 43000 files in the config backup directory. After getting rid of those, it upgraded faster than I have ever encountered in the past., I had gotten used to upgrades taking 10+ minutes.

@Abdul-Qadir said in pfsense 2.7.0 installed as vm on xenserver now routing issue: the CCTV nvr is somewhere else location connected to switch and i have connected that switch to our office network LAN swith. So how are you separating the two subnets? You are using VLANs on the switches? It sounds like you have a layer 2 issue there. It could be a loop perhaps?

It should still have a default route of course.

2.8.1 beta is available as an upgrade or available to install directly from the Net Installer. https://docs.netgate.com/pfsense/en/latest/install/netinstaller.html

Yup more and better logging is coming. However it also looks like there is an issue with the negotiated MRU/MTU value so a fix for that is in the works.