Messages

Its not a fix but a workaround. I switch on dnsmask when i need the remote domain.

You could add dnsmask as a dns-server to unbound. Ugly but doesnt includes adding all the single hosts to the override file.

You probably mean you switch on dnsmasq locally on OPNsense when you need the remote DNS server?
Yes, that is doable.
m

If you can access a shell on the firewall host, there is a command to look at the status of wireguard, latest handshake, addresses allowed, etc.:

Code Select Expand

wg show

I have my firewall rules in the WireguardGroup "interface" to allow traffic to and from the tunnel.
Also, I used

Code Select Expand

tcpdump -i wg0
to look at the traffic flowing in and out of the tunnel.
Both commands can be done at either end of the tunnel.

I hope the extra information helps to find the problem.

Cheers,
Michiel

8) That is great news.... Support in dnsmasq.

dnsmasq is lightweight, highly configurable... has been around for so long, so lots of help/ support available on public forums.
I would use dnsmasq over anything for a lightweight resolver.

I agree. Dnsmasq has served me well during years and years.
I was reminded of the smoothness of the dnsmasq experience over the years, when I tried to battle through unbound quirks during the past couple of days.

Strictly speaking, of course.  ;)

Michiel

I have used a workaround for now.
Unbound does still not successfully parse the response from my older nameserver for NED, so I decided to add 'host overrides' in unbound for the most important hosts in the NED network.

See menu:/Services/Unbound/Overrides/Host Overrides
Not very neat, a bit of a hack, but usable for the time being.

Thanks for the support,
Micihiel

[3]

On the dashboard: FreeBSD 14.1-RELEASE-p3

Code Select Expand

# kldload agp
module already loaded or in the kernel


Correct.

Michiel

Rebooting as we speak.
Wait for it...
wait for it...
Yes, it booted. The patch seems to work.

Meh, dumb, I called it 23.7.3-agp

[3]

Rebooting as we speak.
Wait for it...
wait for it...
Yes, it booted. The patch seems to work.

Meh, dumb, I called it 23.7.3-agp

I must admit, I am about to give up on this. I have spent the last three days, going through logs, tcpdumps, and even looked at some source code of unbound, albeit not in the right spot.

I will experiment further with running dnsmasq as my internal root servers for the internal domains, without all the strict controls of unbind. I cannot afford to dive deeper or spend more time, especially if that leads me away from managing the firewall via the GUI.
It feels like defeat, but it is what it is.

Sorry for bothering you with this.
Michiel

On

Code Select Expand

opnsense-update -zkr 24.7.3-agp
No signature found.
opnsense-update -zfikr 24.7.3-agp
No update found.

Did you remove the kernel already?
Cheers,
Michiel

Mark from FreeBSD provided a patch so I built a test kernel with agp reenabled and the fix in place.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281035#c8

# opnsense-update -zkr 24.7.3-agp

Just in case to recover reboot into kernel.old from the boot menu (if possible).

Though it looks like the most likely fix at the moment. To confirm-confirm test if agp was already loaded when it boots ok when initial 24.7.2 would not:

# kldload agp

Should complain about already being loaded. :)

Though we will probably keep the driver disabled by default unless it creates other problems with 23.7.3. Only one way to find out either way.



Cheers,
Franco

I will have a try today. But first I wall save and export my current config...  ;)

Mark from FreeBSD provided a patch so I built a test kernel with agp reenabled and the fix in place.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281035#c8

# opnsense-update -zkr 24.7.3-agp

Just in case to recover reboot into kernel.old from the boot menu (if possible).

Though it looks like the most likely fix at the moment. To confirm-confirm test if agp was already loaded when it boots ok when initial 24.7.2 would not:

# kldload agp

Should complain about already being loaded. :)

Though we will probably keep the driver disabled by default unless it creates other problems with 23.7.3. Only one way to find out either way.



Cheers,
Franco

Code Select Expand


server:
do-udp: no


IIRC. Read the man page.

Ah, yes, when hacking the config files is allowed  ???
I restricted myself to using the OPNsense GUI, but yes...

Do you see a log message "parse error on reply packet"? If not, it'd have to be eDNS, I think?

Indeed I'd perhaps start with making unbound use TCP only.

I seem to remember vaguely that I have seen such a setting, but I cannot find it at the moment. Unbound currently is sending an receiving UDP packets.

As for the "parse error on reply packet": I do not see that.
I am seeing "parse error on response packet".
I am also seeing that Unbound detects that the 'ned' server is EDNS capable.

m

So I have a piece of the log on level 5 debug selected and saved, but it is not making me any wiser  :(

The UDP response received seems to be binary, but it is not decoded.


Michiel

I had to kill all users (disconnecting cables  ::) because I am flooded with log messages if not.

I scrolled the log (verbosity at 5 at the moment).
I have seen the query going out and a response coming in as UDP packet. Roundtrip time 17msec

I see UPD responses coming in but they are not decoded. It is sending the query to the right server, requesting the right records 'IN A' and it noticed a response from the said server over UDP.

That sure is sifting through a lot of log!

Selecting on 192.168.11 omits the response. It does several tries each with a response received.
It is shows

Code Select Expand

serviced query: EDNS works for ipv4 192.168.11.2 port 53 (len 16) one time, attempts four queries:

Code Select Expand

sending to target: <ned.> 192.168.11.2#53

, each with a response received and fails the parse.

I admit I have no idea what I am supposed to be looking for. I have noticed though, the queries to other servers seem to have the decoded responses in text in the log, and the responses for 'ned' do not.

Start at https://github.com/NLnetLabs/unbound/blob/b5951ce1fa30b64b4fb079e36d5d98d57fb53372/iterator/iterator.c#L646-L650

Do you see a log message "parse error on reply packet"? If not, it'd have to be eDNS, I think? https://github.com/NLnetLabs/unbound/blob/b5951ce1fa30b64b4fb079e36d5d98d57fb53372/iterator/iterator.c#L4311-L4321

Were you able to capture a response with tcpdump?

I have just posted the exact error message. It uses the word 'response' so your first link is accurate. Thanks.
However, in the mean time I am totally confused, because I see neither a query by unbound nor a response in tcpdump.
It must be me slowly going mad!  :-[

I am not surprised there would be a parse error on a non-existent response. Why do I not see the query going out?

Michiel

WTF?

Code Select Expand

tcpdump -v -i wg0

shows queries going accross the tunnel, whit

Code Select Expand

dig @192.168.11.2 <hostname.ned>

But

Code Select Expand

dig <hostname.ned>
shows noting at all. Not even a query.

Still, the error in the unbound log shows it could not parse the result. It also shows it knew where to send the query, because the nameserver address is correct.  ???

Code Select Expand

[79782:1] error: SERVFAIL <hostname.ned. A IN>: all the configured stub or forward servers failed, at zone ned. from 192.168.11.2 could not parse upstream response

It appears to understand it has to query 192.168.11.2, but it doesn't?
Tcpdump tells me it seems to not even query the server!

Time for a coffee.
michiel