Dnsmasq and dhcpd, two networks and domains



  • Hello,

    Hope someone can shed some light on this problem, as it's doing my head in.

    • Router: ALIX 2D3 (1 WAN interface, two LAN interfaces, both used)

    • pfsense: 2.1.4-RELEASE (i386)

    • Goal: LAN interface to serve DHCP/NAT/DNS Fwd for home network on domain1. LAN2 interface for office - separate network/domain, with its own dhcp and dns forwarding. Two LANs are firewalled and that separation works fine.

    • Problem: LAN2 has problem resolving DHCP leased hostnames. Even worse, Linux, FreeBSD, OS X clients are all behaving differently. Static DHCP leases are working fine, but dynamic ones don't seem to register in dnsmaq (despite the fact that dhcp is sending the correct domain).

    *Typical case: LAN2 domain set to "bsw.lab" in DHCP. Linux virtual machine with hostname "vm1" is visible on the network only if I ping it with hostname (ping vm1), but is not visible as "vm1.bsw.lab". When addressed as "vm1" it gets the domain name from the resolv.conf of pfsense, which is the domain served to home LAN1.
    Something is not working as intended, or I am completely misunderstanding how dhcpd/dnsmasq work in tandem over multiple interfaces. Can firewall cause this issue? Any ideas? Thankful for every and any suggestion!

    dhcpd.conf follows (snow.lan is home network, bsw.lab is office):

    
    $ cat /var/dhcpd/etc/dhcpd.conf
    
    option domain-name "snow.lan";
    option ldap-server code 95 = text;
    option domain-search-list code 119 = text;
    
    default-lease-time 7200;
    max-lease-time 86400;
    log-facility local7;
    one-lease-per-client true;
    deny duplicates;
    ping-check true;
    authoritative;
    subnet 192.168.1.0 netmask 255.255.255.0 {
    	pool {
    		range 192.168.1.100 192.168.1.199;
    	}
    
    	option routers 192.168.1.1;
    	option domain-name "snow.lan";
    	option domain-search "snow.lan";
    	option domain-name-servers 192.168.1.1;
    
    }
    host s_lan_0 {
    	hardware ethernet 00:11:32:12:30:eb;
    	fixed-address 192.168.1.99;
    	option host-name "nas1";
    }
    subnet 192.168.101.0 netmask 255.255.255.0 {
    	pool {
    		range 192.168.101.100 192.168.101.254;
    	}
    
    	option routers 192.168.101.1;
    	option domain-name "bsw.lab";
    	option domain-search "bsw.lab";
    	option domain-name-servers 192.168.101.1;
    
    }
    host s_opt1_0 {
    	hardware ethernet 68:5b:35:d0:c2:8f;
    	fixed-address 192.168.101.2;
    	option host-name "minisrv2";
    }
    host s_opt1_1 {
    	hardware ethernet 68:5b:35:b5:6c:07;
    	fixed-address 192.168.101.3;
    	option host-name "imac";
    }
    host s_opt1_2 {
    	hardware ethernet d4:c9:ef:38:95:60;
    	fixed-address 192.168.101.4;
    	option host-name "hpswitch";
    }
    host s_opt1_3 {
    	hardware ethernet 68:5b:35:81:ea:2c;
    	fixed-address 192.168.101.5;
    	option host-name "minisrv1";
    }
    host s_opt1_4 {
    	hardware ethernet 00:1b:4d:78:0f:75;
    	fixed-address 192.168.101.6;
    	option host-name "areca";
    }
    
    

  • Banned

    @fix3r:

    • pfsense: 2.1.4-RELEASE (i386)

    There. BIG problem.



  • OK, thanks for pointing it out. (Coming from Mikrotik background, not quite up to speed with pfsense yet).

    I'll upgrade the firmware and report back if it solves the problem.
    I see that the new version comes with unbound in place of dnsmasq. I'll try both and see which one untangles the mess I'm in.



  • Upgrade finished, currently running:

    2.2.4-RELEASE (i386)

    The same dhcp/dns config was preserved across upgrade, and it's still not working for dynamically assigned IPs.
    I disabled dnsmasq and went with unbound instead (dns forwarder -> dns resolver), but the issue persists.

    If anyone has any idea what could be causing this then please chime in, before I throw this Alix box out the window and go back to Mikrotik.



  • In case anyone is having similar problems, the main culprit seems to be one of my Macs. DNS lookup is working fine, but whatever happened to the system resolver in OS X Yosemite seems to have broken things. Not even Wireshark could identify where exactly things go wrong.

    So in the end I reintroduced my Mikrotik router as a DHCP/DNS only server for one of the networks and disabled those services on the second pfsense port. It's all working fine, except for that one Mac (which happens to be my workstation, sigh) that refuses to perform proper lookups and will often return completely unrelated networks during ping lookups. So I'm now running FreeBSD VM inside that Mac which lets me talk to the rest of the network.


  • Rebel Alliance Global Moderator

    " that refuses to perform proper lookups and will often return completely unrelated networks during ping lookups."
    "Not even Wireshark could identify where exactly things go wrong"

    huh..  What did the mac query for, where did it query - what answer did it get?  These are clearly going to be plain as day jumping out at you information in the wireshark.

    Why don't you post this info where your saying you getting stuff you don't expect when you ping something.. So we can see what was actually queried for and to where.

    dns is pretty freaking straight forward you ask for a FQDN it either gives you an answer that it knows about, tells you NX or Refused or forwards its on..  Not rocket science.



  • @johnpoz:

    " that refuses to perform proper lookups and will often return completely unrelated networks during ping lookups."
    "Not even Wireshark could identify where exactly things go wrong"

    huh..  What did the mac query for, where did it query - what answer did it get?  These are clearly going to be plain as day jumping out at you information in the wireshark.

    Why don't you post this info where your saying you getting stuff you don't expect when you ping something.. So we can see what was actually queried for and to where.

    dns is pretty freaking straight forward you ask for a FQDN it either gives you an answer that it knows about, tells you NX or Refused or forwards its on..  Not rocket science.

    DNS works fine, but ping, ssh, … don't use DNS, afaik? Checking this all again seems to show slightly different results. But some weirdness persists...

    Here's an example where system resolver goes all wonky, but DNS lookup works fine:

    
    :~ host minisrv1
    minisrv1.bsw.lab has address 192.168.101.105
    :~ ping minisrv1
    PING minisrv1 (192.168.2.3): 56 data bytes
    Request timeout for icmp_seq 0
    
    

    Ping resolves this host to 192.168.2.x, which is a network that never even existed here. No idea where it's coming from. FreeBSD and Linux VMs running on this same box (bridged) have no problem correctly identifying hosts.

    Anyway, this all went way off topic. My original problem was "solved" by introducing another DHCP server and leaving pfsense to take care of firewalling. Not ideal, but so far I'm happy with the setup.


  • Rebel Alliance Global Moderator

    "DNS works fine, but ping, ssh, … don't use DNS, afaik?"
    "Ping resolves this host to 192.168.2.x, which is a network that never even existed here."

    What..  And how would ping resolve minisrv1 ??  It either queried dns, wins or it broadcasted for it..  Or you have it in a host file on the box.  Why are you not using FQDN?

    Here see I ping pfsense, my box adds the suffix local.lan which is how I have it setup..  Clearly a sniff this as I said would JUMP OUT AT YOU!!!




  • @johnpoz:

    What..  And how would ping resolve minisrv1 ??  It either queried dns, wins or it broadcasted for it..  Or you have it in a host file on the box.  Why are you not using FQDN?

    Here see I ping pfsense, my box adds the suffix local.lan which is how I have it setup..  Clearly a sniff this as I said would JUMP OUT AT YOU!!!

    This ended up being incredibly strange problem, with many Murphy's Laws involved.

    The reason that strange network ended in ping response seems to be due to one of two HP switches being reset back to factory settings somehow, which gives them the 192.168.2.x network. Somewhere in there it seems to have "acquired" the MAC address of one of the servers and thus confusing the crap out of this workstation, whereby ping tried that completely unrelated IP address (this is what I meant by ping not using DNS if it can find the address by other means).

    Rebooting every piece of the network, setting up one of the switches again, and clearing all caches has now resolved all the problems.