Topics

I recently upgraded my OPNsense firewall hardware that I had been running for 5+ years and I am running into a weird issue with DNS port forwarding that I didn't see on my previous appliance. I am running Adguard Home via the repository and I configured port forwarding for TCP/UDP 53 to 127.0.0.1. It works fine but I have a few IoT devices that are sending parallel DNS requests to the firewall LAN address (DHCP DNS address), 8.8.8.8 and 1.1.1.1. Most of the time 2 of 3 requests are responded to and the third on is dropped. In the firewall log I see a block for the port forward PASS rule (if I change to an associated rule I see a drop for that). I checked the Adguard Home logs and I don't see the third request. I never had this issue with my previous appliance so I am trying to figure out what could be different (other than the system being faster). I have done packet captures for those devices and can see the 3 DNS requests hitting the firewall and one will be flagged with DNS response missing. Is there anything that can be tweaked to handle simultaneous UDP DNS port forwards from the same client to 2 different destinations. This is more of cosmetic issue since the client always gets at least 2 responses and nothing breaks. But getting a block for a PASS rule in the log is annoying.

I do very minimal filter logging with my OPNsense implementation for home use but I always wanted slightly better filter log views. I have been using Telegraf, Influxdb, Packetbeat & Grafana for general system and DNS monitoring. I finally decided to spend a little time to work on adding in the filter log and it turned out be relatively straight forward for the limited fields I needed (source, destination, destination port, rule number and label) for IPV4, tcp/udp, and blocks only. Here is the snippet that I added for Telegraf to /usr/local/etc/telegraf.d/custom.conf:

[[inputs.tail]]
  files = ["/var/log/filter/latest.log"]
  from_beginning = false
  pipe = false
  watch_method = "poll"
  name_override = "filterlog"
  data_format = "grok"
  grok_patterns=["<%{NONNEGINT}>%{NONNEGINT} %{TIMESTAMP_ISO8601:timestamp:ts} %{HOSTNAME} %{WORD} %{NONNEGINT} \\- \\[%{GREEDYDATA}\\] %{INT:rulenum},%{DATA},%{DATA},%{DATA:label:tag},%{DATA:interface:tag},%{DATA},%{DATA},%{DATA},%{INT},%{BASE16NUM},%{DATA},%{INT},%{INT},%{INT},%{DATA},%{INT},%{DATA:proto:tag},%{INT},%{IPV4:src:tag},%{IPV4:dst:tag},%{INT},%{INT:dst_port:tag}"]

Attached is the view I configured in Grafana. I just did the rule label translation in Grafana since I only have a few rules which are logging.

The bulk of the effort was fine tuning the grok pattern. I had found several examples but most were from syslog export tools and didn't include everything needed to read directly from the filter files. So far it has been working fine for me.

I am running 22.1.8_1 and anytime my WAN gateway (home cable modem) goes down Unbound constantly restarts until the Gateway comes back online. If I have Gateway monitoring enabled, the firewall doesn't recover on its own. I have to either reboot or manually disable/enable the gateway. With Gateway monitoring disabled, the firewall recovers fine. I don't remember this being an issue in previous releases. I changed Unbound network interfaces to All and that didn't help.

Is this behavior expected or are there other changes I can make to stop Unbound from constantly restarting when my cable modem resets. I am dealing with the cable modem resets separately with Optimum but would like to clear this up on the OPNsense side as well.

It doesn't look like Telegraf is following the log file standard and it isn't displaying at all in the GUI following the upgrade to 22.1. In /var/log/telegraf, it is generating a telegraf.log file instead of one with date format & latest.log. The GUI is not displaying the log info. Attached is a screenshot of my log file and blank GUI screen. It used to display the log file in the GUI fine before the upgrade (I was using rotational logs as well before the upgrade). I did try doing a log reset but it didn't help.

After upgrading to 21.1.9 from 21.1.8 a few hours ago, the Insight Aggregator python process has been pegging the core it is running on at 100%. I tried a reboot and it didn't help. Anyone else running into this issue or have a suggestion? I am running a Netflow data repair now to see if that helps and will try a Netflow reset after that.