@Jsetive said in DHCP not pooling in interface with VLAN:

connect the port in access with VLAN 200 and i still facing that issue.

Well again - the port connected to pfsense port that is tagging that vlan would have to be setup as trunk (cisco term) where vlans are tagged, and the native vlan is not tagged..

Just connecting a port in access (not tagged) to that port where your tagging 200 wouldn't work - just like connecting your computer that doesn't understand the tag or use the tag wouldn't

@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