unbound with ULA: connection timed out (nslookup)?

Bob.Dig

... Although it is not exactly for your problem, maybe it helps.

Or you just have missing firewall rules.

the other

@jasonau
I can see it when using GUA, not when using ULA.
If I set ULA in RA DNS Servers field, I can resolve via using my browser. Nslookup still timing out when using fd:... although it ist entered in /var/etc/radvd.conf

Well, it is working (the only flaw is that time out with ula IP for unbound). Internet browser finds sites with ula as well as gua in /var/etc/radvd.conf...
Thanx for your answer :)

the other

@bob-dig
Firewall rule should not be the issue, tried even with allow all for port 53 on vlan interface...
So...no practical issues, but still not working with
nslookup -query=AAAA google.com pfsense-ula-ipv6

Patch did not change anything...since an ugly flu is just coming up, I give this curiosity (and myself) a rest.
Was just wondering, if I missed something obvious...thanx for your input

johnpoz

@the-other not able to duplicate your problem.

Setup a ula vip on my pfsense lan

fd10:a945:372f:6c84::1/64

Setup unbound to listen on this VIP

Made sure my firewall rules and unbound acl allowed for ula range fd00::/8

Set my pc up with a IPv6 ula address in this range fd10:a945:372f:6c84::2/64

And query and it works fine..

Few things to keep in mind, you need to make sure unbound is listening on this vip.. If your using auto ACLs in unbound you need to make sure set to allow from your ula range. Or set it them manually to allow.

You can view them with
cat /var/unbound/access_lists.conf

You need to make sure your firewall rules on this enterface allow for udp/tcp 53 from your ULA range, etc. Keep in mind that rule of Lan Net or OptX Net as source isn't going to include some vip ULA address.. You would need to make sure your firewall rules specifically allow for your ULA range or the whole ULA block, etc.

Now I am on 23.01, maybe there is something wrong with 2.6? But not sure how that could be really, it comes down to is unbound listening on this ULA address, does its ACLs allow queries from ULA address range. Do the firewall rules on the interface allow for dns port from ULA range, etc.

Validate unbound listening on the ULA address, sockstat come in handy here

You say its working with your gua - so its not like you set unbound to not do Ipv6 with the do-ip6: no in custom options or something.

the other

@johnpoz
I erased all my steps and started fresh...did everything as you wrote (pretty sure that's what I had)...

AND IT IS WORKING!! Thank you very much @johnpoz

Don't know, maybe had a typo anywhere. It is all well and the little voice in my head that was ickering about it is quiet now... :)
Have a nice weekend!!

johnpoz

@the-other glad you got it sorted.. Hope you have a great weekend as well!

Out of curiosity if you don't mind - other than a learning experience, why do yo want ula.. I just do not see the point, you have a gua right.. What what is the purpose of the ula for your use case? Just curious..

Seems to me it just another layer of complexity.. I don't see the value in it. Your already running a dual stack with rfc1918 and IPv6.. You sure do not need even to access pfsense via IPv6 for dns for IPv6 to work - you can just as easy use the rfc1918 address you have locally for dns it can lookup AAAA etc..

Now some point in the future when we are not running IPv4 and need stuff to talk to each other on local networks, stuff that doesn't have a gua ok makes sense then. And then only if you had to route stuff across segments, or the link-local could be used.

I could see setting it up for a learning exercise, but soon as that was done with - I would remove them.. The ula I setup for testing is already been removed.. I have zero use for it.. And can not even think why I might want to use it currently with the state of the transition to IPv6.. I have gua /48 I can use if I want something to use IPv6, locally my device just use IPv4 via rfc1918 and don't see any time soon where I would even need to fire up or even allow for any IPv6 communication between really any of my devices, etc.

Complexity only adds more points of possible failure ;) KISS is my motto!

the other

@johnpoz
Hey there,
well, it is a dynamic GUA, changing in unspecific intervals by ISP (Germany)...
so, although I could set everything on automatic getting a working connection (the GUA is handed out), I quite like it to configure manually (setting Gateway and DNS and such). Since my GUA is changing I thought I would get that done with giving out ULAs as well. So for IPv6 I use ULA for routing in LAN...beteeen vlans.

To be clear: this is just for the heck of it, a hobby, trying to do this and that with my network. So yeah, a learning experience.
And yeah, everything is kinda "double" for DNS was working via IPv4 as well. It's rather an approach to play with IPv6 and learning by doing...
:)

SteveITS

@johnpoz Without looking it up :) I’m assuming Bob’s patch above is the one for pfSense setting incorrect unbound ACLs using IPv6

Yeah its quite possible problem with that - I don't actually use auto acls, I use manual

