You don't need a cross-over cable for Gigabit. No special driver should be required. If you are trying to ping between them then I assume they are detected as interfaces and allow you to assign them and set IP addresses? Did you add firewall rules to allow pinging on the new interface? Steve

Hmm, those are supported by the driver in 2.5.X: https://github.com/pfsense/FreeBSD-src/blob/RELENG_2_5_0/sys/dev/e1000/e1000_hw.h#L193 Check the boot log. The driver may be failing to attach for some reason. Do you have SFP modules in there? Incompatible modules can present like that. Steve

@stephenw10 Thank you Sir. This was very helpful.

Thanks... I think I'll avoid the RAM disk for now and just keep an eye on memory.

Hmm, hard to think what that might be if it's only IPSec that stops responding. Do you mean there are no IPSec logs or no logs at all? If are no IPSec logs (until you reboot?) that implies the ipsec daemon stopped responding perhaps. I would look at the output od ps -auxwwd for ipsec, charon and strongswan lines. I haven't seen that on the one I have here though it doesn't get the use it once did. Steve

Ha, that'll do it.

Was it still running the default config? Pretty much has to be hardware if so.

Mmm, disabling MSIX globally for all PCI devices should really be a last resort option anyway.

@EveningStarNM After my upgrade to 2.5.1 I also was faceing some "strange" issues with my broadcom nics, too (I can remember, i several problems some years ago...) However: Given a special situation my broadcom nics started to change states from up to down and vice-versa. Was well documented in my logs. I started searching and stumbled about several threads and blogposts pointing me to the drivers for broadcom nics. https://www.it-react.com/index.php/2021/03/08/pfsense-re0-watchdog-timeout-error/ https://forums.serverbuilds.net/t/guide-resolve-realtek-nic-stability-issues-on-freebsd-pfsense-2-4-4-2-4-5-2-5-0-opnsense-use-2-5gb-realtek/3555 The blog-post gives a brief introduktion to the problem and solution. I went with the now already availeable package through pkg. Solved my problem and as it seems the day to day performance seems to be better as well. Might be worth to take a look into.

@stephenw10 Thanks. Seeing the traces were so identical, I checked twice: no confusion, those were two true distinct crashes/reboots. I had fully removed the good-old trafic shaper right after my last post. Seeing no new issues for more than 12 hours, I started rebuilding a new shaper configuration. Looks stable for now Thanks.

@stephenw10 ok, a bit more complicated than I thought then... If anyone have any idea what might help I`m open earl! Or else there seams to be more work to getting this to function than it is worth it..

They are still driven with an AC signal, you can change the tone of the beep. I'd be amased it didn't work when connected the other way. But anyway I don't believe that is the issue here, more that the device is not presented to the OS in a way that FreeBSD/pfSense can use as /dev/speaker. Steve

I assume you want to run the card as an access point? Most of the Intel driver do not support hostap mode so cannot be an access point. No, there is nothing significantly newer than the Atheros AR9380 that is supported. Yet. Steve

Hmm, interesting. We don't build that module though it is in our ports tree. You might be able to load the package from FreeBSD 12.2 stable directly. Steve

That indicates the system does not have an interface with a subnet covering that IP for the kernel add it to. Usually it means the WAN has gone down and that IP is the WAN gateway. Steve

Mmm, I can see no reason why it would not be unless you using some unusual connection method. Like maybe fiber directly. Or something similar to pfatt. Steve

You will be seeing two issues here. The firewall still boots because lagg is a subinterface excluded from the check. So even though it boors without issue the defined lagg will still be re NICs and hence invalid. When you add a 4 port Intel NIC it it's using the igb driver the WAN and LAN ports will probably have moved onto the card. The ports are numbered in the order they are detected and the expansion card is usually parsed first. See: https://docs.netgate.com/pfsense/en/latest/solutions/xg-1537/io-ports.html#optional-intel-1-gbps-expansion-card-ports Steve

If you just change the NIC type in Hyper-V I would expect pfSense to fail to boot because the assigned ix NICs would no longer be present. It would stop in the console and you would have to re-assign the interfaces there to the new ixv NICs. Steve