IPv6 always resolves to localhost
Today, I noticed an unusual behavior with Firewalla's DNS. It resolves many devices on my network to the IPv6 address :: (unspecified address), even though I have IPv6 completely disabled on my network. I’m puzzled as to why Firewalla is attempting to provide IPv6 addresses at all in this setup.
This issue seems to primarily affect my Linux servers, as far as I can tell. I’ve tried enabling IPv6 for my LAN temporarily to see if it changes anything, but the behavior remains the same. Firewalla still resolves hosts that don’t have IPv6 configured to ::.
Is there a way to configure Firewalla to stop returning IPv6 addresses altogether—especially for devices that don’t have an IPv6 address assigned? This behavior feels like a bug to me, but I’m not entirely sure.
I first noticed this issue today when I was trying to SSH into a new host that didn’t yet have an SSH server configured. To my surprise, the connection attempted to fall back to my local machine (loopback). After troubleshooting with ssh -vvv, I observed that SSH first tried the IPv4 address, which was rejected (as expected), but then it fell back to IPv6 and attempted to connect to ::. This resulted in SSH unexpectedly connecting to my localhost, which is odd behavior. I’ve since disabled IPv6 in my SSH client as a workaround, but this isn’t an ideal solution.
If anyone has encountered this or knows how to configure Firewalla to avoid returning the :: address, I’d appreciate your advice!
-
Is there a solution or workaround to avoid this? I'm seeing it a lot for local server names that resolve to 192.168.10.x, 192.168.15.x, other IPs on local VLANs - the Firewalla also returns a bogus :: AAAA record, confusing a lot of processes that are trying to connect to the servers.
-
Sample. One internal server, querying for another, via the firewalla router IP as resolver. In reality, the host qbit.nat.cosanostra.net ONLY has an A record, and resolves accordingly from the open internet. The gold pro has decided to generate a false :: answer which is loopback, not an empty/non-answer. It doesn't do it for all hosts, it doesn't do it for all interfaces on different VLANs of the same host, and it sometimes comes and goes.
r740:~# host qbit.nat.cosanostra.net
qbit.nat.cosanostra.net has address 192.168.15.18
qbit.nat.cosanostra.net has IPv6 address ::
r740:~# dig @192.168.15.1 qbit.nat.cosanostra.net a
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @192.168.15.1 qbit.nat.cosanostra.net a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26010
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;qbit.nat.cosanostra.net. IN A
;; ANSWER SECTION:
qbit.nat.cosanostra.net. 0 IN A 192.168.15.18
;; Query time: 2 msec
;; SERVER: 192.168.15.1#53(192.168.15.1) (UDP)
;; WHEN: Sun Mar 23 19:06:26 EDT 2025
;; MSG SIZE rcvd: 68
r740:~# dig @192.168.15.1 qbit.nat.cosanostra.net aaaa
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @192.168.15.1 qbit.nat.cosanostra.net aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51271
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;qbit.nat.cosanostra.net. IN AAAA
;; ANSWER SECTION:
qbit.nat.cosanostra.net. 0 IN AAAA ::
;; Query time: 1 msec
;; SERVER: 192.168.15.1#53(192.168.15.1) (UDP)
;; WHEN: Sun Mar 23 19:08:05 EDT 2025
;; MSG SIZE rcvd: 80
-
For what it's worth, I've started manually adding the A record under "Custom DNS rules" when I see the problem pop up, which seems to stop it from generating a bogus AAAA record. But that's not scalable, won't handle any records besides A type as far as I know, and could cause internal DNS and external DNS to get out of sync in the long run. I keep everything in DNS for consistency, having to duplicate records in the firewall manually doesn't really help that.
If this is a partial attempt at something related to DNS Rebind protection or similar, it needs to be configurable. I expect public DNS to return valid RFC1918 addresses for my internal networks without extra junk records that break stuff.
Please sign in to leave a comment.
Comments
7 comments