But I don't believe even auto would take into account a vip? And sure there could be a problem, and track for IPv6 prefixes that change could be a problem..

I was just trying to point out the stuff to validate if not working, etc.

eightfold

Hate to bring up an old topic here, but I am also having this issue and have been struggling to figure out why. Given that I know I'm not the only that experienced this (I also found at least 1 other topic on this issue), I'm almost certain there's some sort of bug with Unbound.

My setup is as follows:

I have a Virtual IP configured as fd01::1/64 on my LAN interface (igc0)
I have Unbound setup to listen on that interface and I've already added the entire ULA subnet to the access list.
I am certain my firewall rules are not the issue here as even adding a floating rule with a Default Allow All on my LAN interface did not make a difference

You can see below the relavent configuration lines in my setup:

[24.03-RELEASE][admin@gateway.home]/var/unbound: grep -F fd01 *.conf
access_lists.conf:access-control: fd01::/64 allow
unbound.conf:interface: fd01::1

Below you see the ULA virtual IP assigned to my LAN interface:

[24.03-RELEASE][admin@gateway.home]/var/unbound: ifconfig igc0
igc0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: LAN
        options=48020b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,HWSTATS,MEXTPG>
        ether 90:ec:77:8b:44:db
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
[...]
        inet6 fd01::1 prefixlen 64
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

And finally the network interface being shown that it's listening on the ULA on port 53:

[24.03-RELEASE][admin@gateway.home]/var/unbound: netstat -an | grep fd01
tcp6       0      0 fd01::1.53             *.*                    LISTEN
tcp6       0     44 fd01::1.22             fd01::c10b:40d4:.58886 ESTABLISHED
udp6       0      0 fd01::1.53             *.*
udp6       0      0 fd01::1.123            *.*
[24.03-RELEASE][admin@gateway.home]/var/unbound: sockstat | grep -F fd01
unbound  unbound    33807 7   udp6   fd01::1:53            *:*
unbound  unbound    33807 8   tcp6   fd01::1:53            *:*

These are the IPs of the host machine I'm testing from:

robot@x201:~> ip a s to 192.168.1.0/24
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.1.83/24 brd 192.168.1.255 scope global dynamic enp0s25
       valid_lft 4232sec preferred_lft 4232sec

robot@x201:~> ip a s to fd01::/64
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet6 fd01::5853:1717:110e:6b2c/64 scope global temporary dynamic
       valid_lft 86164sec preferred_lft 14164sec
    inet6 fd01::f2de:f1ff:fe2c:704f/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86164sec preferred_lft 14164sec

So, everything should work right? Well it doesn't. Here's the output I see when I try to do a query against my pfSense box:

robot@x201:~> host -t a dns.google 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:

dns.google has address 8.8.8.8
dns.google has address 8.8.4.4

Wed 05 Jun 2024 08:05:06 AM MDT

robot@x201:~> host -t a dns.google fd01::1
;; communications error to fd01::1#53: timed out
;; communications error to fd01::1#53: timed out
;; no servers could be reached


Wed 05 Jun 2024 08:05:20 AM MDT

And here's the tcpdump on my pfSense box showing it's receiving the query but never replying:

[24.03-RELEASE][admin@gateway.home]/var/unbound: tcpdump -nni igc0 host fd01::5853:1717:110e:6b2c and port 53 or host 192.168.1.83 and port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igc0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:05:06.574576 IP 192.168.1.83.42352 > 192.168.1.1.53: 54442+ A? dns.google. (28)
08:05:06.734561 IP 192.168.1.1.53 > 192.168.1.83.42352: 54442 2/0/0 A 8.8.8.8, A 8.8.4.4 (60)
08:05:10.760721 IP6 fd01::5853:1717:110e:6b2c.42040 > fd01::1.53: 53979+ A? dns.google. (28)
08:05:15.765258 IP6 fd01::5853:1717:110e:6b2c.41654 > fd01::1.53: 53979+ A? dns.google. (28)
^C
4 packets captured
14494 packets received by filter
0 packets dropped by kernel

So I'm not sure what else there is to do here. Maybe I'm stupid and I missed something, but none of the configuration changes I've done made any difference. Perhaps someone here can shed some light, because I'm at a complete loss.

Edit:
I should also add, you can see above that sshd is also listening on that interface. Just to further show this isn't some sort of firewall issue, I can ping and ssh from the same host machine without any issues:

robot@x201:~> ping -c3 -I fd01::5853:1717:110e:6b2c fd01::1
PING fd01::1 (fd01::1) from fd01::5853:1717:110e:6b2c : 56 data bytes
64 bytes from fd01::1: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from fd01::1: icmp_seq=2 ttl=64 time=0.111 ms
64 bytes from fd01::1: icmp_seq=3 ttl=64 time=0.136 ms

