Messages

Hi!

https://forum.opnsense.org/index.php?topic=48278.0

Posted it in the above thread under VPN. Correct, or should it be in here 25.7 release?

Hi all awesome people!

I've got this since 25.7. Now on 25.7.1.
/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command '/usr/bin/wg syncconf 'wg1' '/usr/local/etc/wireguard/wg1.conf'' returned exit code '1', the output was 'Name does not resolve: `mywg.domainIhave.yy:55820' Configuration parsing error'

mywg.domainIhave.yy resolves as it should. But using it as peer in wg, wg fails with the above.
Replacing mywg.domainIhave.yy with the IP-address resolves the problem and wg starts as it should after reboot.

This used to work without any problem before the upgrade, that is 25.1.
Any changes made how wg is starting or waiting for stuff?

Brgs,

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.