Messages

Good morning,

I am hoping someone can please help me.

I am running a couple of dedicated game servers locally at home.  I have a VPN running which all of my traffic is routed through, however I want to have my game servers connected directly via my ISPs static WAN address instead of going out via the VPN interface, due to its highly dynamic IP nature.  I have it partially complete, with port forward NAT and firewall rules set for traffic inbound via my WAN interface to take priority and be passed to my internal server IP and port.  This works perfectly and I can directly connect to my game server using the external ISP static WAN IP and port, as can my friends, so this is all working as expected.

However, for both games, they do not appear in the game server lists used within the game search systems.  When I set the first up I assumed a bug, however the second also does the same.  In further checking, it appears that both games report their external IPs as being my VPN interface IP.  I realised that this is likely as, although my inbound traffic is coming via my ISP WAN interface, I obviously do not have anything setup for the outbound and therefore I assume their outbound traffic goes back out via my VPN interface and therefore they detect the IP for that as the one to think they are operating under.

I have therefore set NAT rules for the outbound so that traffic from my game server IPs and associated ports are NAT to my ISP WAN interface, with accompanying firewall rules on the LAN for traffic to be able to pass from the LAN to the ISP WAN interface.  These are set before the rules that push all my LAN traffic via the VPN interface, so they should take precedence.  However, my game servers continue to pick up the VPN interface IP as the one to use and I think I must have done something wrong.  Am I thinking along the right lines or do I have this all wrong please?

As this is confirmed as a continuing fault in 19.7, should this thread be moved there or a new one started and linked back to here, with 19.7 discussion there.

This is an ongoing and severe issue for me.  I've tried a bunch of potential fixes mentioned in this and some other threads but nothing has worked.  The moment my PPPoE refreshes my OPNsense self-immolates and requires a hard reboot.  I've tried this on a fresh install and it is the same.  I have yet to upgrade to 19.7, I'll likely try this shortly and see what happens.  If it's still an issue I'll have to jump ship for another option.

I upgraded to latest 19.7 version and still occurring, so definitely not fixed there.  I have tried some suggested fixes here and on other BSD related forums and nothing has worked so far.

This is an ongoing and severe issue for me.  I've tried a bunch of potential fixes mentioned in this and some other threads but nothing has worked.  The moment my PPPoE refreshes my OPNsense self-immolates and requires a hard reboot.  I've tried this on a fresh install and it is the same.  I have yet to upgrade to 19.7, I'll likely try this shortly and see what happens.  If it's still an issue I'll have to jump ship for another option.

Intel I211?

Intel i210AT is what is listed for them. I hope you're not about to tell me that those are bored in BSD!

I am using Intel NICs. I use a Supermicro X10SBA board and just went to their support page to confirm just in case I was mistaken.

For testing purposes it may help to disable smp (simultaneous multiprocessing). The idea behind is to mitigate concurrency within kernel mode.

• Disable smp: loader tunable kern.smp.disabled=1
• Disable specific cpu: loader tunable hint.lapic.X.disabled with "X" as the apic id of the cpu

Further details, see here

I'll try this next and report back in a few days

I've stayed up for 50 hours without failure, however my PPPoE connection has not reset during that. I forced a reload of my PPPoE and OPNsense immediately died and required a reboot. So at least I know it is due to PPPoE, but that tunable has not fixed it.

I have been experiencing this issue for a while now, and I also use PPPoE.  It's been driving me crazy and I lack the technical experience to solve it myself.  I thought it was due to my use of the earlier Wireguard packages, or maybe my hardware was faulty.  However, I returned to OpenVPN and removed WG, and did a fresh install on top of that, and also tested my hardware and didn't see any faults occurring there, but the issue has kept occurring.

I have also set the tunable as detailed by cpw and I'll report back in a few days as to how it is going.  I usually see at least one kernel panic a day, sometimes multiple, so I should know quite quickly.