--- fd01::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2017ms
rtt min/avg/max/mdev = 0.111/0.180/0.293/0.080 ms

Wed 05 Jun 2024 08:22:27 AM MDT

robot@x201:~> ssh -b fd01::5853:1717:110e:6b2c fd01::1
Command history storage is enabled. Clear history with: history -c; history -S.
[24.03-RELEASE][robot@gateway.home]/home/robot: logout
Connection to fd01::1 closed.

Wed 05 Jun 2024 08:22:36 AM MDT

Gertjan

If unbound is listing :
@eightfold said in unbound with ULA: connection timed out (nslookup)?:

[24.03-RELEASE][admin@gateway.home]/var/unbound: sockstat | grep -F fd01
unbound unbound 33807 7 udp6 fd01::1:53 :
unbound unbound 33807 8 tcp6 fd01::1:53 :

and you showed it it is, on every existing interface.
And if firewall rules on the concerned interface (LAN ?) is ok, then, for me, on the pfSense side of things, all is well.

Your LAN device should, in theory, prefer IPv6, if avaible, as this is the default for pretty every OS these days.

Example :

C:\Users\Gauche>ipconfig /all

Configuration IP de Windows

   Nom de l’hôte . . . . . . . . . . : Gauche2
   Suffixe DNS principal . . . . . . :
   Type de noeud. . . . . . . . . .  : Hybride
   Routage IP activé . . . . . . . . : Non
   Proxy WINS activé . . . . . . . . : Non
   Liste de recherche du suffixe DNS.: bhf.tld

Carte Ethernet Ethernet :

   Suffixe DNS propre à la connexion. . . : bhf.tld
   Description. . . . . . . . . . . . . . : Intel(R) Ethernet Connection (11) I219-LM
   Adresse physique . . . . . . . . . . . : A4-BB-6D-BA-16-A1
   DHCP activé. . . . . . . . . . . . . . : Oui
   Configuration automatique activée. . . : Oui
   Adresse IPv6. . . . . . . . . . . . . .: 2a01:cb19:907:a6eb::c7(préféré)
   Bail obtenu. . . . . . . . . . . . . . : jeudi 30 mai 2024 07:12:38
   Bail expirant. . . . . . . . . . . . . : jeudi 6 juin 2024 02:25:28
   Adresse IPv6 de liaison locale. . . . .: fe80::daa9:bcf8:99cd:717e%11(préféré)
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.6(préféré)
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Bail obtenu. . . . . . . . . . . . . . : jeudi 30 mai 2024 07:12:36
   Bail expirant. . . . . . . . . . . . . : jeudi 6 juin 2024 07:40:24
   Passerelle par défaut. . . . . . . . . : fe80::92ec:77ff:fe29:392c%11
                                       192.168.1.1
   Serveur DHCP . . . . . . . . . . . . . : 192.168.1.1
   IAID DHCPv6 . . . . . . . . . . . : 346340205
   DUID de client DHCPv6. . . . . . . . : 00-01-00-01-26-59-DF-8D-A4-BB-6D-BA-16-A1
   Serveurs DNS. . .  . . . . . . . . . . : 2a01:cb19:dead:beef:907:a6eb:92ec:77ff:fe29:392c
                                       192.168.1.1
   NetBIOS sur Tcpip. . . . . . . . . . . : Activé
   Liste de recherche de suffixes DNS propres à la connexion :
                                       bhf.tld

I do see some fe80::... stuff, but I guess my Microsoft Windows 11 gets a GUA.

Why I do a nslookup :

C:\Users\Gauche>nslookup
Serveur par dÚfaut :   pfSense.brit-hotel-fumel.net
Address:  2a01:cb19:dead:beef:907:a6eb:92ec:77ff:fe29:392c

Not sure why I should introduce ULA's ...
Ok, true, I activated DHCP6 on the pfSense LAN.

eightfold

@Gertjan

Not sure why I should introduce ULA's ...

Although my internet doesn't go down often, when it does, I typically get assigned a new prefix. The ULA is just really there to have a static IPv6 nameserver because the GUA could potentially change.

Anyway I figured out what the problem was. It turns out I am stupid as there was a NAT rule I had in place that was causing the issue. ‍️ So much for all that troubleshooting, but lesson learned!

Gertjan

@eightfold said in unbound with ULA: connection timed out (nslookup)?:

I typically get assigned a new prefix.

Omg.
I just posted this where I was positif about IPv6, and I forgot about those stupid ISPs totally breaking RFC's / IPv6.