disable DNS rebinding protection

[aagaag]

Might a good sould explain to me how I can disable DNS rebinding protection for good? I just want to access some internal web sites from the LAN using their external names. I do not want to deploy split DNS or NAT reflection. Thanks in advance for any help that you might give me!

[johnpoz]

So you want to have public dns provide rfc1918 address.. That is borked..

As to disable rebind - simple click..
https://doc.pfsense.org/index.php/DNS_Rebinding_Protections

If your using unbound.. It can be turned off under system advanced - see the attached pic

[aagaag]

Thank you for your help, but regrettably things still do not work. I have checked and unchecked things as instructed. My internal sites are accessible from outside the LAN but not from inside. Any suggestions? Might the log files bring clarity? If so, where would the log entry be found?

[johnpoz]

some details of what your trying to do exactly..

So you have some server behind pfsense on say 192.168.0.100 and your on a box say 192.168.0.101 and your trying to use some fqdn www.domain.tld and you want it to resolve to 192.168.0.100 you want it to resolve to your public IP 1.2.3.4?

What exactly are you trying to do??  That is not working?

Are you even using unbound - maybe your using the forwarder, dnsmasq which that setting will not effect.. Really need some details of what your wanting to do exactly if going to help you.

[aagaag]

Thank you for taking the time to advise me. Also, apologies for my ignorance: I am a medical doctor by training and my networking knowledge is self-taught and sketchy. I use unbound and have not changed the default values (see pic). The pfsense gateway has address 10.10.10.1 and the LAN DNS service is hosted by a windows server at 10.10.10.2. The goal, as you correctly surmised, is to resolve an external mydomain.com to 10.10.10.x both from within and from outside the LAN.

[johnpoz]

To what end? If www.domain.tld resolve to 10.x.x.x public nobody will be able to get to this site. 

Externally would not work at all.. what is the fqdn your trying resolve?  PM it to me and I will check it..

"LAN DNS service is hosted by a windows server at 10.10.10.2"

So your clients do not point to pfsense for dns, they point to windows machine.. Which does what to look up something?  Does it forward, does it resolve - does it then ask pfsense?

Lets say this www.domain.tld resolve to 10.10.10.x - what then?  Do you think outside people would be able to get to this site?  Do you want people outside to get to it?

[aagaag]

Thanks again for your help. The situation is as follows:

• a web site is hosted at server wit internal IP 10.10.10.16
• an internal DNS server (located at 10.10.10.2) translates "haus.lan" to IP 10.10.10.16
• consequently, the web site is reachable internally as both "http://haus.lan" and as http://10.10.10.16
• the same web site is reachable from external clients as "https://mywebsite.com". pfSense is the gateway, and NAT-translates WAN requests to "mywebsite.com" (port 443) to a windows server (10.10.10.2)
• The latter windows server, in turn, takes care of authorization/authentication and reverse-proxies to IP 10.10.10.16

All of the above works fine. However, what I would like is to use the same address "https://mywebsite.com" from both LAN and WAN. And that I cannot get to work - and I don't understand why, and it's driving me totally crazy!

[Grimson]

I use unbound and have not changed the default values (see pic). The pfsense gateway has address 10.10.10.1 and the LAN DNS service is hosted by a windows server at 10.10.10.2.

So unbound has no effect as it isn't used by the clients. You have two choices:

1. Research if you can do host overrides on windows server, and how to do it. In that case it has nothing to do with pfSense at all.
2. Use pfSense with Unbound as your DNS service for LAN clients and use a host override. There are many posts about this here, so just search for them.

[aagaag]

Dear Grimson, the thing is, pfSense translates the port-443 request from the WAN to 10.10.10.2. According to my (probably faulty) understanding), the LAN DNS resolver shouldn't even come into play. Indeed, the requests from outside are processed correctly.

[johnpoz]

Why are you running a proxy on 10.2 at all?  Makes zero sense and screams asymmetrical if the proxy does not nat the traffic as well.. Since the gateway of 10.2 to answer say an answer from some public IP 1.2.3.4 is what?  Pfsense I would assume..

If you want to hit your public IP from some client to get reflected back in then you would have to setup nat reflection.

The most logical course is to as mentioned just setup a host override on whatever dns your clients are using locally to resolve your public fqdn to the local IP address of where you want to serve/proxy the traffic too.. 

[aagaag]

10.2 is needed for reverse proxying, in order to (1) redirect WAN traffic to the appropriate web servers within the LAN, and (2) to provide authorization and authentication.

I could certainly move the LAN DNS server (and DHCP server) from 10.2 to the pfSense gateway (10.1), and that may help reducing the number of possible points of failure.

But I have a hard time understanding how that would affect my redirection problem. As I said, web requests from the WAN work fine, hence the whole chain of NAT and reverse-proxy is set up correctly, and the internal DNS server is not used since the reverse-proxy translates directly the requests into IP addresses.

Nevertheless, I see the value of moving DNS and DHCP to pfSense. Currently I use a powershell script to load the DNS and DHCP tables (containing all info about the LAN) onto the Windows server. Is there a way to automate this process in pfSense as well? (This question may merit a separate thread though).

[aagaag]

Dear all
I stand corrected! I have added an override to the windows DNS service, and voilą, everything now works! Thank you all for bearing with my ignorance. For future reference, a guide to adding an override to the Windows DNS service can be found here: http://blog.simonw.se/override-a-single-external-hostname-with-internal-dns-entry/
Thanks again. I am a wiser man now!

[johnpoz]

As I said, web requests from the WAN work fine, hence the whole chain of NAT and reverse-proxy is set up correctly,

Glad you got it working.. But you still have could asymmetrical issue..  And unless your actually doing proxy and not just redirect you would have a real issue.. Placing your reverse proxy on the same network as your hosts/clients going to be concern of asymmetrical traffic..  See attached examples of where you can run into problems.

If you want it to not be asymmetrical internally you need to have the client directly go to the web server, or you need to make sure all access is actually sent back to the proxy via its IP and not to the client ip requesting the traffic.. Last pic..

You need to make sure return traffic follow the same path as it took to get to the server, to get back.. Or you have asymmetrical traffic and this can cause problems.  If client gets back syn,ack from different IP it sent syn to - its not going to like it.. And when you send asymmetrical traffic through a firewall you can run into problems with the state times out, or just plain failure..

Why would you not just run the reverse proxy on pfsense so its at the edge?

[ReeceCarthy]

The DNS forwarder (dnsmasq) uses the option --stop-dns-rebind by default, which rejects and logs addresses from upstream nameservers which are in the private IP ranges. In the most common usage, this is filtering DNS responses received from the Internet to prevent DNS rebinding attacks. Internet DNS responses should never come back with a private IP, hence it's safest to block this.

There are some cases when public DNS servers have private IP address replies by default, though it is not recommended. In those cases, DNS rebinding can be disabled or an override may be placed in the DNS Forwarder Advanced Settings box as follows:

rebind-domain-ok=/mydomain.com/
Note this is automatically overridden for domains in the DNS forwarder's domain override list, as the most common usage of that functionality is to resolve internal DNS hostnames.