I have also been suffering lockups and connectivity loss, requiring full manual reboots. Happens at least once a day and usually 2-3. I lose all network connectivity through OPNsense, though sometimes I don't notice straight away as if streaming a film from my media server, my switch keeps that traffic flowing. I cannot access the webgui and my console is locked up too. I have discovered that it only happens when my small server is connected to the network. It runs Arch Linux and if disconnected the lockups stop. What else do you have connected on your network? Are you able to try removing one device each day and see if the lockups stop for that time period?

Good morning,

I've been experiencing an odd issue that I have been trying to resolve and initially thought was due to anything from a fault in OPNsense itself after an upgrade, to the Wireguard package I was using, to my hardware. But now I think it is something else entirely.

I have a basic small home server running Arch Linux which contains mostly media along with some other data, and a bunch of services mostly running in Docker. It's taken over from an old HP Microserver I had, and was originally built since around October 2018. From around that time I have been experiencing severe instability issues with OPNsense in that the whole system would lock up and the webgui and SSH would be unresponsive, I'd lose all networking, and have to reboot to get the system back up. This happens at least once a day, often twice or even more. As I said, I thought there must be a fault and I've been trying to rectify it without success. However, one of the OS drives in my server died end of April and it went offline for around 2-3 weeks. During this time I have had 0 failures on the OPNsense box. I got round to rebuilding the server the other day, with new drives and a slightly modified and fresh build, and immediately the issues have returned, with OPNsense failing twice a day over the last few days.

My main desktop uses Arch as well and hasn't triggered this response from OPNsense. I don't know if this is a hardware or software issue caused by my server or why it would even cause this. Having left it unplugged for a while, the failures stopped occuring. Does anyone have any idea as to why my server might be causing this, spanning two entirely separate installs of both OPNsense and Arch? Any advice would be appreciated. I don't even know what I'd look at log-wise to identify the cause.

Thank you, mimugmail. I'll switch back to OpenVPN for now then but will keep an eye on WG and happy to test when needed.

I've been experiencing random kernel panics for a while that require a hard reboot of the system. I thought it was due to the update fault in 19.1 which has now been resolved. Then I discovered my SSD was dying and I thought it may be just related to that.

However, the 19.1 issue has been fixed and I am now running 19.1.4, and I have also replaced my SSD. After much testing, I have found that the system seems to panic and die after I have remotely connected via Wireguard from my phone to OPNsense and then disconnected. I do.not see the same issue if I switch to OpenVPN.

Checking online, it seems others have reported the same fault and that it is an error in the underlying 11.2 FreeBSD Wireguard implementation. Is this correct and the likely cause of my issues? If so I will have to switch back to OpenVPN for now. Wireguard has been superb in terms of connectivity, reduced battery consumption and ease of use, but I can't have it killing my system like this. Any confirmation or advice would be appreciated.

I need to apologise. Seems my error was not the kernel panic. It started after my upgrade and exhibited similar behaviour to other reports, and also happened if booting on a live USB, so I assumed was the same.

However, turns out my SSD had suddenly begun failing and died the other day. Having finally sourced a replacement today, everything is now perfect. Not sure why the SSD was also causing the live USB boot to fail, but it was as no such issue with the new one and I've not changed anything else.

Config imported and back up and running in a few minutes. Amazing work from all involved in the development. Thank you!

I had this issue too and it did cause breakage at home. Sure, I'd rather it hadn't happened, but I get this stuff for free and it's generally solid work, so I am appreciative of all the effort made by the Devs. I am consistently amused, puzzled, and annoyed by those who keep ranting on about how their essential production business system has been affected. I'm no expert, but I'm pretty sure that if I were running something like that I would a) not just mash the upgrade button the second a release is out b) not do it without testing on a standalone box first c) not do it without backups with a restore strategy I can revert to d) maybe consider paying for the proper support levels if I'm profiting from this and need the help urgently. But as I said, I'm no expert, maybe throwing my expensive business kit into the fire with no plan is how people roll these days.