root@OPNsense# tcpdump -ni vtnet0_vlan50 "src 192.168.50.116 and dst 192.168.50.102"-> shows tons of traffic as expected on a promiscuous & bridged interface in this networkroot@OPNsense# tcpdump -ni vtnet0_vlan50 -p "(ether host $OPNSENSEMAC or ether broadcast) and src 192.168.50.116"-> no more promiscuous, this shows exactly what I would expect, traffic from this source host leaving (or trying to leave) this subnet, being sent to opnsense. destinations here are never in 192.168.50.0/24root@OPNsense# tcpdump -ni vtnet0_vlan50 -p "(ether host $OPNSENSEMAC or ether broadcast) and src 192.168.50.116 and dst 192.168.50.102"-> again shows nothing, which makes sense as local traffic should not be addressed to the opnsense MAC address. yet during this test my opnsense logs keep filling up with drops for this exact source/destination/interface pattern?!Quote from: nero355 on Today at 05:53:29 PMEven when it's disabled it still occures because of :Quotethere are only 3 routes which are correct (to each local network on the right interface, plus the default gateway which again points to the right interface).When your Client/Server receives packets from Network X via Gateway Z the data won't go back via Gateway Z if the Client/Server has a NIC that it also connected to Network X and will use that NIC to send the data back to Network X.
Quote from: snulgy on Today at 05:19:42 PMI did of course double check those settings as I mentioned - packet forwarding is off for IPv4 & 6 (I actually disabled v6 entirely for now to rule out issues)Even when it's disabled it still occures because of :
Quotethere are only 3 routes which are correct (to each local network on the right interface, plus the default gateway which again points to the right interface).When your Client/Server receives packets from Network X via Gateway Z the data won't go back via Gateway Z if the Client/Server has a NIC that it also connected to Network X and will use that NIC to send the data back to Network X.
QuoteIt does smell like asymmetric routing but I haven't yet figured out how this can possibly happen here.I am working on a document about this, but it's not finished yet because I am writing it many months after having dealt with such an issue so I need to double check a lot of things.
Quote from: hakuna on Today at 05:46:32 AMSSD/NVMe is electronic, I cannot trust cutting the power while in halt, won't damage it coz it is still in operational mode.The issue with SSD's is that they have become a mess over time :
QuoteI will die in this hill, halt is not and will never be a shutdown.I agree with you that the whole thing should be automatic and hassle free and most of all clean :)
Quote from: lmoore on Today at 07:53:53 AMDuring the evolution of Hard Disk Drives, upon power failure, the IDE drives (and others too) were designed to retract the heads to the landing zone.But AFAIK the SATA Controller needs to give them that signal and that signal again comes from the Operating System so it's one big chain that needs to do it's work correctly.