I would guess it's because you are policy routing traffic from LAN clients to a specific gateway. So that works even when the firewall has no default route.

@Gertjan I can handle the interface shuffling via console. I am hoping not to have to reconfigure everything for all the interfaces again. I'll know for sure once I have an available round tuit so I can get it done.

@johnpoz Ok i see what you are saying now. I went back and re-read the documentation to solidify my understanding. Granted i think the wording around IPv6 could use some work in the GUI i generally understand what the knobs do here. Thanks for having patience

@stephenw10 ah ok. so depends really on what you want to do and/or see. Makes sense. Thank you!

@stephenw10 well its completely tanked again now just slowly got worse over several days. Going to try running it from a vm on my unraid server at least that way i can rule out the hardware

What are you seeing that looks like pfSense is sending traffic to other gateways? What are you using for monitoring ping targets?

Hmm, what change did you make that triggered this? Does it happen for any change? Is it actually losing the backend servers when this happens, the health check fails?

But can they connect to the pfSense GUI or ping it's local IP address?

@SteveITS Thank you for answering all my questions. I just found a managed smart switch that I'll try to create a few VLANs here. This forum always helps even if I'm too confused to properly put out my doubts. So thank you.

Probably the latter. It will not kill the connection to fail back. I assume you mean for an OpenVPN client running in pfSense? Though for external clients connecting to a gateway group the same would apply. In both cases the system prioritises maintaining the connection over failing back. Though in 24.03 this can be overidden: https://docs.netgate.com/pfsense/en/latest/config/advanced-misc.html#state-killing-on-gateway-recovery

The backtrace and end of the message buffer before the panic are most helpful there. Can you upload the full crash report(s) here? https://nc.netgate.com/nextcloud/s/n2e9iLQTRSYXY4X

@keyser Took the advice and re-installed pfblocker without keeping settings. So far so good. I have no idea what was wrong with the configuration prior. I'll keep monitoring but so far it looks good. Strange one indeed.

What's different about the subnet/interface that can reach it? When you try to reach it from the working subnet check the states that are created. Compare that with states created when trying from a failing subnet. Check the firewall logs. Connection refused instantly implies something is responding that it's blocked. The default pfSense block rule doesn't do that. So it may be incorrectly routed or denied at the target device. Your block 1918 destinations would block this connection since NAT happens before firewall rules. The NAT reflection rules should translate the destination from the CARP/IPAlias VIP to the internal server IP and that would be blocked. Are you trying to connect using an FQDN? Does that resolve to the public VIP? Steve

It might have a DMZ pass-through option that simply forwards traffic to pfSense. But that may not be useful if you want to use the public IPs separately.

Hmm, odd. Hard to imagine that it doesn't like running cooler!

@meowmere said in Pfsense 2.6.0 CE - No internet access: could it be from the ISP router configurations that I have to change? You tell us (the details) and we'll tell you ^^

@scilek I've edited my post, I was posting the wrong link. CE link is now there.

@wendel_gt did you enable clam av it updates at night try to disable it you might not have the memory for it

@VioletDragon Same thing. On pfSense, or elsewhere, that all good. remember : processes communicate with 127.0.0.1 = local, to some locally running process, or for example to 192.168.1.10, some device on pfSense LAN, with the same process on that device.