Messages

The following pop up alert appeared during my update a few minutes ago (image attached).

It read:
An API exception occurred
phalcon/Mvc/router.zep:724: A dependency injection container is required to access the 'request' service

Checking status and for updates after indicated everything was up to date. I haven't poked around to see if anything is broken yet, but figured it best to leave a post about it in case it would cause an issue with some aspect I'm currently not using, etc.

This opnsense is running on a virtual machine on windows 11 pro. Base hardware includes Intel 10850k (stock settings), vm is set to use up to 24gb of the 32gb of ddr4. Network card being used is a Intel x550-t2 based model. Wan port isn't shared with windows os.

Up until this update I haven't had any issues. Added plug ins are primarily zen armor and crowdsec and it's used for home purposes.

Please let me know if I can provide any additional information that would be helpful.  Thanks.

First place to start would be setting up rules for the OPT interface's firewall.

To start, what I did was close the IPv4 rule that OPNsense creates by default. When you are configuring that clone, you can then change the interface to be OPT and the source to be OPT network. Then you can check if devices for the OPT port can say go to google the same as anything plugged into LAN.

For cross port communication, I'm not overly experienced and learning myself, so I'd guess you would need to ensure that the local addresses would be resolved by any dns requests sent (the register addresses check box)

I added additional rules that might be unnecessary given the allow to any, but a allow IPv4 from the opt network dhcp range out of firewall to lan dhcp range in the lan firewall rules and the reverse in the opt rules (lan range out to opt range) mostly so I can ping across in case of some configuration issue and connect a system directly to the opt port. Normally, what resides on that port is our solar panel system reporting out it's information to a monitoring service and all our other devices are on the lan port. I did have these rules to have logging enabled just to see if there was any weird traffic, but there hasn't been any that wasn't created by me (pinging the solar panel controller).

Routing should be created by OPNsense, so I don't think there's anything else you need to do there. With this setup I can ping the sole device that is connect to my opt port from my desktop using it's wifi connection to the lan port without issue. I haven't tried any other types of cross-communication as it's info is simply sent out to the monitoring service and I have no direct interactions with it.  I set it up on the OPT port so it didn't create any additional slow downs (it's only 100m ethernet) by connecting it through say a port on my wifi access point and through the lan.

If you need multicast and similar, that I'm unsure of as I know there's a plug in for it but there's no need to relay multicast and similar message with my current setup and haven't messed with it.

Someone with more experience and know-how can likely provide a better answer with additional suggestions, but this might get you started for now.

In setting up my WAN, I've found that it relies on ipv6 link-local for the gateway and that gateway communicates from that link-local address including link-local to the multicast of ff02::2. I'm just learning all of this so I have guesses as to what is going on, that it's trying to check for new devices connected to it to assign them an ipv6 address, but would like to know if this is correct and what I should be doing about this traffic and why the gateway itself never resolves to an IPv6 address and instead remains a link-local one. Recently after trying a few things, I unchecked the normally checked block private networks after I manually added WAN rules to block the IPv4 address ranges it lists in the description. This probably isn't the right choice, but this is more for learning than say protecting a business's network, etc.

Checking the NDP table, I can find that address, that its manufacturer is Cisco and even double checked and its mac address doesn't match that of the cable modem.

Now I recently checked the System>Log Files>General logs and I'm seeing:

Code Select Expand

Notice kernel <7>cannot forward src fe80:2::2c8:****:****:****, dst 2601:193:8200:939:****:****:****:****, nxt 58, rcvif igc1, outif igc0

which by address is the link-local address for the gateway as the source with a destination that appears to be a combination of the IPv6 prefix and last 4 parts of the wan's dhcp assigned ipv6 address.

My guess is that there is something I misconfigured somewhere, a setting that needs to be enabled or disabled, etc. and I was wondering what other users may have for their dhcpv6 settings, etc. for Comcast/Xfinity that is correct (or at least isn't generating errors). Currently my DHCPv6 client configuration just has a prefix delegation of 64 and Use IPv4 connectivity checked, with Use VLAN priority disabled.

I've been messing around with different settings and configurations as I've been getting random latency spikes and trying to figure out if there's something left on my end that could be causing it versus something on their side (which honestly seems more likely as this has been ongoing for years even before having a firewall system between the cablee modem and my local lan)

On the LAN side, I have it set up to allow manual changes with a range that involves :dddd: so that I can tell immediately if an ipv6 address used was assigned locally and it's DNS servers listed as ::1 and the LAN track IPv6 address which is in that 2601:193:8200::/64 range and isn't the address in the error. This too is likely configured incorrectly, but again I'm messing around and trying to learn and have it so any ipv6 dns queries go to opnsense instead of out to comcast's dns servers.

One thing I know I should probably do, but haven't yet, is to create rules to redirect dns traffic to opnsense, but first I also need to get doh requests set up to be resolved locally as apple devices seem to love using that.

I've rambled a bunch here, but figured its better to provide the additional information that might not be needed than not provide enough.

Hardware wise, OPNsense is currently running on a Protecli Vault VP4650 with way too much memory (in case I wanted to mess around with virtual machines next) and an NVME ssd drive. Currently I have hyperthreading on in the bios and OPNsense reports 8 cores (4-cores, 8-threads). It uses Intel's i225-v controller and I've updated the bios a few months ago to the latest they provide and haven't seen any newer versions since.

Any help with resolving this error and other configuration suggestions would be greatly appreciated. Thank you.

I'm unsure what is going on with this but when I went to the (Firewall:Diagnositics:)Sessions page, the first line shown is:

<-- (out). icmp   71.233.x.x:29816 (wan dhcp ip)  71.233.x.x:29816 (isp gateway listed in interface summary)    0:0  29711  10  56.77 KB   1.55 MB  Block priv... link (goes to checkbox setting for Block Private Networks option)

...and I'm wondering what is going on. I have no formal training in networking, just learning as I go, and was wondering if that Block Private Networks link is being incorrectly displayed or something.

71.233.0.0/15 is a Comcast block that doesn't appear to match any of the networks listed as Private.

I'm fairly new to all of this myself, but I would also try and check speeds between lan devices first to see if it's some misconfiguration or other issues on the lan side. With the hardware you listed perhaps Surface to and from desktop and see if the speeds match or are much higher than to something outside of your local network, though note that the slowest device will be the speed limiter. Another comparison to do would be disabling firewall functions, suricata, etc. to see if it's a rule, packet inspection, or something there. You can also bypass the entire firewall hardware if something else on your lan such as wireless router can act as the dhcp provider, etc. and bypassing the lan entirely such as by running wired say from your desktop to your cable modem or other device that provides your internet connection. Compare all these numbers for the same device and see where the biggest drop in speeds is and then you at least have a starting point to look into for the biggest potential improvement. Some slowdowns are just going to be present, say for packet inspection so then you have to weigh feature vs speed and determine what's most important for you. If it's say suricata, zenarmor, or similar you can try using exceptions, rules, whitelisting, etc. to try and mitigate speed decreases for specific traffic that you assume to be safe.  Someone with more professional experience and a better undestanding can help.

Lastly device information regarding the hardware opnsense is running may also be helpful. Perhaps there's a driver that needs a particular plug in (I believe there's a Realtek one) that may help as well.