There is no specific rule to block it. All unsolicited traffic is blocked inbound by default. Traffic is scrubbed by default which prevents fragments passing but even if you disabled that most rules would not pass fragmented traffic because they cannot match without the header info. See: https://man.freebsd.org/cgi/man.cgi?query=pf.conf#FRAGMENT_HANDLING There's no way to actively pass fragments from the GUI, there is no fragment option on user rules.

@planedrop said in Will pensense join vpp/dpdk: @NollipfSense I am guessing a typo, though that might be a difficult one to do.... LMAO...

It's defiantly Home Assistant. I assume deleting the integration didn't completely get rid of everything. I'll have to do some poking around and see if I can find out how to disable whatever is left.

Commonly it's because there are no iroutes to allow the OpenVPN server to know which subnets exist behind which clients. Those are not required in a shared key setup because it can only ever be point-to-point. https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html#create-client-specific-overrides Steve

@stephenw10 That's great, thank you. I'll get that done

The error is still misleading. Try removing a package at the command line: pkg-static remove pfSense-pkg-Open-VM-Tools Steve

Hmm, then there should be no problem with them using the primary IP in the 10.10.0X subnet as long as it' not the CARP VIP. Do you not see states at all on the other nodes?

@Gertjan that's what i have done sunday! i was surprised that it didn't worked, but i saw the cable was still in the yellow of port of the netgear....i put it in the right port and everything goes well!

@walidbz said in Unable to check for updates from dashboard: i install from : https://pkg.pfsense.org/pfSense_v2_7_0_amd64-core That isn't where you're installing from. Neither wazuh-agent nor pkg-1.20.6 are in that repo. Also if you have pkg-1.19.1_2 installed you would not need to run pkg-static: [2.7.0-RELEASE][admin@pfsense.fire.box]/root: pkg search wazuh-agent [2.7.0-RELEASE][admin@pfsense.fire.box]/root: What repo do you see in?: pkg-static -d update What version do you in? :pkg-static info pkg

Just to clear you should restore the complete modified config. The rules section will reference a different set of interfaces so will not line up otherwise.

@RobbieTT said in Tunning after half a gig: I know, you are stuck on G.fast The struggle is real! But, yes, multiqueue PPPoE sure would be nice.

Yes, generally I'd rather use VLANs with a managed switch than a USB adapter. Though Realtek NICs can also be problematic. But not always. Steve

@NogBadTheBad Thanks? I added IPsec as was previously not using... Still - no change re: original issue: iOS device over wifi (Unifi AP) using 2FA: can NOT authenticate Diagnostic > Authentication: The same user authenticates using 2FA Log reports as listed in thread title

@Nervous-Ned Or set your pc/device your using to connect to pfsense to have an IP that is in the range you set the new IP too. If pfsense IP is 192.168.1.1/24 and you change it to 192.168.2.1/24 your pc on 192.168.1.2 is not going to be able to talk to 192.168.2.1 until it has an IP in the 192.168.2.x network. Be it you change manually, or let your pc get a new IP from dhcp. This can be done by unplugging the cable from the pc for a second and then plugging it back in, or just doing a ipconfig /renew should do it as well if your on windows.

You can bridge the ports, it will work. And, as stated, it costs nothing to try it so why not. Generally in pfSense you would not do that because adding router interfaces is a lot more expensive than switch. And because if you don't need to filter between those interfaces a switch works better and doesn't load the firewall. But it will work. Steve

@stephenw10 - Thank you Stephen for taking the time to reply. The following is an update for anyone who comes across this which may benefit from this exchange. No matter what I tried i could not get rid of the crash. I noticed this usually happens when the firewall is under heavy use. Normal use usually did not result with the issue. In the end I decided to change the machine and now using Intel(R) Core(TM) i5-8500 CPU which has been working with no issues for few days now. I know this is way overkill, but the lower powered ones were problematic. As for your question on: Do you see the file /var/etc/xinetd.conf present on the system? I moved into a different system and don't have access to that install anymore hence i can not answer it.

@stephenw10 Thanks Steve. We will replace this mini-PC with a VM on an Intel NIC platform. In every other respect the mini-PC has been great but there is nothing to gain with experimenting on this hardware.

Nice result! That was certainly a weird issue.

@Headstorm-0 That intel NIC should be solid, can you test with snort and pfBlockerNG fully disabled to see if this persists? make sure running a force reload>all in pfB returns no output.

@kp206 Go to the gateways logs (Status / System Logs / Gateways) and see what dpinger is reporting when the problem happens, and when you attempt to restart the service. Assuming that you are not doing multi-wan, two quick questions: Do you have an explicit monitor address set for the gateway in System -> Routing -> Gateways? Do you have addition of static routes for gateways (System / Advanced / Miscellaneous) enabled or disabled?