Switched to Python unbound Mode and now have issue
-
I switched to Unbound python mode and disabled DNS Resolver DHCP Registration option and DNS Resolver OpenVPN Client Registration. Everything seemed to start fine. When I turned on 'Enable DNSBL' I lose connect to everything.
I figure it is a DNS issue and I thought way back when I first setup pfBlockerNG I had a similar issue but I can't remember why or what I did to fix it. I am confused as to why switching to python mode would suddenly cause me issues. Any suggestions on what it could be or where to continue troubleshooting?
-
@thezfunk said in Switched to Python unbound Mode and now have issue:
When I turned on 'Enable DNSBL' I lose connect to everything.
When you install pfBlockerNG (latest version 3.0.0_8), using unbound mode, or Python, it does ... nothing.
Same thing for unbound mode.Then , two thing happens :
Settings are changed.
Feeds are activated.
If there is a DNS issue, undo one or both changes.What do you mean by DNS issue ? That rather vague as an problem description.
-
Your right, sorry. Between tired and frustrated I didn't get everything down coherently.
I was a couple version behind on the Dev. version as I had seen that there were a few issues that looked like they were resolved. Sequence of events:
- Stopped pfBlockerNG
- Upgraded
- Started pfBlockerNG and tested that it still worked fine.
- Did some testing for a few days no issue.
- Decided to switch to the python mode so I could start playing with REGEX at some point
- I had to turn off those two options in DNS Resolver before switching to python
- Switched to Unbound Python mode.
- Left it default (I think).
- Forced reloaded my DNSBL feeds.
- Turned DNSBL back on
- Lost DNS resolution network wide.
- Turned off DNSBL and got resolution back working.
-
@thezfunk When you switch/enable mode, you have to run a Force Update and Force Reload All.
Did you inspect pfblockerNG.log, Systems Logs, Resolver Logs ?
-
I do remember one other thing that happened just before I did the first force reload is that it was saying there was a cron job already running and wouldn't let me do a reload. I sat for quite a while and it appeared hung so I rebooted pfSense. Not sure if that means anything.
Well, it looks like I found a bit more information. When I start DNSBL and do a force reload. It looks like unbound DNS Resolver dies and won't restart until I turn off DNSBL and do another force reload. Why would that be happening?
-
@thezfunk Time to inspect pfblockerng.log
It looks like it didn't complete the Update at some point. -
@ronpfs said in Switched to Python unbound Mode and now have issue:
@thezfunk Time to inspect pfblockerng.log
It looks like it didn't complete the Update at some point.I think you still have to manually restart Unbound from the Dashboard after you stop and then restart DNSBL in pfBlockeringNG_devel.
It has been reported on this forum by others that if you wait a while, amount of time is unknown, it will restart on it's on but I've found it quicker to just click restart Unbound from the Dashboard.
Supposedly this will be fixed when pfSense 2.5 is released and python mode is fully compatible/implemented with pfBlockerNG-devel.
-
Hello!
Maybe related to this? :
https://github.com/NLnetLabs/unbound/issues/372
What about adding unbound to the Service Watchdog?
John
-
@serbus said in Switched to Python unbound Mode and now have issue:
What about adding unbound to the Service Watchdog?
Bad idea, Unbound or pfblockerNG services are not happy with it.
-
Well, I think I fixed it. After you pointing out that a file was missing according to the log, I just reinstalled it. This time, when I started DNSBL and checked the services, unbound DNS Resolver was still running and the logs showed the file was now in place. Whatever that python file it is that it looks for.
Right now I am slowly turning my feeds back on and it seems to be working. Now, if I can only figure out why my credit union Android app won't connect and the reports show nothing blocked for those IP address. Existing problem I started a thread on that this update doesn't seem to have solved.
-
@thezfunk Updating/Re-installing pfblockerNG while it is active is prone to fail.
Disable pfblockerNG before, update, review settings, enable, run Force Update, Force Reload All. -
@ronpfs said in Switched to Python unbound Mode and now have issue:
Bad idea, Unbound or pfblockerNG services are not happy with it.
Hello!
Unbound is listed as standard option for Service Watchdog. What sort of issues are there?
John
-
@serbus Search the forum to get more info. ;-)
-
@ronpfs said in Switched to Python unbound Mode and now have issue:
@thezfunk Updating/Re-installing pfblockerNG while it is active is prone to fail.
Disable pfblockerNG before, update, review settings, enable, run Force Update, Force Reload All.That is exactly what I did do originally. I was following the instructions laid out after other people had issues.
-
@serbus said in Switched to Python unbound Mode and now have issue:
Unbound is listed as standard option for Service Watchdog. What sort of issues are there?
You'll enter into timing critical issues, and these are, by there nature, very hard to debug.
The service watchdog exists to create a controlled major fail of the entire system .... and have it running to the bitter (close !) end.
See it like drilling extra holes into a sinking ship's hull to permit it to sink horizontally.
Remember Titanic ? Evacuation on a more then 45 ° deck angle is hard.edit :
a core pfBlockerNG-devel file can't be found. or, per instructions, unbound needs it to start.
It /var/unbound/pfb_unbound.py, should be there, after a pfBlockerNG-devel 3.0.0_8 install or upgrade. Things go bad without it. -
@gertjan said in Switched to Python unbound Mode and now have issue:
It /var/unbound/pfb_unbound.py, should be there, after a pfBlockerNG-devel 3.0.0_8 install or upgrade. Things go bad without it.
If the OP has Ramdisks enabled, that would wipe the /var/unbound folder and delete the Python script.
The Pkg needs to be re-installed and RamDisk option disabled.
-
@bbcan177 said in Switched to Python unbound Mode and now have issue:
@gertjan said in Switched to Python unbound Mode and now have issue:
It /var/unbound/pfb_unbound.py, should be there, after a pfBlockerNG-devel 3.0.0_8 install or upgrade. Things go bad without it.
If the OP has Ramdisks enabled, that would wipe the /var/unbound folder and delete the Python script.
The Pkg needs to be re-installed and RamDisk option disabled.
I did not but a reinstall did fix my issue.
-
I have a slight different issue
The py script is in place, however I get
File "pfb_unbound.py", line 1147, in operate if qstate_valid and pfb['safeSearchDB']: KeyError: 'safeSearchDB'And unbound fails to start.
Playing with options for safesearch didn't do any difference
Disabling the python module "resolves" the issue
pfsense 2.5 stable, pdblockerngdevel ver 3.0.0_15
-
@netblues said in Switched to Python unbound Mode and now have issue:
I have a slight different issue
The py script is in place, however I get
File "pfb_unbound.py", line 1147, in operate if qstate_valid and pfb['safeSearchDB']: KeyError: 'safeSearchDB'And unbound fails to start.
Playing with options for safesearch didn't do any difference
Disabling the python module "resolves" the issue
pfsense 2.5 stable, pdblockerngdevel ver 3.0.0_15
Wanted to point out that I have the same issue with 2.5, 3.0.0_15 and python...
-
@mcfuzz
Can you post the contents of this file when Unbound python mode is enabled: /var/unbound/pfb_py_ss.txt -
@bbcan177 No such file exists
Even tried touching and disabling - reenabling.Is the file name correct?
-
@netblues
Did you enable Python mode and Safe Search? Then Run a Force Update. -
@netblues Maybe save DNSBL Settings, SafeSearch Settings, Force Update / Reload ALL while monitoring pfblockerng.log.
-
@bbcan177 said in Switched to Python unbound Mode and now have issue:
@netblues
Did you enable Python mode and Safe Search? Then Run a Force Update.So - this worked for me, but only after I’ve done a second time! After the first time I had the same issue and after doing the second time, it started working flawlessly. Odd... could be something on my end but so far, everything’s working well.
-
Enabled safesearch, enabled python mode., applied and force updated
Loading DNSBL Statistics... completed
Loading DNSBL SafeSearch... enabled
Loading DNSBL Whitelist... completed
DNSBL - SafeSearch changes found - Rebuilding!-Assembling DNSBL database...... completed [ 03/29/21 22:26:48 ]
Removing DNSBL Unbound python integration settings
DNS Resolver ( enabled ) unbound.conf modifications:
Removed DNSBL Unbound Python mode
Removed DNSBL Unbound Python mode scriptSaving DNSBL statistics... completed [ 03/29/21 22:31:10 ]
Resolver Live Sync analysis... completed [ 03/29/21 22:31:24 ]
Resolver Live Sync finalizing:And hungs there, with no dns service, unbound process at 100% for 15 minutes now..
After killing unbound process
Resolver Live Sync ... FAILED!
Stopping Unbound Resolver
Unbound stopped in 1 sec.
Additional mounts:
Unmounting: /lib
Removing duplicate mounts (2): /dev
Unmounting: /var/log/pfblockerng
Unmounting: /usr/local/share/GeoIP
Removing DNSBL Unbound python mounts:
Unmounting: /usr/local/bin
Removing: /var/unbound/usr/local/bin
Unmounting: /usr/local/lib
Removing: /var/unbound/usr/local/lib
Removing: /var/unbound/usr/local
Removing: /var/unbound/usrStarting Unbound Resolver... completed [ 03/29/21 22:46:33 ]
DNSBL update [ 801834 | PASSED ]... completed [ 03/29/21 22:46:35 ]and safesearch appeared on google search
python mode was found disabled again.Re enabled python mode in resolver at this stage
and
Mar 29 22:55:55 unbound 55552 [55552:1] error: pythonmod: Exception occurred in function operate, event: module_event_new
Mar 29 22:55:55 unbound 55552 [55552:1] error: pythonmod: python error: Traceback (most recent call last): File "pfb_unbound.py", line 1147, in operate if qstate_valid and pfb['safeSearchDB']: KeyError: 'safeSearchDB'STILL NO FILE!!!
-
@mcfuzz Is python mode on in resolver?
-
@netblues said in Switched to Python unbound Mode and now have issue:
Re enabled python mode in resolver at this stage
You can not simply enable Python in DNS Resolver / General Settings tab, you have to do that in pfBlockerNG / DNSBL tab, then run a Force Update.
-
@netblues said in Switched to Python unbound Mode and now have issue:
@mcfuzz Is python mode on in resolver?
Yessir.
-
@ronpfs I did that, initially.
exactly as instructed! -
@netblues Same result with a Force Reload All?
-
@ronpfs it does take time doing aaforce reload
-
@netblues 5-30 mins should be enough. But if some lists timeout after 5 mins, Update time can be much longer.
What kind of machine ? Under 4GB you have to limit the size of Feeds.
You may also have some lists that break DNSBL. Maybe disable all Groups and enable only one at a time to see if that complete fine.
Maybe something is running wild, was it rebooted lately?
-
@ronpfs @ 4Gigs, runs under kvm.
Disabled all tld option, for speedier updates.
I'm aware of lists overload et all. Without python mode, cron updates are normal, and force update complete in about 10-12 minutes.
Still, I can't enable python mode without loosing dns resolution.
So update fails due to no resolving.Looks like a corner situation.
-
@netblues said in Switched to Python unbound Mode and now have issue:
about 10-12 minutes
That's ..... long. Slow connection ? Huge number of feeds ? Both ? Underpowered device ?
But even so, during the update, unbound - and the underlying extension python script, just takes a couple of seconds to restart. Surely non "10 minutes".It's possible that the download saturates the download "pipe", so even DNS traffic suffers. All your traffic could suffer from this.
One of the reasons I update my feeds ones a week at 0300 AM. As most lists - you can see the date/time stamp info - is updated less often then that. -
@gertjan Downloads are instant.
Filtering through 1m takes most of the time.
And no, the pipes are not saturated @100MbitsAnd dns doesn't suffer overall.
If I get the dreaded error in resolver logs, no resolution is possible.
Ping with ip works great.I need to experiment a bit more, but since this is service affecting during normal hours