PFBlockerNG Python-Mode - Source-IP in Reports
-
You don't see something like this :
?
@seraph77 said in PFBlockerNG Python-Mode - Source-IP in Reports:
but only showing the IP of the internal DNS
? Where ?
-
@Gertjan I see those entry's in Python mode only (Unified and Alerts Log). And there also only, the request coming from the internal dns server (before the update I saw the IP of the Clients under Unified and Alerts mode Unbound only). With unbound only mode, the logs are not generated now (not in Unified and not in Alerts). Since I did read your previous Posts I decided to switch to Domain Overrides. So just all internal DNS requests would be redirected to my internal dns. So now I see all the Client IP's again in Python mode (Unified and Alerts log). I guess it's just the way it is at the moment. Probably DNS is anyway faster with this config. What's still not clear to me is, if i would put Null Block (logging) would it be faster than going throug DNSBL webserver/VIP?
-
For Python mode, when you use an internal dns server, you can either null block or check the option "DNSBL Event Logging", which will provide a workaround for this issue.
-
@BBcan177 Thanks for the help. I wil try that.
-
@seraph77 said in PFBlockerNG Python-Mode - Source-IP in Reports:
What's still not clear to me is, if i would put Null Block (logging) would it be faster than going throug DNSBL webserver/VIP?
No speed difference here.
If a listed == blocked domain was requested, instead of resolving it, pfBlocker intercepts the request, and 'teminates' it for unbound right away with the answer '0.0.0.0', (the "Null Block (logging)) option which will indicate the requesting source, i.e. your web browser, that their is no answer (no A or AAAA) so the content won't get loaded.
When you select "DNSBL webserver/VIP" instead of "Null Block (logging), then an IP will be return, by default "10.10.10.1" which is an IP served by a pfBlockerng web interface.
This means, if you where using a web server on the client, this 'page' would be loaded, and instead of the requested blocked domain name, this would be shown :
but there is a but : this is pretty worthless.
These days, most http requests are not http any more, but https. This means the web browser will request a certificate from the pfBlockerng web server.You'll see :
because the browser was requesting initially "a-pfblockerng-blocked-host.tld" and it got back an IP for this host : "10.10.10.1". When connecting to it using https, the web browser will ask for a certicate and here it comes : this certiccate will not / can not contain the SAN "a-pfblockerng-blocked-host.tld" but something else. click on "Advanced" and you'll see :
So, two issues : the cert is self signed, which is not a good sign when you (try to) visit a public web site, and - not even shown but you can have a look at the cert : it doesn't contain "a-pfblockerng-blocked-host.tld" neither.
Mine showed :
which isn't "a-pfblockerng-blocked-host.tld" for sure.
This is what https is all about.
This also means that "DNSBL webserver/VIP" is pretty worthless in giving the visiting end user a reason why the web visit failed. Most people on earth don't understand what that browser screen really tells.
The will abort and or run away, which is a good thing.
When https is used, the pretty pfBlockerng web server page (see above) won't show up. The browser won't allow that.Long story short : imho, use "Null Block (logging)" and call it a day.
-
The main problem is not the block site or if there is a https error. This does not matter. The problem is, that the client IP is missing in the logs as source IP. I for myself switched back to unbound-mode two years ago.
Back then there was no option for a workaround. @andrebrait wanted to look deeper into this, but he never posted a solution here. So I switched back to unbound-mode.
Don't know if the option from @BBcan177 helps to solve the problem now. But please let me know if it helps. Would be nice.
-
@Gertjan Thanks for the detailed answer. I will leave it to null block (logging) then.
-
@mOrbo Well I just checked and I will stay on my new config (Client gets Pfsense as DNS entry). It seems that I gained some speed with this setup and I don't want to spend more time with this. For my internal DNS request from the clients, I did just put my internal domain as Domain Override and point it to the ip of the internal DNS Server. That worked flawlessly.
-
Yes this could be a solution. But I’m afraid of all the consequences this can have. For example problems with automatic DNS updates from clients over VPN Tunnels, revers DNS Lookups or multiple internal domains including DNS-Split-Setups for several hybrid solutions. From my experience the internal windows dns service works best for a windows domain. Especially if this domain has a lot services relying on dns. Switching to the pfsense DNS for all clients would include a lot of testing. Unbound mode was the easier solution for me, as my pfsense has enough ram and cpu for handling unbound mode with over 5 million entries.
-
@mOrbo O.k. i see. Under such circumstances i would also stay on the internal DNS. Well just give it a try with
@BBcan177 said in PFBlockerNG Python-Mode - Source-IP in Reports:
For Python mode, when you use an internal dns server, you can either null block or check the option "DNSBL Event Logging", which will provide a workaround for this issue.
So as far i remember, it did not work with Python mode and DNSBL Null block (logging). But i surely did not test it with checking "DNSBL Event Logging" and DNSBL Webserver / VIP.
