Messages

Hi again!

Updated to latest. Looks as it should now. No more logging for the rule which has logging disabled.
This fixed in this version?

OPNsense 25.1.5_5-amd64
FreeBSD 14.2-RELEASE-p2

I couldn't extract related info from the change log... probably a limitation associated with me and not the change log 😮😁

brgs,

Another interesting detail: it looks there are always multiple log entries with the same source port when this happens.
So either a single packet generates multiple log entries or it's the other way round: two packets with the same source port arriving at the same time are causing the issue.

In either case, this screams ,,race condition" if you ask me...

Does this mean that it could be this specific device which is the cause/problem? As I only see this block logging from this particular device?
It's a small box, en external controller, for the solar system I got. It makes "intelligent" decisions how to use the energy from the panels and a large battery. They call it "Hartbeat", and the appliance looks very much like a "rasp in a box".
You cannot view this attachment.

Could be the same as https://forum.opnsense.org/index.php?topic=45801.0 but I haven't checked the details.

I read through that. Looks very much as it could be related to what I have here. Await when the "fix" is in a release or a patch is available.

I'll put my feedback here then. Pausing my own troubleshooting.

And.

And in that case it was about IP options...

I tried it out. IP options and change source to Any. Still got block in logs.

Live and prosper 🖖

Many thanks to everyone putting time, brain and keypushing into this!

And sorry for the noise.

Brgs,

What the fork!

I just edited so yaml just have 0.0.0.0 and restarted AdGuard service. Now it works!
So odd, as I tested this back and forth to be sure that it only worked when I hade 127.0.0.1 in there.

I'm confused. Maybe should change the subject on this thread "inconclusive case"

Code Select Expand

root@fw:/usr/local/AdGuardHome # drill @127.0.0.1 svt.se
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 65417
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; svt.se.      IN      A

;; ANSWER SECTION:
svt.se. 2908    IN      A       13.248.174.171
svt.se. 2908    IN      A       3.33.226.205

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Mon Mar 31 17:17:37 2025
;; MSG SIZE  rcvd: 56
root@fw:/usr/local/AdGuardHome # cat AdGuardHome.yaml
http:
  pprof:
    port: 6060
    enabled: false
  address: 10.23.1.2:3333
  session_ttl: 720h
users:
  - name: admin
    password: ***********
auth_attempts: 5
block_auth_min: 15
http_proxy: ""
language: en
theme: auto
dns:
  bind_hosts:
    - 0.0.0.0
  port: 53


Patrick M. & Hausen cookiemonster

Strange. Maybe I made a blunder going through the Setup guide initially then if 127.0.0.1 was an option to include.

But to make things obvious here. If you guys use nslookup in a shell and set server to 127.0.0.1 you get answers? Mine didn't until I added 127.0.0.1...
Trying to figure out if my install is "borked" or what can be going on here.

I think it's because of something is/was wrong with the state of the connection but I don't know right now how to replicate it.
E.g. with asymmetrical TCP connection, for a return package when the firewall has no matching state.

Thank you.

I've done captures and I can't see any asymmetrical traffic. Should be rather simple to see, traffic going out on one interface (mac) and in on another?
Is there a way to see if the "rouge" device is spoofing mac and be that creates asymmetrical traffic (this is way beyond my network experience and knowledge so guy-guessing i bit here.)

Question still remains. Why does it log it? 😁 As you can see in the logs it's like every minute this "rouge" device is "attacking" external name servers. Logs get pretty useless when spammed like this.

Hi!

If I interpret what you say here, it is about how Unbound handles answering on 127.0.0.1.

More generally, how 127.0.0.1 is bound as an interface. 0.0.0.0 binds to all interfaces but not the loopback 127.0.0.1 because "it's a bit special" as I understand it.

It was not easy to find a good reference for this. Two different AI explained it rather well though, but for a human-generated explanation, I found this https://stackoverflow.com/questions/20778771/what-is-the-difference-between-0-0-0-0-127-0-0-1-and-localhost

Editing the YAML for AdGuard and adding 127.0.0.1 so it listens on that makes it behave more like Unbound's default settings in OPNsense. "Do not use the local DNS service as a nameserver for this system" is default off and Unbound answers on 127.0.0.1.

Is that more correct?

Hi!

Encountered this when mocking around with DNS redirects, AdGuard Home set as primary (53) and unbound at 8053. I wanted the redirect to go to loopback:53. (note: Unbound usage. Forwarding my local domain suffix to unbound:8053 to get hosts resolving and reverse lookups.)

AdGuard not answering... until i added 127.0.0.1 to bind_hosts in AdGuardHome.yaml @ /usr/local/AdGuardHome

Code Select Expand

dns:
  bind_hosts:
    - 0.0.0.0
    - 127.0.0.1
  port: 53

BSD by default doesn't bind loopback interface when specifying only 0.0.0.0. Linux does...
Unbound does answer on loopback by default as I understand it.

Don't know if mimugmail lurks the forums here. If so, any comment on this? Should the above bind be set as default maybe? It conforms more with the behaviour of unbound implementation then.

For ref. nslookup tests:

Code Select Expand

> set port=8053
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#8053
> dn.se
Server:         127.0.0.1
Address:        127.0.0.1#8053

Non-authoritative answer:
Name:   dn.se
Address: 34.117.105.189

> set port=53
> dn.se
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   dn.se
Address: 34.117.105.189


