@coreybrett said in using pfSense DHCP to service other subnets via relay:

Is this a pfS limit, or the underlying dhcpd?

It's because DHCP initially uses broadcasts, which are not passed through routers. You have to set up a relay agent to get around that. PfSense can be configured as a relay, but I haven't tried that.

@johnpoz Yep that was certainly the issue, when I turned off some of the easylists I had (relatively) recently enabled I could update it just fine! Thank you for your help

That would require much more complicated logic because then we'd have to check/test for different things in the static mappings. For example, if there is no range or pools then it would have to require all mappings to include an IP address, or it would have to prevent from switching to that mode if there were mappings that didn't conform. It could be done, sure, but that is a lot of jumping through logical hoops to cater to one specific and rarely used scenario.

Defining a range of an IP address or two isn't going to cause a problem to work around it.

Depending on you configuration an Unbound reload can take a few seconds to a few minutes to complete, hence disruption DNS service to devices. Running cron update during off hours is recommended.

With the Live Reload, pfBlockerNG perform live Unbound conf modification without interrupting DNS service. So you can run Cron Update hourly.

Live reload still have an issue where the Unbound internal DB becomes out of sync with pfb_dnsbl.conf file. It shows in the pfblockerng.log as

Resolver Live Sync... completed [ 09/06/18 05:29:28 ] DNSBL update [ 1107297 | PASSED ]... completed [ 09/06/18 05:29:29 ] DNSBL DEBUG..[ Data(s): 1107298 Zone(s): 950371 | 09/06/18 05:29:52 ]

When this happens, you can run a Force Reload DNSBL to correct the drift. Or you can just perform a Unbound reload with the shell cmd :

unbound-control -c /var/unbound/unbound.conf reload code

The widget DNSBL Unbound total queries counter might be cleared when an Unbound reload, giving you bad statistics. Simply clear the DNSBL counters by clicking on the Garbage Can icon in the widget.

That i sure Pfense dont send option 160 when i add them on configuration.
on dnsmasq we need to add the -force parameters, on dhcpd i dont know.

So it's a bug ?

Yes im sure pfsense dont send the 160 options (verify with wireshark).

@tman222 said in Still using 53 despite configuring 853:

Hi @surfshack66,

Can you please confirm that:

The DNS Forwarder (Services, DNS Forwarder) is disabled? The DNS Resolver (Servers, DNS Resolver) is enabled and the "Enable Forwarding Mode" option is checked?

Hope this helps.

Hi @tman222 - Thanks for the help. Turns out I had a firewall rule restricting certain ports on the LAN and 853 was not included. Also, that rule wasn't flagged to log alerts, so I didn't catch it.

Yes, JKnott, I do have "do not allow PD Address release" checked. And you're right, there is no control over what the ISP will actually do. I think the addresses had been the same for about 2 months but it seems like a power cycle of the modem is what triggered the IP change. pfSense had little control over it.

I'm actually on the phone with Comcast Xfinity now, it's taken 1h22m to get to a supervisor. Seems I've been talking a foreign language to both reps I've talked to so far. How hard is it to get a static /60 - /48 on an account? :) I'm currently finding out. It's not like I'm asking for a static IPv4, I'm not even bothering with that.

...and after the call, Comcast Xfinity confirmed they still don't hand out/sell IPv6 blocks to Residential customers. So it is what it is.

Would it be a fair (acceptable?) compromise to only run DNS lookups over IPv4? It looks like if I reorder my IPv4 DNS servers System -> General to place my DCs IPv4 addresses at the top of the list (with no outside interface assigned to it), then remove the RA & DHCPv6 DNS servers - the pfSense DHCPv6 server will assign out its own IPv6 per-interface address as a DNS server, and proxy the replies from the servers, in sequence, from Settings -> General. Seems to do away with the need for a DNS forwarder, which also seems to be IPv6-dependent (i.e. only take IPv6 addresses).

Just configure a DHCP reservation for that client (MAC address). Within the reservation (or static mapping) specify the openDNS server. The static mapping will trump the DHCP scope if values are populated.

Services --> DHCP Server --> Select interface --> at bottom select Add+ under the heading "DHCP Static Mappings for this Interface" --> Then enter the clients MAC address, and specify the DNS settings which would only apply to that specific client.

Ok, i found something: It's the CaptivePortal.

i think its some sort of ipfw rule, wich blocks outgoing dhcp requests.
I've found a workaround:

Bad:
edit "/usr/local/www/services_captiveportal_mac_edit.php"
comment the following line out:

$input_errors[] = sprintf(gettext("The MAC address %s belongs to a local interface. It cannot be used here."), $_POST['mac']);

then i was able to add the local MAC-Address.
But maybe this not allowed without purpose...

Better:
So i switched to dhcping-ng: https://github.com/pchytla/dhcping-ng

I compiled this on an other freebsd11 system and copied to the pfsense machine

