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

pfstyro

@stephenw10
It is a Linux based server running nginx. One virtual host (the main application) works fine, the other virtual host (which is a myPHPadmin page) redirects to the pfSense web manager - same subnet, but physically different hardware.

The other weird thing is it is ONLY this one physical machine. Others work fine.

I have tried using both discrete and alias entries in the DNSresolver settings - makes no difference.

stephenw10

OK, can we assume you're trying to connect to it by host name? If now exactly how are you connecting?
Do you have port forwards configured to it? Is NAT reflection enabled?

Still seems like it could be DoH. Have you checked that in Firefox?

Steve

pfstyro

@stephenw10
Thank you for getting back to me.

Yes, I am access it by hostname.

As to how EXACTLY am I connecting, very simply and straightforwardly. I type in the FULL URL in the web browser. Sometimes I cut and paste it from a scratchpad - especially if I am trying to compare results using different browsers to avoid any typos. (eg https://<hostname>.<domain> that is it - with the relevant info substituted obviously.)

I have just checked, Firefox is NOT set for DNS over HTTPs

I do not recall setting any NAT reflections (and there is no NAT reflections set in System/Advanced/Admin Access, in any event, that wouldn't work as the external link would fail as it is not NAT'd for that server IP or host. I don't believe pfSense has DoH support, so I cannot see how that would work here.

The network runs a split DNS, so internal IPs are served via DNSresolver. External IP addresses are served by an external service. The host in question is not accessible from outside the LAN as previously indicated. I am not aware if pfSense is able to deliver DNS over HTTPS (I assume that is what you mean by DoH).

The weird thing is it has started out of nowhere really. The machine in question is running on a VMware Virtual Machine which was moved to a new updated physical server. Everything was unchanged as the move was flagged as a move, not a new server (I believe this even retains the MAC address).

johnpoz

@pfstyro so to clarify..

This fqdn your trying to hit is public hosted elsewhere on the public or your own network, so it is suppose to be resolved to some other internal IP when local and your public IP when remote. Or this is just some public hosted site, and shouldn't resolve to your public IP or internal IP at all?

So lets say your trying to go to https://host.domain.tld, out on the public internet this resolves to your public IP lets say 1.2.3.4

But internally it should resolve to some server on your network lets say 192.168.100.42, but your saying it resolves to pfsense IP?

So your clients all use pfsense as their dns? And it has records for this fqdn that points to the 192.168.100.42 address where you host this site?

Or do you have domain override setup pointing to some internal dns for these fqdn that should resolve to local IPs?

Are you running say pfblocker - where it could return an IP that is pfsense or hosted on pfsense as a vip for something that it blocking.

stephenw10

Indeed, Unbound in pfSense does not support DoH. And even if it did Firefox would not use it unless reconfigured to do so.

Does that host resolve that FQDN to a pfSense IP at the command line?

Are you actually using pfSense for DNS?

The other thing that Firefox does differently is use it's own network settings. Chrome (unsure about brave) will use the Windows connection settings (assuming it is Windows) so you should check that has not changed somehow.

Steve

pfstyro

@stephenw10
No, I should have said - if I ping the hostname from another machine, it returns the correct IP address.

It is not windows - the ping machine is the same machine I was using for the web access. I just loaded a simple cmd window and pinged the hostname.

If the VM is turned off, the ping fails. If the VM is turned off, it still goes to the pfSense webGUI (I have just checked it before typing.

When the VM is turned on, the ping is successful. The web URL still goes to the pfSense webGUI.

Internally, DNS resolver is used for internal IP addresses. Anything that has to be accessed externally uses and hosted DNS service which is then NAT'd through to the appropriate local IP.

It is only a small network - all on the same subnet. I had some VLANs planned and set that up - but the problem did not coincide with that being set up, and anyway I have since removed them just in case. None of those planned VLANs coincided with that IP in any way.

pfstyro

@johnpoz
No, the host and the machine accessing it are both on the 172.16.1.0/24 subnet (as is the pfSense management GUI).

This host in NOT accessible from anything other than the 172.16.1.0/ subnet

See other reply regarding ping tests and windows cmd.

johnpoz

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

if I ping the hostname from another machine, it returns the correct IP address.

Are you pinging the fqdn, or just the hostname?

Your saying pinging fqdn from machine A works and returns the correct IP, but if ping the fqdn from machine B it returns the pfsense IP and you get a rebind error produced by pfsense?

Example if I create record that points some non pfsense fqdn to pfsense and try and access it I get this error in browser.

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;zzz.testrebind.com.            IN      A

;; ANSWER SECTION:
zzz.testrebind.com.     3600    IN      A       192.168.9.253

After I accept the error about the ssl not matching I get this.

192.168.9.253 is the lan IP of pfsense.. Which is the correct response, you need to figure out why whatever fqdn your resolving from whatever machine on your network is not resolving the correct IP for the server hosting that site. But if yes if you hit pfsense via some name its not aware of as its, then it will warn possible rebind.

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.