Messages

The GUI config for telegraf inputs has an option for "dns_lookup" and adds the option (either true or false) to the telegraf config file. The "dns_lookup" option in inputs.ntpq was deprecated some time back and the telegraf that is installed with 25.1.10 considers it a config error and stops config from loading. 

To fix, comment out the following from /usr/local/etc/telegraf.conf


[[inputs.ntpq]]
  dns_lookup = false

This is truly bizarre. Out of the blue yesterday morning, one client started being blocked from Internet by the "Default Deny / Policy Violation" built-in rule when on wifi. On wifi, the client has access to everything on the local network including OPNSense management. I can change the client IP but the blocks persist.

The client is a Lenovo T440 laptop running Windows 10. OPNSense is 23.7.12-amd64. APs are Cisco 2702 in autonomous mode. Nothing has been updated recently or configs changed.

When I connect the client wired (same VLAN/ subnet), it works.

This setup had been running great for years.

For completeness, I will add this:

1. Several months ago, I added crowdsec to OPNSense. After a couple of months, crowdsec went berserk and blocked a couple of internal IP addresses (including my internal DNS server.) I disabled crowdsec.

2. I tried the 24.1 upgrade and it screwed up OPNSense. I run OPNSense on ESX, so I reverted to the pre update snapshot to get back to 23.7.

Both of these events happed weeks before this new issue started.

Any ideas? Have can I see exactly what policy violations are occurring in order to figure this out? I'm sure it must be in the logs somewhere, but I haven't found anything that looks like a smoking gun.

Shouldn't need it. The virtual IP on my WAN is 192.168.223.1/24 which is in the same subnet as the devices (192.168.223.233 and 192.168.223.224).

Besides, from the LAN I can communicate correctly with the bridges. It's when the bridges establish the connection that things fail. If I ping an internal server from the bridge, I can see the ping requests at the server (via Wireshark). I can see the pin replies going back to the bridge's IP. They just never get there.

I'm using a pair of Ubiquity wireless bridges to get my Starlink signal into OPNSense. The Starlink router is set to bypass (think bridge mode). The Starlink dishy gives OPNSense WAN interface a (CGNAT) DHCP address. This all works as expected.

I want to be able to access SNMP and the web interface on the bridge units so I assigned them IP addresses 192.168.223.223/24 and .224/24. Their default gateway is 192.168.223.1

I added a virtual IP on OPNSense's WAN interface for 192.168.223.1/24. This indeed lets me access the bridge units from my LAN subnet. So outbound traffic from the LAN to the bridges works.

However, I'd also like for the bridges to be able to do ntp and syslog into a server on my LAN, so I added a rule to allow WAN traffic from 192.168.223.0/24 into my LAN. This is where it gets interesting: traffic from the bridges makes it into the server on the LAN (I can see this with wireshark), BUT return traffic from the server to the bridges never makes it to the bridges. I have verified the source address of the packets as observed in wireshark are indeed the 192.168.223.x addresses.

But I can ping the bridges from the server. This is what makes it so odd. It's like inbound traffic doesn't get a state associated with it and gets dropped.

Any ideas?

I'm trying to create a shaper rule to tame Microsoft windows updates (even one PC updating will clobber my DSL connection). I've found a way to more or less get all the IP addresses Microsoft uses as Windows update hosts.

My thinking is that I'd run a script periodically to collect the windows update IPs and use the OPNSense API to add them to an alias. I could then use the alias and build a traffic shaping rule to limit those hosts to a collective 1Mb/sec.

If I try to create a shaper rule using an alias as a source or destination address, I get an error message telling me to enter a valid network address.

Are aliases not usable in shaper rules?

Did that - same issue.

When I run OPNsense (latest version) under ESX 6, it works ok for a few minutes, but after 10 minutes or so performance goes south. I see speedtest.net and fast.com results drop, and the latency reported by speedtest.net (using the same speedtest destination server) doubles or triples.

If I go into the shaper and just create a pipe, performance drops even more.

OPNSense shows very little CPU used.

The same setup runs Sophos SG UTM, Sophos XG, and pfsense without issues.

I use E1000 virtual NICs. I've insured that all the NIC offloading is turned off in OPNSense (although I've tried turning it on with no difference).

My ESX server is a quad core AMD with 16GB ram and two NICs. One NIC connects to a Cisco 800 series DSL router, the other NIC connects to my internal network (one subnet, no VLANs). Each physical NIC connects to a an inside and outside vswitch, and the OPNSense virtual has two vnics - once connected to the inside vswitch, and one connected to the outside vswitch.

My DSL is 3Mb/768k. With either of the Sophos firewalls or pfsense, speedtest.net and fast.com will show very close to those numbers.

OPNSense will start off at close to those numbers, but within 10 minutes will drop to 1Mb. If I create a traffic shaper pipe (no queues, no rules), the speed drops to 100kb. If I delete the pipe, the speed stays 100k until I reboot.

Any ideas?

I am seeing this same behavior. I have ipsec set up between an OPNSense system and a Sophos SG UTM. Both sides have dynamic IP address and I use DuckDNS to track names to the IP addresses. I have verified that DuckDNS is being updated by both sides when an IP address changes.

The VPN works great until the IP address of the Sophos side changes. OPNSense can "see" the new ip address (if I ping xxxx.duckdns.org from the OPNSense CLI, I get the right ip). However, the VPN stops working. Currently, I reboot OPNSense and everything starts working until the Sophos UTM's ip changes, then it breaks again.

Sophos seems to handle a change to the OPNSense side's ip without problem.

And how would one track that down and fix it?

After updating to 18.1.7 I noticed that I was not getting snmp data from opnsense. Looking at the dashboard, I could see that the snmp service was stopped. Attempts to start didn't work.

Looking in the log, I could see this error:

snmpd[24875]: error in config file
snmpd[24875]: in file /var/etc/snmpd.conf line 11

Looking at line 11 in that file shows this line:

begemotSnmpdPortStatus..161 = 1

Editing the file to remove the extra "." and starting the service from the GUI resulted in the same error. Looking at the file, I can see the bad line has been added back.

The temp workaround is to edit the file, removing the extra ".", than starting the bsnmpd service with:

/etc/rc.d/bsnmpd onestart

EDIT: It looks like much more breaks as well. It appears the UCD-SNMP-MIB (1.3.6.1.4.1.2021) MIB is no longer working., even though the "UCD" option is checked in the SNMP configuration.

When I get the amount of memory present using an SNMP get of 1.3.6.1.4.1.2021.4.5.0, it agrees with what the dashboard shows. However, getting the amount of free memory (1.3.6.1.4.1.2021.4.6.0), show much less free memory than what the dashboard shows.

Which is correct? Where does the dashboard get its memory stats from?

Is there a better OID for getting the free memory?