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?

@macaruchi Peers allow Adresses > gust give 1 IP per Peer (/32) + check your Firewall Rules

@ojosaghae Coming from that far, 2.5.1, I would backup a pfSense config, and not bothering upgrading the device. Install clean with a memstick version from pfSense download. You'll have a chance to change the file system to ZFS. "You want that" and in place upgrading can't give you that.

Probably not. What I would expect to be required would be to bridge each VLAN individually. But if you do that you can't bridge the untagged parent interfaces because it will break VLANs on those NICs. So if you moved all traffic onto VLANs then using multiple bridges it should. Steve

If it's a bug in GAProxy it might be fixed in the dev version of the package. It uses 2.8.d12 vs 2.7.8 in the standard pkg.

@mpcjames Just to help with some of your early questions. You are correct that the Openreach VLAN is added by the modem or ONT. For generic modems this may have to be added manually, or not, as some UK-specific firmware loads do this for you (eg on some Draytek units with BT-approved firmware). The MTU for your WAN/pppoe0 link (shown as MRU 1492 in your stats above) should be set at 1500 - ie the standard packet size. The actual physical interface connection between your pfSense router to the Openreach modem or ONT should be set at 1508 MTU, to allow for the extra 8-bytes of the PPPoE wrapper: [image: 1694082069193-2023-09-07-at-11.18.35.png] [image: 1694082081847-2023-09-07-at-11.19.14.png] You will see the somewhat bogus PPPoE MTU 1492 mentioned a lot on English-speaking forums as they tend to be dominated by those from the US, where they do things differently. The 1492 setting has become somewhat of an internet lore but is incorrect for many other countries, including the UK. I'm on the pfSense Plus side of the house where there have also been a number of PPPoE niggles, one of which is the multiple attempts to achieve a PPPoE link, rather than the expected single attempt. This can muddy the waters when doing any testing. For reasons unexplained the latest 23.09 dev firmware is more likely to make a PPPoE connection at first try. So there is hope that things are getting better for UK-style connections. I hope this adds some UK-orientated clarity! ️