@qbhatti said in Pihole as secondary dns:

blocks some google ads so it means I cant click on shopping items or sponsored items when searching.

Seems like a problem of the ad blocking list your are using in Pihole.
You could try a safe one like OISD Basic that has no false positives.

@johnpoz I am hallucinating indeed I see that I can use other dns that are not those of my provider. I don't know if it's their mistake or they have changed their policy and now they allow us to use others. If so, this has solved my problem. Ufff!
Thank you very much for your help.

@johnpoz
I just verified. In the Network preference of the mac, under "DNS", I had specified a bunch of IP addresses of entities other than my own ISP (like 1.1.1.1 or 9.9.9.9 ...), owned by Google, Clouflare and possibly others. I erased all entries in this field yesterday and just checked now : it contains one entry it added itself, which is 198.168.xxx.1 : the LAN address of my SG-1000 pfSense firewall-router, in the private vlAN of which this mac is client.

@bob-dig Yes, what you say is true. Luckily my prefix(es) are not dynamic and I'd need to do quite a few changes to flip to what you suggest. I'll probably think about that as a longer-term project but for now this solution works for my specific use case.

@chris1284 when I get a chance I will try and duplicate this.

@br116 said in IP Addresses not showing up:

Is there a reason for this?

You're probably missing important info.
If you set up a device with static IP settings, like : a screen shot of one of my APs :

92141b30-4402-496b-a5c3-369802092bc6-image.png

then the DHCP client process on that device, my AP, and your device, isn't used.
So, my AP will never emit a DHCP request, and the pfSense DHCP server will never receive a request for a lease from this device.
Because : DHCP isn't used by this device.
So : no lease.
Because you chose not to use DHCP for your device.

@derelict this has come up multiple times ;)

Here is an old thread where went into much detail about when the dns server your redirecting on on a different vlan, etc. or when its on the same network and you get back the unexpected IP, etc..

https://forum.netgate.com/topic/139457/transparently-intercept-and-redirect-dns-traffic-to-an-internal-dns

Personally not a fan of redirection either, either use the dns I handed you - or not getting dns ;)

But I have done on one of my vlans just to shut up some iot shit that insists on trying to talk to 8.8.8.8, so just redirect it to my pihole - there you go buddy googledns answered you ;) If you would just use the freaking dns I handed you with dhcp you dumb crappy pos we wouldn't have to do such nonsense.

@gertjan Thank you.
I'm not skilled in programming that's why I asked where to submit a request.
If I do a pull-request and edit things which most likely is wrong, someone has to view this and I'll wasted his/her time, because.. I suck.

I'll gladly donate 10usd to whomever does it. Or donate to a cause by his/her choosing.

@steveits I have 22h2 on windows 10, and the dhcp server is clearly still listed there.

