Issue with DNS Rebind Check (?)

  • (I posted this in 'Bounties' by mistake and couldn't delete it - still trying to get used to this forum inteface...) Mea culpa.

    Hi there – I’m not sure if this is a bug, a feature, or a mistake on my part. However, at minimum, it was definitely a concern (for which I think I have a workaround).

    Some context to set things up - I set up a Guest VLAN (160) so that guests could get access to internet only. Firewall on VLAN 160 set up in order…:
    • block LAN net
    • block RFC1918 (redundant, I believe, but no matter).
    • Allow all

    My pfsense host name is: and is publicly available.

    The WAN firewall is, I believe well locked down…:
    • Block RFC1918
    • Block Bogon
    • Allow ping
    • Allow port 1194 to WAN address for openvpn
    • Allow port 80 to ‘This Firewall’ (for let’s encrypt cert)
    • Allow port 443 to ‘This Firewall’ (also for let’s encrypt, and flow through to internal web server)
    • Allow port 32400 to ‘This Firewall’ (for plex)

    I am running a simple HAProxy set up to flow through to an internal host (synology NAS getting a Let’s Encrypt cert), but it’s pretty tight.

    DNS Resolve…:
    • I am running DNS Resolve with my internal host names (ie ) mapped to an internal (IP This way I can access router/internal hosts by name, and without going outside (from default VLAN – I DON’T want access to router from VLAN 160, of course)
    • DNS Resolve is running an ALL interfaces and set up for ALL outgoing interfaces.
    • DNS Query Forwarding is off

    Main options..:
    • In main option DNS Rebind Check is NOT disabled (and, prior to setting up DNS Resolver, I confirmed that this worked well)
    • and I have, as default DNS.
    • I am running pfBlockerng-devel, but I’ve tested this both with and without it enabled

    Now… the issue…:
    I want to be able to specify a specific DNS for certain VLANs (ie – use OpenDNS or similar for kids vlan), and I wanted to test this out the principle on Guest VLAN to kick the tires a bit.
    On the DHCP settings for VLAN 160 (guest), I specified, for the DNS.

    So, when I log in as guest (and am on VLAN 160), I have full access to my router at (When I leave DNS on DHCP for VL 160 blank, I am blocked as expected – but I should be able to tune this by DHCP interface!) I cannot access anything else internally – just the router (ie – Webconfigurator in particular). Not what I want from a guest VLAN.

    When I try to access from the internet, there’s no access (as expected, thankfully). But when the request originates internally, I can access.

    It looks like when the client on guest vlan 160 gets the (WAN!) address from external DNS, it can use that to access the router, regardless of what I disallow on the firewall for the VLAN 160 interface (ie – my webconfigurator port is certainly NOT open externally).

    I can also access the router from guest vlan when I enter in the WAN ip address with webconfigurator port. PFSense is somehow ignoring the firewall restrictions when originating internally, but with external DNS server.

    DNS Rebind protection seems to have no effect.


    So… fortunately I think I have a solution…: I created a floating rule that blocks access to WAN Address and applied to every interface (except WAN). After this, I am blocked as expected, and I can once again sleep at night.

    My thinking is that it might be worth putting a floating rule in place on pfSense by default to block access to the WAN address, as I’m not sure any typical scenario would need this. (?)

    Not sure if this is all due to misunderstanding on my part, or what, but this is definitely not behavior I’d have expected from pfSense. I am, however, posting this so that less informed folks (like me) don’t run into the same issue without a solution in hand.

    I’m a big fan of pfSense. I’m grateful for all the knowledge I’ve gained working with it, and for the functionality it’s provided.

    Cheers – I’m receptive to comments, positive or negative!

  • LAYER 8 Global Moderator

    @indigomirage said in Issue with DNS Rebind Check (?):

    Allow port 80 to ‘This Firewall’ (for let’s encrypt cert)

    Horrible idea!!

    It looks like when the client on guest vlan 160 gets the (WAN!) address from external DNS, it can use that to access the router, regardless of what I disallow on the firewall for the VLAN 160 interface (ie – my webconfigurator port is certainly NOT open externally).

    On your vlan that you want to block access to the web gui.. Block access to this firewall on whatever ports you want to block..

    Your allow all there for internet will for sure allow access to your wan IP.. since that is an internet IP is it not, and sure is not rfc1918.

  • Hi there - I very much appreciate the response! There might be a misunderstanding here. Firstly, my webui is not on port 80. Port 80 is handled downstream via haproxy. (I'm happy to learn a way to facilitate Let's Encrypt without opening a port to the acme webserver (be it 80 or 443)).
    Secondly, my guest vlan cannot access my internal network (except for the wierd scenario i'm outlining). I've tested this.
    The scenario that I'm actually outlining here is that when the guest vlan is assigned a DNS through DHCP (or perhaps if it's entered in manually by the client (out of my control), though I haven't tested), it gets the WAN address from the external DNS (, etc). From there (originating FROM the guest vlan (only) ), it can access the router using the external WAN address - even using the web ui ports.

    To be clear, the firewall on the VLAN interface should forbid this. I've tried blocking LAN net, as well as everything on 'This Firewall' with the same effect.

    In short... if client on guest vlan uses DNS Resolver, all is good. If it uses an external DNS, it can bounce back into the router (any port) using the WAN address (seemingly bypassing the WAN interface firewall completely. This is very odd to me.

    By forbidding access to WAN address from the guest VLAN (on guest VLAN firewall rules), everything behaves as it should again.

    Wrt Port 80 or any of the others on the WAN, I get the same issue whether enabled or not.

  • I re-read your comment... and I see what you're saying wrt the Allow All from the guest VLAN. I think that's likely the issue. Thank you for the clarity.

    There is definitely some bad advice floating around online as I got this approach re guest vlan from more than one source.

    If I may ask - what is the bare minimum that must be granted at the vlan firewall to allow access to the internet?

  • LAYER 8 Global Moderator

    Well the internet is really an ANY.. You could limit ports if you want..

    But the wan is normally a public IP, ie the internet.. So blocking rfc or lan net, etc would not block it..

    The use of "this firewall" is great for those types of rules where you don't want clients on specific vlan to access port XYZ, or anything on the firewall at all. Since it will update if say your pubic changes, or any other IP you might have on the firewall in a vlan or VIP, etc.

    Just remember rules are evaluated top down, first rule to trigger wins no other rules are evaluated.

    So blocking gui ports to "this firewall" at the top of your list in guest vlan would prevent guests from accessing any gui ports, no matter what rules you have under that, say a ANY for internet.

    example - here is a set of rules that allow ping pfsense interface on that network (check connectivity) Also for dns and ntp. Blocks anything else to the firewall, and any other rfc1918 address, and anything else - ie the internet would be allowed..


  • I really appreciate the advice here, and I'm glad to have a template. I will certainly test it out!

  • And of course, if your ISP provides IPv6 connectivity, make sure to evaluate that as well. The [interface] address and This Firewall entries will incorporate IPv6 addresses as well, if they're present. Just make sure to set the protocol to IPv4+v6. If none of your earlier entries allow/block IPv6, but the last "Allow any" rule does, then someone on your guest network could access your other network(s) through IPv6 if they knew enough.

Log in to reply