/root/dhcping-ng -i vmx0.X -c 5 -w 2 -h aa:aa:aa:aa:aa:aa

With the parameter -h i changed the source MAC-Address, so i also added this MAC-Adress in the CaptivPortal to the MACs section as Pass Action.

I see this only as an workaround. I would like to be able sending what i want from the firewall-host

Here the working Rouge-DHCP-Detection script. Added to the crontable executing every 5 minutes.

#!/bin/sh res1="`/root/dhcping-ng -i vmx0.9 -c 5 -h aa:aa:aa:aa:aa:aa 2>/dev/null`" res1found="`echo $resnew | grep 'Recived Resonse from'`" [ -n "${res1found}" ] && printf "Rogue DHCP detected! - Guest-Network\n\n$res1\n" # for testing and finding # ./dhcping-ng -v -i -c 100 vmx0.

Now when I restart dnsmasq I get

/services_dhcp_edit.php: The command '/usr/sbin/arp -d '192.168.170.239'' returned exit code '1', the output was 'arp: writing to routing socket: No such file or directory'

I actually opened a separate ticket about this - but obviously they are connected

@tman222
Thanks for posting the link.
If I don't specify a gateway in the General Setup/DNS servers will it use the Cloudfare DNS for all my web surfing including when I'm connected to my VPN? ie. hide my DNS lookups when in a public wifi connected to the VPN.

unbound-control -c /var/unbound/unbound.conf dump_infra 1.1.1.1@853 . ttl 429 ping 196 var 7 rtt 224 rto 224 tA 0 tAAAA 0 tother 0 ednsknown 0 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 1.0.0.1@853 . ttl 428 ping 103 var 45 rtt 283 rto 283 tA 0 tAAAA 0 tother 0 ednsknown 0 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0

Do I have to have an SSL cert for my pfsense for this to work? I'm currently using a generic certificate to access the GUI on https.

Hi @johnpoz - so I had a situation where I was testing a DNS over TLS setup with these 4 servers:

1.1.1.1
1.0.0.1
9.9.9.9
149.112.112.112

One example that was interesting is that pinging say, www.google.com, sometimes I could get a Google server located in NYC and sometimes in Atlanta. Geographically speaking, the former is closer to me, and the RTT difference is almost 20ms. Not a lot, I grant you, but enough to make curious minds want to know :). When I removed the last two DNS servers (and only use Cloudflare's), the result given to me now consistently comes from NYC. The only explanation I could come up with at the time was that the servers from different DNS services were giving me different results and sometimes Cloudflare's servers would be faster and sometimes Quad9's.

Is there a flaw in my thinking, or is it actually possible to get different results in a case like e.g. google which has a huge amount of server nodes all over the planet?

Thanks again.

Here's some snips that might help:

Interface setup
0_1535825194214_guest.PNG
0_1535825254928_LAN.PNG

DHCP
0_1535825404886_DHCP.PNG

DNS
0_1535825472979_DNS.PNG

There is never a reason to forward non-FQDNs.. Unbound not going to resolve them either, and public dns not going to resolve.. No actual valid NS should resolve a nonFQDN.. So zero reason to forward those..

Well take that back if you forwarding to something that would/could resolve nonFQDN - that is when you would want to forward them upstream. But no in any sort of sane configuration you wouldn't forward those.

As to the reverse - if you were forwarding to public ns, then no you would never forward those. But in your case what you will be forwarding to pfsense and pfsense will resolve your local stuff.. Then yes you would want to forward that to pfsense, so uncheck that one.

If your setting up all yoru devices as dhcp reservations, ie static - then sure in unbound have it register your static stuff.

2/ - no resolver and cloudflare are NOT complementary... You either resolve or you forward, you normally do not do both. The only time you would would be in say a domain override situation where you have a local or specific NS that is authoritative for a non pubic domain... Lets call it domain.privatetld - in such a case then you would be "forwarding" to that vs resolving.. But its a conditional forwarder.

Thanks for your answer!
BIND is listening on all interfaces, IPsec ist not listed in there but in unbound IPsec isn't listed too and there it's working.

I already checked to restart VPN service but that changes nothing. I also think that has something to do with unbound being handled out of the box and BIND as a package is handled differently.

Just to clarify: I can query all DNS entrys made in BIND from all local networks but not from the VPN tunnel / IPsec interface.
Perhaps there need to be an advanced config made to get BIND to listen on IPsec interace too. Unfortuantely it's not listed in the "listen interfaces" tab...

where are you seeing that exactly? the dhcpd.conf would be in

/var/dhcpd/etc

I'm also wondering about this behavior.

I've three DynDNS host names which are to be updated on WAN IP change and I get two notification mails on every IP change.

Is it possible to prevent the double notification or is there an explanation for that?

You telling pfsense to use 192.168.1.10 is not the same thing as forwarding or domain override.. If your clients ask pfsense for dns out of the box it would resolve via unbound.