Weird DNS rebind issue - Chrome/Brave go to the wrong host. Firefox works fine.

pfstyro

@johnpoz I get your confusion - this really doesn't make sense
All performed on the same Windows 10 PC.
Lets say the problematic host is 'ABC.mydomain.net' =FQDN on 172.16.1.50 and it is turned on.
ping FQDN: returns correct IP and packets (172.16.1.50)
enter https://FQDN or http://FQDN, I get the same same rebind attack screen you showed.

Turn off the 'ABC' host
ping FQDN: returns host unreachable
enter https://FQDN or http://FQDN, I get the same same rebind attack screen you showed.

But you got me thinking ...
I have just tried using Brave on a physically different Linux box, that returned the correct web page. So it clearly is something windows related. Thanks - no idea why I didn't try that earlier.

So, why the issue with windows now (apart from the myriad things wrong with windows) - and why does ping then work on that machine?

I did try clearing the cache from all time too ... I am going to try that again ...I'll report back

johnpoz

You sure your windows machine only has 1 NS listed?

Possible windows is appending its search suffix for this fqdn your looking for and that is returning the IP of pfsense.. Or browser is using something in its cache for that fqdn..

so vs looking for abc.mydomain.net its actually asking for abc.mydomain.net.otherdomain.tld and this is returning pfsense IP.

But this is not a pfsense issue - pfsense is reporting to you that you tried to access its gui via fqdn that it is not aware of - which is possible rebind.

pfstyro

@pfstyro No - as I had tried to use private/incognito sessions before I didn't really expect that to work.

Just for good measure - I wiped all browsing data and cookies from both Chrome and Brave - just in case they cross talked.

pfstyro

@johnpoz Yes, It now seems it isn't pfSense - you are quite right. I will go check the idea of an appended domain name. I doubt it - but maybe it has corrupted and gotten in. Thanks

Sorry for the slow reply - had to wait 120 seconds :-)

stephenw10

Yup seeing queries for ABC.mydomain.net.mydomain.net is disappointingly common!

pfstyro

@stephenw10 Well, I set the Windows PC as a fixed IP and the problem disappeared. I thought I had done that before. Windows keeps messing about with things like that at update time - I hate it but need it for some specific apps.

Anyway, I obviously have a dns settings error in my pfSense. Will go hunt for that now.

Thank you for the help. Sometimes you can get so caught up in what you have done and what you think you have done you get lost. Sorry to have wasted your time.

johnpoz

@pfstyro well the trick here is figuring out why whatever fqdn your trying to access is going to pfsense IP..

These browser makes try and use doh these days, even when you don't want them too - its default.. So its possible doh as already mentioned is returning maybe your public IP from whatever domain your trying to look up.. Could you PM the fqdn your trying to access, and can see what the public internet dns says about it, and report back to you via PM.. If your hitting the pfsense wan IP via fqdn is not aware of - you would get the same error..

So I pointed my test fqdn to my public IP, and then flushed my local dns cache and browser cache.. And if I hit in my browser even my public IP I get the rebind error - because the fqdn trying to be access is not A name pfsense is aware of.

;; QUESTION SECTION:
;zzz.testrebind.com.            IN      A

;; ANSWER SECTION:
zzz.testrebind.com.     3550    IN      A       64.53.x.x

As to finding out what exactly your client is asking for - and validate its actually asking unbound on pfsense.. Is to turn on logging of unbound queries.

server:
log-queries: yes

In the unbound custom box..

Better would be prob just sniff on pfsense for your host IP and dns, and then flush all the caching and try access again.. Then you would see the query, and the response, etc..

09:22:16.708113 00:13:3b:2f:67:62 > 00:08:a2:0c:e6:24, ethertype IPv4 (0x0800), length 101: (tos 0x0, ttl 128, id 13061, offset 0, flags [none], proto UDP (17), length 87)
    192.168.9.100.58718 > 192.168.9.253.53: [udp sum ok] 17672+ [1au] A? zzz.testrebind.com. ar: . OPT UDPsize=4096 (59)
09:22:16.708379 00:08:a2:0c:e6:24 > 00:13:3b:2f:67:62, ethertype IPv4 (0x0800), length 105: (tos 0x0, ttl 64, id 3277, offset 0, flags [none], proto UDP (17), length 91)
    192.168.9.253.53 > 192.168.9.100.58718: [bad udp cksum 0x950a -> 0x25de!] 17672* q: A? zzz.testrebind.com. 1/0/1 zzz.testrebind.com. A 64.53.x.x ar: . OPT UDPsize=4096 (63)

pfstyro

@johnpoz
Thanks, I'll have a look at that - but I think it might have been something simple.

Can you confirm, does 127.0.0.1 have to be explicitly specified in the DNS list for it to use that as the default when using DHCP for an IP address etc?

If so, that was my problem - missing 127.0.0.1 in the DNS list. Added that and it worked from there.

I also tried the hostname from my mobile after your last message (I think I'd done that before anyway) and that just returns a host can't be reached message as expected.

johnpoz

@pfstyro said in Weird DNS rebind issue - Chrome/Brave go to the wrong host. Firefox works fine.:

does 127.0.0.1 have to be explicitly specified in the DNS list for it to use that as the default when using DHCP for an IP address etc?

huh? You would not set loopback address 127.0.0.1 anywhere in the dhcp settings. If you handed out 127.0.0.1 to a dhcp client for dns - it would just ask itself.

127.0.0.1 is address of the localhost, it always and can only ever tell the host to talk to itself.. That would never be listed in dhcp for dns - unless you wanted to break dns ;)

Now pfsense would ask itself, ie using 127.0.0.1 when IT wants to resolve something, ie it would ask unbound via that IP (itself).. But that would have zero to do with what a client would ask or resolve.

stephenw10

@pfstyro said in Weird DNS rebind issue - Chrome/Brave go to the wrong host. Firefox works fine.:

does 127.0.0.1 have to be explicitly specified in the DNS list for it to use that as the default when using DHCP for an IP address etc?

For pfSense itself? No it doesn't. And in fact it can cause problems doing so.

To DHCP clients? Also no.

I suspect re-saving that applied (or re-applied) some setting to Unbound.

Steve

pfstyro

@johnpoz Well, yes, I know it is the loopback.

Here is the thing.
When I set the DNS manually on the Windows PC to the pfSense IP address, the problematic page worked, but accessing the pfSense webGUI page reported a rebind attack.

I then added the loopback to the DNS list in System>General Settings (DNS Servers section). It apparently then all began to work fine.

Now I am even more confused.

pfstyro

@stephenw10
Yes, I think that must have been where the corruption was - I removed it and it is all working properly now.