Ethernet adapter Local: Connection-specific DNS Suffix . : local.lan Description . . . . . . . . . . . : Killer E2600 Gigabit Ethernet Controller Physical Address. . . . . . . . . : B0-4F-13-0B-FD-16 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 192.168.9.100(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Friday, November 11, 2022 6:20:38 AM Lease Expires . . . . . . . . . . : Thursday, November 17, 2022 6:20:38 AM Default Gateway . . . . . . . . . : 192.168.9.253 DHCP Server . . . . . . . . . . . : 192.168.9.253 DNS Servers . . . . . . . . . . . : 192.168.3.10 NetBIOS over Tcpip. . . . . . . . : Enabled

@schirrms when you forward, the dns you forward to either does dnssec or it doesn't that setting can cause issues if your asking unbound to do dnssec, but its not actually resolving.

That setting when you click forward should in my opinion be auto unchecked, there is really no scenario where you would forward and also want unbound to try and do dnssec..

Where you forward either already does it or it doesn't - that setting is only going to cause extra queries and most likely issues.

If you want to use dnssec when you forward, pick a server to forward to that does it - which is most of them. If you don't want to do it - then pick one that doesn't. Many of the big providers have a different IP to use that doesn't do it.

For example quad9 has 9.9.9.10 that doesn't do dnssec

9.9.9.10 Provides: No security blocklist, no DNSSEC, No EDNS Client-Subnet sent. Please use the unsecured secondary address of 149.112.112.10

Having unbound do dnssec only makes sense when its resolving stuff on its own.

@wurst Great that my post helped you finish setting this up!

Even when I figure something out myself or through other research I like to come back and finish a thread so there is a working solution for others to find if they come looking with the same problem.

Just to clarify for others (I can't edit my post now) the route-gateway commands are added to Advanced configuration, custom options in the OpenVPN server and client configuration for the link.

Regarding my two domain configuration - I did some testing with dhcrelay at the command line and unfortunately it is not possible to run two instances with the same upstream link - the daemon binds to the upstream interface (ovpnc1) with a BPF (packet filter) binding, however the second instance refuses to start saying the ports are already in use. This seems to be a coding limitation of dhcrelay because you can actually have more than one application listening to the same UDP ports on the same interface if you use raw sockets. (I guess it doesn't use raw sockets, which is surprising for DHCP)

So the only way to run two instances would be to use two different VPN tunnels to the two different domains, and at least one of the instances would need to be run from the command line or a startup script... messy and not very maintainable in the future.

However for my purposes one instance is actually enough. I realised that you can add many DHCP servers in the dhcrelay config, in the GUI as well, so I simply added all 5 of them - two are primary DHCP servers for the two domains, two are failover DHCP servers for the two domains (usually inactive) and one is the PXE boot server.

This causes every client DHCP broadcast request to be sent to all 5 servers as unicast. Not very efficient, but it works, as only the server which owns the scope for that particular VLAN (and is not in failover standby) will reply, the others just ignore the requests. And in the case of PXE boot the PXE boot server is the one that replies.

This can be seen here, captured on the ovpnc1 interface, when a client on VLAN 1 sends a DHCP request where only the primary DHCP server for Domain 1 responds:

16:17:41.702734 IP 172.23.0.2.67 > 10.0.0.250.67: BOOTP/DHCP, Request from b8:03:05:c7:0e:6b, length 334 16:17:41.702758 IP 172.23.0.2.67 > 10.0.0.248.67: BOOTP/DHCP, Request from b8:03:05:c7:0e:6b, length 334 16:17:41.702774 IP 172.23.0.2.67 > 10.0.0.249.67: BOOTP/DHCP, Request from b8:03:05:c7:0e:6b, length 334 16:17:41.702787 IP 172.23.0.2.67 > 10.0.0.253.67: BOOTP/DHCP, Request from b8:03:05:c7:0e:6b, length 334 16:17:41.702801 IP 172.23.0.2.67 > 10.0.1.6.67: BOOTP/DHCP, Request from b8:03:05:c7:0e:6b, length 334 16:17:41.719679 IP 10.0.0.253.67 > 10.20.1.254.67: BOOTP/DHCP, Reply, length 330

And here, when a client on VLAN 2 sends a DHCP request where only the primary DHCP server for Domain 2 responds:

16:18:59.910858 IP 172.23.0.2.67 > 10.0.0.250.67: BOOTP/DHCP, Request from b8:03:05:c7:0e:6b, length 336 16:18:59.910880 IP 172.23.0.2.67 > 10.0.0.248.67: BOOTP/DHCP, Request from b8:03:05:c7:0e:6b, length 336 16:18:59.910894 IP 172.23.0.2.67 > 10.0.0.249.67: BOOTP/DHCP, Request from b8:03:05:c7:0e:6b, length 336 16:18:59.910908 IP 172.23.0.2.67 > 10.0.0.253.67: BOOTP/DHCP, Request from b8:03:05:c7:0e:6b, length 336 16:18:59.910921 IP 172.23.0.2.67 > 10.0.1.6.67: BOOTP/DHCP, Request from b8:03:05:c7:0e:6b, length 336 16:18:59.925943 IP 10.0.0.248.67 > 10.22.1.254.67: BOOTP/DHCP, Reply, length 333

As we only have a small number of devices at this remote site I'm not worried about the overheads of doing this. Even if I was able to separate the forwarding requests for the two domains I would still have 3 requests per domain anyway, primary and failover DHCP and (shared) PXE boot server.

People should keep in mind that this configuration of relaying to all DHCP servers can potentially cause information leakage - eg the DHCP servers in one domain see queries from devices in the other domain even if they aren't responding to them. So you would only want to do this when the two domains are "friendly" and owned by the same organisation.

If not separate dhcrelay clients on other devices or separate tunnels would be warranted to avoid DHCP servers seeing queries from outside their organisation.

I've gone ahead and followed this guide on my firewall to avoid having to configure preferences against a system behind the firewall.

And it blocks everything it needs to from LAN clients after I configured the firewall rules referenced in the first post.

However I have a Wifi mesh system linked to the firewall that seems to agree with some blocks, but connecting to some hosts from my smartphone isn't blocked when they should be. Is there something more that needs to be configured?

@jegr

Why exactly? Multiple domains won't make that "impossible". That you have to explain.
My impression was that you suggest to use one of those domain names also for internal use. Since I have multiple that seems impossible to me, apart from the fact that i do not like the idea.

Otherwise a Host Override will do better as it won't have traffic go to your firewall to be reflected
The traffic from my internal systems are passing directly to the also ^publicly accessible systems^. However in opposite to what you suggest, they do pass the firewall, since the public servers are in the redzone and for example the pc's are in the pc-zone.

However I do not understand the NAT reflection idea. I had a look on https://docs.netgate.com/pfsense/en/latest/nat/reflection.html And do not get the impressing that there is a better solution. But perhaps I am wrong.

Dynamic ones - no. Statically assigned ones are no problem AFAIK as those get imported when starting/restarting the resolver and won't be refreshed that often.
I did not ever released that, I do not like it, however since the things which should have a stable address have either a machine internal fixed address(es) or have one statically assigned by the dhcp server based on MAC and DUID that will probably not be a big problem.

DNS-resolver forwarding local domain to rootservers!??
That issue have been solved recently by changing DNS resolver type to static. Which should IMHO be the default.

To check: What do you mean by "default zone"?
Yep exactly there. That is my toplevel. All the clients are in vlans having <vlanshortname>.lan as subdomain.

Note that .lan and its subdomains are of course not visible from the outside.

Related to DNS options, I have the following options in that field
server:
log-queries: yes
#log-replies: yes
#log-tag-queryreply: yes
local-zone: "use-application-dns.net" always_nxdomain
Not so sure about the final line 😧

Related to blocking SSH from e.g. my guest vlan. I am not sure about the pfSense behavoir (I should test some time).
I have two issues here:

the gateway is inside each vlan (?), and from that you could expect that there is no rule which could block access to that gateway. Never the less I think that you can block the functions provided by the gateway. Second is that you have to add rules for that. Best way there is probably two rules in the floating rule set.
First defining what is allowed
Second refusing the rest

I would prefer an option where you could define the listening addresses for the pfSense GUI.

So perhaps you didn't know, but you can use the ports of SSH/Web and forward them to another host from your WAN without doing anything in pfSense
I do not understand this, however I have only one publicly reachable SSH-/SHTP-server and that one is reachable via port forwarding. pfSense itself is on port 2222 and the pfSense management is not reachable from the wan, not by any port/means.

I don't know your system or HW specs
Related to the hardware specs
Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz
Current: 2099 MHz, Max: 3500 MHz
4 CPUs: 1 package(s) x 4 core(s)
SSD 16 GB-ram

So reasonable powerfull, however I have 10gbit lan's internally, and transferring data from the NAS (greenzone) to the PC-zone is passing the FW.

I also assume that applications like pfBlocker are only checking the WAN, which of course has a much lower speed. But why should I add that complexity If I only want to block a minimal number of domains!?

Note that I not only use the firewall to block incoming traffic, but also try to block some outgoing traffic (using DNS). Not so easy 🎃

@321liftoff Yes they are but why would you need to use transparent ClientIP? That wasn't mentioned anywhere in your question, that's why I'm wondering. Does your service actually need the source IP of the client to work?

Cheers

@jegr the other "DHCP server" is an Android tablet with WiFi sharing.
And so it works without further ado.
I suspect that the client does not understand something. Of course, a DCHP server in the IP range 1.1.1.x does not exist.

I'm just wondering why the "dumb" DHCP server works on the Android tablet and the pfsense DHCP server doesn't.

@jegr Thanks for the suggestions. I dont use pfBlockerNG since I have my own Unbund DNS running on my network in Docker on Synology. This way I am able to stay most current with Unbound versions. Big plus is that I am able to use Unbound full API when it comes to RZP and dns trigger actions. pfBlockerNG is not near what pure Unbound can provide in functionality.

AS I mentioned I do have port forward enabled and multiple interfaces. I use firehol ipset level2 and 3 plus some additional ipsets. I block these aliases at the interface group level.
These are configured to block any internal traffic going OUT to any of the IP in these lists.

Running it about a week and I have few hits. Its a low count.
That proves to me that it is working and catching bad actors as it should.