DNSBL keeps restarting
-
While troubleshooting why my VOIP calls keep getting dropped, I came across hundreds of sequential entries in the General log, all of which look like this, 1 minute apart
Sep 17 08:16:00 php-cgi servicewatchdog_cron.php: Service Watchdog detected service dnsbl stopped. Restarting dnsbl (pfBlockerNG DNSBL Web Server) Sep 17 08:15:00 php-cgi servicewatchdog_cron.php: Service Watchdog detected service dnsbl stopped. Restarting dnsbl (pfBlockerNG DNSBL Web Server) Sep 17 08:14:00 php-cgi servicewatchdog_cron.php: Service Watchdog detected service dnsbl stopped. Restarting dnsbl (pfBlockerNG DNSBL Web Server) Sep 17 08:13:00 php-cgi servicewatchdog_cron.php: Service Watchdog detected service dnsbl stopped. Restarting dnsbl (pfBlockerNG DNSBL Web Server) Sep 17 08:12:00 php-cgi servicewatchdog_cron.php: Service Watchdog detected service dnsbl stopped. Restarting dnsbl (pfBlockerNG DNSBL Web Server) Sep 17 08:11:00 php-cgi servicewatchdog_cron.php: Service Watchdog detected service dnsbl stopped. Restarting dnsbl (pfBlockerNG DNSBL Web Server) Sep 17 08:10:00 php-cgi servicewatchdog_cron.php: Service Watchdog detected service dnsbl stopped. Restarting dnsbl (pfBlockerNG DNSBL Web Server) Sep 17 08:09:00 php-cgi servicewatchdog_cron.php: Service Watchdog detected service dnsbl stopped. Restarting dnsbl (pfBlockerNG DNSBL Web Server) Sep 17 08:08:00 php-cgi servicewatchdog_cron.php: Service Watchdog detected service dnsbl stopped. Restarting dnsbl (pfBlockerNG DNSBL Web Server)I have removed pfBlockerNG DNSBL from the list of services being monitored by Service Watchdog, but I am am not sure why dnsbl keeps crashing and restarting. Also, could this be the cause of my dropped voip calls? (although I note that pfBlockerNG is not set to run on the vlan I use for voip).
Any help appreciated.
-
I think these are separate problems.
Which VOIP service do you have? I would suggest going to their site and looking into their troubleshooting steps. Problems like this could be port related. See if they list which outgoing ports you should have open.
Post your rules for the VLAN the VOIP is on. If you have only VOIP devices on that VLAN, might be best to try an any rule to allow all traffic out. Check the quality monitor graph when you run into these issues. Are you dropping packets?
edit: on that other issue, personally not a fan of the watchdog service. I found that it caused more harm than good. If services have to be restarted, then something is wrong and the watchdog will simply keep restarting something that is broken or misconfigured, eating up resources in the process.
-
Hey, thanks for taking the time to help me with this! Here is the info you referred to:
- VOIP service is voip.ms. They had an intermittent outage over the last couple of days which is now fixed, but my problem has been going on for a couple of months.
- I have already been through all their troubleshooting steps with their support personnel, including a complete factory reset of my ATA and setting up from scratch. Have also switched from UDP to TCP for SIP, which seemed to help at first, but the problem recurred
- I have followed the recommendations in the pfSense documentation regarding setting Firewall Optimization Option to "Conservative"
As for rules, I have 3 pass rules on that vlan:
- PASS TCP/UDP from VOIPlan net to the gateway for that vlan for DNS port 53
- PASS UDP from VOIPlan net to the gateway for NTP port 123
- PASS UPV4 any from VOIPlan net to not local (using alias for local addresses)
When the call drops happen, the call status monitor on my voip ATA shows a rapid increase in dropped UDP packets, culminating in the call being dropped in approx 10-15 seconds.
-
I would think for VOIP you want to be using UDP not TCP. So I would switch that back if you can.
If you only have VOIP devices on this VLAN try an open rule which allows all IVP4 out of that VLAN. Put that rule at the top of the list. I don't think you have a need to be strict with ports on that VLAN if they're simply phones. Especially, since you're having trouble with them. This is a good way to ensure it's not a port issue. Simply allow all ports and if that solves it, you can then start looking into which ports are really required if you want. I personally let all the traffic from my phones out to prevent issues. I have had cases where some phones don't work with the same rules as other phones, so I got tired of playing port whack-a-mole and just opened up all the ports.
On pfSense Go to Status > Monitoring and change the Left axis to quality. See if pfSense is dropping packets at the same time.
edit, here is the rule for my phones as an example. Created an alias for all my phones with static IPs. Then the rule allows those specific phones to talk freely on whatever port they want.
-
Thanks again for you help with this. I followed your suggestion about the pass all rule at the top - this will supercede all the other rules below it, right? (I left the other rules in place)
I also had a look at the status graph. Interestingly, at the time of the last dropped voip call, packet loss was close to 6%, and there was a spike in the delay average and std dev. Could this indicate an issue with my ISP connection? Or was that all coming from my voip connection?
-
@pfguy2018 said in DNSBL keeps restarting:
I followed your suggestion about the pass all rule at the top - this will supercede all the other rules below it, right?
Yes, the rule at the top of the list wins since any traffic will match it. All other rules won't apply, especially with an any rule at the top. The other rules should not matter whether you leave them there or disable them.
I also had a look at the status graph. Interestingly, at the time of the last dropped voip call, packet loss was close to 6%, and there was a spike in the delay average and std dev. Could this indicate an issue with my ISP connection? Or was that all coming from my voip connection?
6% loss might be enough to cause issues with VOIP. The quality graph under monitoring has nothing to do with VOIP or any other traffic on your LAN. This is the status of pings to whatever monitor IP you have set. It is usually a good indicator of your ISP connection, although not always. What is set as the Monitor IP under System > Routing > Gateways?
The default is blank (gateway IP), but you can set this to an IP on the web such as Google's DNS server. That might be a better indicator of the connection health.
This does sound like an issue with your connection to the web though. Before contacting your ISP about it, I would replace the Ethernet cable between your modem and the WAN interface on pfSense.
-
There was nothing set for the monitor IP, so I just updated it as you recommended.
Funny that you mentioned the Ethernet cable between modem and WAN - I had the exact same thought and last night replaced it with a brand new CAT6 cable, just to rule out the possibility of cable damage being the cause of what I am seeing.
-
Since switching the ethernet cable, I have not seen any significant packet loss. There is some variability in the delay statistic though. I have not had to make or receive any phone calls today to test out the voip.
-
@pfguy2018 said in DNSBL keeps restarting:
Since switching the ethernet cable, I have not seen any significant packet loss. There is some variability in the delay statistic though. I have not had to make or receive any phone calls today to test out the voip.
Ok, good keep an eye on it. Your delay average and standard deviation were all over the place in your original screen shot. Is it still like that after changing the cable and the monitor IP? A good connection should not vary that much. You can see my numbers vary too but not by as much.
-
See below - cable was changed at around 7 pm last night. It looks like dropped packet numbers have improved, but there is still a lot of variability in delay. Also, I noted that at the exact time I was on the phone (not a voip call, but WiFi calling on my cell phone (since our cell signal is so poor in the house, I have to turn on the WiFi calling feature), there was a spike in dropped packets up to 7.45%, although the call did not drop. So I am starting to wonder whether I need to get my ISP involved here. Your thoughts?
-
Is this a cable modem? Have you tried power cycling the modem? Pull the plug for at least 20 seconds or so then plug it back in. I've had odd problems solved by simply doing that.
-
Yes, cable modem. And yes, was rebooted after changing the ethernet cable last night.
-
Ok, get in touch with the ISP then. If they charge you to come out to diagnose, you might be better off doing some simple diagnostics yourself. Check your COAX lines throughout your house. Make sure there isn't something obviously wrong with where they connect.
-
Thank you for your help and advice - much appreciated.
-
What kind of hardware is pfSense installed on? If you have any extra network ports available on the system, it might be work trying to reassign your WAN to one of the unused ports and see if the problem goes away. Or swap the LAN and WAN assignment and cables to see if that helps. It probably won't solve the VOIP issue, but might help you figure out if it's port/NIC related if the monitoring graphs improve.
-
@Raffi_ Good thought. It is an SG4860. All ports currently in use, but I can probably rejig things to try that. Just have to find the time.
