Right Way to preconfigure a production deployment (DNS problems)

  • I have had good experiences in the past with pfSense (mainly 1.2), but I am struggling with a current 2.2 deployment, and looking for advice, please:

    I am working towards replacing an existing smb router in front of a production network with pfSense. I cannot of course just disable all access in and out while I configure pfSense and replicate current rules, etc. So my question is: what is the recommended way to pre-configure pfSense so I can "drop it in" once everything is tested and ready, with minimal down time?

    What I have been trying to do: Install 2.2 (or in fact 2.1 tried) on my new pfSense hardware, configure the pfSense LAN to replicate the existing smb router LAN subnet (but of course entirely separate with only one laptop for webConfigurator on it), and point the WAN interface using DHCP at the existing smb router so I can have internet access for packages, etc. The WAN correctly receives 192.168.X.X and provides DHCP to the one laptop on 10.1.X.X

    Ping by IP works across all legs of this setup - I can ping from the laptop for example. BUT I cannot get DNS to work at all! I have tried disabling DNS rebind checks, to no benefit. I can get DNS from the pfSense machine if I: "System > Advanced > Firewall and NAT > Disable all packet filtering" but still DNS timeout from the laptop client, and of course this is hardly progress towards the requirement.

    This seems to be far harder than I remember in the past - I cannot be the only one who has this requirement, namely: pre-configure, test, and then drop in to production. What's the Right Way to do this without so much grief?

    PS: I don't have access to a separate WAN uplink, so I have to somehow go through the existing one.

  • did you update from 2.1 –> 2.2 ? If so, what is currently running dns-forwarder or dns-resolver (unbound) ?
    are you getting errors from either service in system logs?
    is pfsense itself resolving anything when you try locally ?

    there shouldn't be any dns issue's except that the defaults of dns-resolver need to be tweaked (see: https://redmine.pfsense.org/issues/4402 )

  • Thanks so much for reply.

    I had installed 2.1 onto a local 60G SSD. I have been running 2.2 from live CD, so no upgrade etc involved. For both 2.1 and 2.2 I am unable to get DNS to work without forcing 'Disable All Packet Filtering', and even then it only works from the pfSense box itself. Ping by IP works between all devices in this set up, and on out to internet IP's. However no host resolution at all is working on the pfSense network, although it works fine on the network to which the pfSense WAN is connected. dig @ (or any other host) from the one LAN client reports a timeout and "no server found".

    Unless I totally missed something this is a plain 'out-of-the-box' install - pfSense box, one DHCP WAN link (into a known working network), one LAN client which works fine on other networks. The ONLY slightly unusual thing is that the WAN is an RFC1918 network. I strongly suspect that this is somehow causing the problems. pfTop (in 2.1) shows lots of outbound requests to DNS on port 53 so I suspect the set up is making requests correctly, but (despite the fact that there are no rules whatsoever, including RFC1918 and bogon networks ALLOWED on the WAN) nothing is being allowed back in.

    I have followed https://doc.pfsense.org/index.php/Connectivity_Troubleshooting and everything appears correct (except, of course, DNS)., and have reviewed the DNS rebinding discussion here: https://doc.pfsense.org/index.php/DNS_Rebinding_Protections

    Somehow I seem to be making this far harder than necessary, so my main question is still: what is the recommended way to prepare a "drop-in" replacement for a production smb-type router that I have full access to, ensuring minimal outage?"

  • you say you are running wan in private address space …. its not the same subnet on WAN&LAN right?

    you can ping by ip but not by dns
    so there are no errors in logs? what dns servers are configured on pfsense? are you running dns-forwarder or dns-resolver?

    i've never had an out-of-the-box pfsense that didn't resolve dns when it got a valid dhcp lease on WAN ... i have no clue what could be wrong with both your 2.1.5 & 2.2 situation without more info (logs/screenshots/...)

  • Thanks for sticking with, @heper

    Yes that's right, both WAN and LAN on different private addresses spaces (I double-checked to make sure they did not overlap).  I will look into logs and do some more tests over next 24 hrs or so, and report back. Given the apparent rarity of the prob, I am beginning to suspect there must be some stupidness on my part at the bottom of this… stay tuned...

  • I was able to grab our production WAN link for a short period this morning, and booted the pfSense 2.2 Live CD  on the same hardware I had been trying to use with the private address WAN before.

    This worked "as expected", with our public IP for the WAN and a private subnet for the LAN; and DNS resolved with no tweaking required.

    So it appears there is an issue with DNS when the pfSense WAN link is connected to a (at least our) private network. It's conceivable this could be upstream in our networks so I cannot say for sure it is related to pfSense, although as mentioned before every other device on this network (a mixture of linux, mac, android, windows) resolves hosts just fine.

    Would be interesting to know if (and then steps to achieve) anyone reading this has successfully got a set up working with a private network WAN link.

    In any case, I have a path forward now, although it looks like I shall have to plan for a longer outage on the production link than I had hoped, and the config work will require intermittent outages on the current production WAN while I grab the link for testing/packages/config.

  • i think most of us test alpha/beta/rc in virtual machines inside our lans, those are almost allways using private address space. Personally i've never encountered issue's with using privates address' ….

  • Yes ok, excellent point, hadn't thought of that. At some point I may try a VM set up, and see if I can learn anything about what I was doing wrong (it's clear now it was my setup somehow). But in any case I have a workable path forward now so.. onwards!

    Thanks again so much for the support :)