Messages

FWIW: I mocked around a bit with removing, changing and adding static mappings. Worked as intended.

[No problems this time]

Hi!

And great that you had logs on it. Because... I was not telling everything here, I did the upgrade from _10.

Now I tried again, bumped to latest 25.7.11 first. Restart. Went to 26.1_4 with the console option.

No problems this time.

The only "oddity" I "may" experience was a bit longer delay in getting an IP-address (Windows on wifi is a not a stable platform when loosing gw, dns and internet for a moment... it disconnect and starts hunting for other networks...)

I've attached the upgrade logs here.
Snippet:

Code Select Expand

...
Processing candidates (217 candidates): .......... done
Checking integrity... done (1 conflicting)
- os-isc-dhcp-1.0_3 [OPNsense] conflicts with opnsense-25.7.11_9 [installed] on /usr/local/etc/dhcpd.opnsense.d/README
Checking integrity... done (0 conflicting)
...
Installed packages to be UPGRADED:
dhcp6c: 20250513 -> 20260122 [OPNsense]
hostwatch: 1.0.6 -> 1.0.11 [OPNsense]
opnsense: 25.7.11_9 -> 26.1_4 [OPNsense]
opnsense-lang: 25.7.4 -> 26.1 [OPNsense]
opnsense-update: 25.7.11 -> 26.1 [OPNsense]
os-ddclient: 1.28 -> 1.29 [OPNsense]
os-isc-dhcp: 0.1 -> 1.0_3 [OPNsense]
os-net-snmp: 1.6 -> 1.6_1 [OPNsense]
...
Configuring cron...done.
Configuring system logging...done.
[211/212] Reinstalling isc-dhcp44-server-4.4.3P1_2...
===> Creating groups
Using existing group 'dhcpd'
===> Creating users
Using existing user 'dhcpd'
[211/212] Extracting isc-dhcp44-server-4.4.3P1_2: .......... done
[212/212] Upgrading os-isc-dhcp from 0.1 to 1.0_3...
[212/212] Extracting os-isc-dhcp-1.0_3: .......... done
Stopping configd...done
Starting configd.
Reloading plugin configuration
Flushing all caches...done.
Configuring system logging...done.


Hi!

I'm seeing the same issue when upgrading to 26.1_4.

I can try to grab the upgrade log, but that means I'll have to run the upgrade again. For now I restored my VM so everything works again.

This is what I did, upgrading from the latest 25.x:

• Performed console upgrade to 26.1_4
• After the upgrade no clients received IP addresses
• The ics-dhcp service was missing from the GUI under Services
• Regular clients didn't get an address, and static mappings were not handed out
• Restarted
• Uninstalled and reinstalled the plugin, GUI shows
• Restarted again
• Regular clients finally got addresses, but static mappings still didn't work
• Reverted the VM because the family wasn't happy — devices with static assignments couldn't connect

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)