Might be a coincidence but I've noticed that all the timestamps end in ~55s.
Could this be caused by some scheduled job that runs every N minutes, like the table update?

Hi! Thank you for checking in on this.

The device to blame here looks like it do stuff at an interval, it's an IOT, solar panel central, which I don't have that much control over. As mentioned it hunts down external name resolving like a "mad man". It's in this "hunt" opnSense generates a block.

But the interesting thing is why opnSense generate a log at all when I have logging disabled (not checked) on all affected rules and forward... 😮
The logs above I have enabled logging to see what and when the block is shown. It's a PASS rule so shouldn't see block logging anyway (to  my understanding)

As a test I created a rule directly on the interface, VLAN10IOT_hn3.
A PASS rule with logging enabled.
You cannot view this attachment.

Checking the log I get this. Something triggers a BLOCK.
You cannot view this attachment.

If turn off logging the PASS logging disappears but the BLOCKs are still generated.

Also tried replacing the rules destination from the alias to just the ip address. Same-same block are logged 🤪
Here I also turned on loggin for the Port Forward.
You cannot view this attachment.

I'm stuck. Don't know what else to try here.

I'm not making myself clear, no worries and your forwarding rules is probalby correct. What I meant is, does your port forwarding rule look similar to the following, second entry (interface would be different, of course)?

You cannot view this attachment.

Here is the port forward, attached png.
I've been toying around with like everything so maybe that alias for internal DNS contains to many IPs right now. It should be enough with .32.1 and .32.6

You cannot view this attachment.

The purpose is to block doh/dns to be accessed externally from any network on the inside. All resolves should go through internal DNS.

1/ You cannot block DoH (usually port 443) nor DoT (usually port 853) by redirecting port 53.
2/ You cannot redirect DoH/DoT in this way even by redirecting the proper ports - since it breaks the encryption (certificates).

Would suggest reviewing the following, e.g.:
https://developers.google.com/speed/public-dns/docs/dns-over-tls
https://developers.google.com/speed/public-dns/docs/doh

Hi!
Thank you.

• I'm blocking known Do* servers not trying to redirect DoH or DoT. Purpose is to make the device resort to normal DNS-request and from there be redirected to internal DNS.
• Have that understanding

But the curiosity that made me start this subject was that I got block logging when not having a log enabled rule and on top of that it's a PASS rule.

Sorry for my messy answer here. I've edited and added stuff while composing this.

Port Forward rule
from: !hosts_lan_DNS (from everything that is not a DNS-server)
to: !net_IP_rfc1918 (not destined for a local network)
dest: 192.168.32.1
port: 53
Linked rule: ...

Maybe first another question: what is the point of this forwarding rule, you want to redirect external UDP/DNS queries to .32.1?

You have set no source proto & port, or are they set to UPD/53 for source and destination? (Sorry it's early) What I meant is you have set destination to !net_IP_rfc1918, port 53 and forward it to .32.1, port 53 - and proto for this rule is set to UDP, on what interface is this rule?

The purpose is to block doh/dns to be accessed externally from any network on the inside. All resolves should go through internal DNS.
To allow two LAN DNS (.32.1 and .32.6) to access external doh and dns.
DHCP on all interfaces gives out two DNS .32.1 and .32.6.
Host 192.168.88.30 connected to VLAN10IOT_hn3 ignores this and tries to connect to a bunch of DNSs externally...

you have set destination to !net_IP_rfc1918, port 53 and forward it to .32.1, port 53 - and proto for this rule is set to UDP

I can't see that I have such rule or am I missing something here? What description do you see for the rule you're referring to here?
The Port Forward looks a bit what you referring to.
To my understanding this should Port Forward traffic that is not from my internal DNS and not having a destination to any internal address.

from: !hosts_lan_DNS (from everything that is not a DNS-server)
to: !net_IP_rfc1918 (not destined for a local network)
dest: 192.168.32.1
port: 53
 
hosts_lan_DNS is a host alias with internal dns addresses.
net_IP_rfc1918 is a net alias for private networks 10,127,192...

I have on the interface VLAN10IOT_hn3 just one rule that lets everything out if it's not rfc1918. It's the last rule on the interface.
"dns allow hosts_lan_DNS" is a floating rule for all internal interfaces.

It's an allow rule and it shows the block in logs. This role in combination with the Port Forward works as it should. Devices on any internal interface which tries to resolve names externally is redirected.

I don't get this log block message from other devices than this particular device 192.168.88.30 though... Which is strange.

As the logs fills up with this block message from "dns allow hosts_lan_DNS" I would really like to figure out why a PASS rule logs a block 😁

Did you change the floating rule from block to pass? Or do you have another rule with the same name?

A pass rule would not block, it eithers match and allows what it is supposed to allow. Or not match and not do anything.

Hi!

Name/description. No, I've checked and also changed the description to be sure it this rule I see in the logs. Also click the RID-link opens up the correct/this rule, "dns allow hosts_lan_DNS".

Yes, the rule has been a PASS rule since the beginning. What I've toggled is logging on or off. But for this specific host, 192.168.88.30, it still shows a block in the log. I started out with a linked rule from the Port Forward, it showed the same behaviour.

The first three rules is behaving like this. Logging is off but log shows a block anyway. There should only be one of the three active, but as I'm troubleshooting this I've tried a some variations on it.

Also captured traffic from this specific host to try to see what's going on. Not sure what I'm looking at as I'm not the well versed in Wireshark.

Attached the rule set from VLAN10IOT