@michmoor

Solved!!
There was another P2 active.
So i think i know what happened. Whent he IPsec tunnel was first set up, it was in tunnel mode. Switched over to VTI but the other p2 was still there. Somehow there was a conflict. After deleting the old p2, things are looking good.

Leaving this here for future me or anyone else

What bandwidth does it need to pass? Do you plan to run any packages or VPNs?

Yes, that is possible. I would say there is always some risk that Windows decides to use those NICs before hyper-v sets them us to pass through. But there are many people doing exactly that.
Probably better to ask about it in the Virualisation sub.

Steve

Any of those VPNs could work for that. I would probably use IPSec for a fixed site to site tunnel like that though.

Hmm, two panics shown there in different processes and different backtraces.

I would run some memory tests to be sure it's not just bad RAM.

Steve

Yes pfBlocker puts it's rules at the top by default. You need to change the rule handling to allow custom rules above it.

Or you can use a pass rule for the dyndns name in pfBlocker so it gets added at the top anyway.

Is pfSense resolving the host correctly?

@stephenw10 I get it completely. Legacy code. Technical debt. Limited resources. If we have all the time in the world then all the things can be done 😀

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