@stephenw10 yeah i forgot proxmox supports 'vmxnet', I assume its not as optimised as it is in esxi, but I do wonder if a multi queue 'vmxnet' on proxmox is more capable than a single queue 'vtnet'. It will be interesting to find out.

Undecided at this time. You could always roll back or switch to 2.7 if you need to though.

That's a side effect of how schedules are handled these days. The methods of fetching rule labels are not quite right there, but it's fixed on snapshots: https://redmine.pfsense.org/issues/13155 -- that alone wouldn't apply to 2.6.0 since there are a lot of other changes around after 2.6.0 there. Though schedules are not mentioned it's the same root problem since schedules are handled through an additional rule labels on 2.6.x.

Not personally. I'm sure there are many others here doing similar things though. Steve

@hayescompatible said in pfSense Plus generating corrupted backups: ror: SSHDATA at line 7349 cannot occur more than once in /etc/inc/xmlparse.inc:89 There's a known bug in the SSHDATA issue (https://redmine.pfsense.org/issues/13132) Check the redmine for details

@dnavas said in DLNA over VLAN: A how (not?) to: Your mileage will vary That is very true. I have seen users enable PIMD between the interfaces and do nothing else and it all immediately started working. I have seen other users spend weeks trying to make it work and fail. Implementations of clients and servers seem to vary significantly. Steve

@stephenw10 So I discovered a misconfiguration in one switch (LAN A), and seems like on HA mode, arpwatch has an option to avoid reporting CARP/VRRP ethernet prefixes that was enabled. To use CARP VIP and arpwatch together, that option needs to be check to disable those messages. Doing this it solved the situation. Hope this could help others since on documentation I didnt found anything.

@stephenw10 That did it, thank you. Here is the relevant thread and note from JimP about this rule. ( I cannot post hyperlinks) [image: 1657635731390-ntpsolvednatrule.png]

@stephenw10 Thanks Steven I will look this over and see if I cant make it work. Hope all is well.

The format is in the docs: https://docs.netgate.com/pfsense/en/latest/monitoring/logs/raw-filter-format.html

You should give more details on what you are asking for help with really. Also this should probably be in the Community Job Board. Steve

I'd also enable SSH now if you have not already so you can try to connect back that way. Steve

Hello, I've verified the problem. I got that notice after my rules had not been updated for some time. I followed iTestAndroid tecnique and confirmed that I had too this negate duplicate networks , so i checked "Disable Negate rules" and manually reloaded filter, which addressed the issue. but issue is not solved yet. I'have also tryed disabling nat reflection, but nothing Output of: pfctl -f /tmp/rules.debug is pfctl: pfctl_rules Following this thread after solved the duplicate ruleset, a reboot was needed. That solved the issue for me.

@stephenw10 I mostly use it for clients. I haven't had to change a server OpenVPN client in awhile. There needs to be an easier way to turn on and off OpenVPN clients.

Yup, seems there is some confusion!

Hmm, if it has a correct route and can ping the default gateway that starts to look like an upstream problem. You could run a packet capture on WAN whilst pinging just to make sure the pings are actually leaving WAN with the correct details. Steve

For reference see: https://redmine.pfsense.org/issues/13154 And the associated: https://redmine.pfsense.org/issues/13156 Steve

It's much safer to force the user to re-assign them. Imagine if you had 3 USB NICs and you disconnect one of them. Now at boot the NIC order might be different and you could end up with LAN hosts connected to a DMZ interface. Or worse. Steve

Sounds good. Thanks for the help. With the /boot/loader.conf.local variable change, I've been running for more than a day now and it all seems stable with much lower memory utilization. I feel a lot more comfortable with 58% utilized compared to the 88%, especially if I have a sudden increase in traffic or encrypted tunnels, I know there are enough resources available to handle anything thrown at it.