FreePBX 17.0.19.28
on Debian 12
I patch about once a month.
OK, this is weird. I had this happen to 3 sites where it blocks the site from pinging and connecting. The logs say it can’t reach my 3 sip providers and I can’t ping the site listed from freepbx. From any other computer on the same network I can ping it. I can ping many other sites from FreePBX just not my sip providers. I have tried restoring from backup but that did not work. I tried turning off the firewall but that did not work. I tried checking that there are no other devices with the freepbx ip (turning freepbx off and ping its address and then check my mac tables to see if there was something that isn’t pingable). Turning off the router and switch for a minute and bringing it back up in case of a corrupted mac table. Nothing worked. I checked the ip information and it was all correct. What else could be blocking a ping from freepbx? This happened after an improper shutdown. Something seems odd about the networking on freepbx. I have never had this happen on any other linux computer (or any other computer for that matter).
I did a fresh install on a fresh vm and I restored and got it working but that was a whole other mess I’ll post a new topic about that. I would still like to know what else could be causing it from pinging certain ip’s? This is just happening on a freepbx install. I have been using Linux for over 20 years. I have never had anything like this ever happen before. I still have the vm in an off state to test if anyone has ideas. I am scared of this happening again. The first sip provider it blocked the site provider had other sip addresses I could pick from that was 3 months ago. The recent 2 happend a few days ago. I could have picked a different site for one but this is getting ridiculous.
It should not be hard to see where the ICMP is being dropped.
tcpdump ‘listens’ to received packets before any software firewall (iptables), and transmitted packets after iptables.
So, if tcpdump doesn’t show the ICMP echo request, iptables is blocking the transmission. If tcpdump shows the echo request and echo reply, but the ping fails, iptables is blocking the reception. If it show the request but no reply, the failure is elsewhere.
If this is indeed an iptables issue, you can look at what is still there (after turning FreePBX Firewall off) by issuing iptables -vL
at a root shell prompt. iptables -F
will flush all rules, though some process might reinstate them, so give iptables -vL
again after ping fails to confirm that the rules are still gone.
If this is not an iptables issue, try tcpdump on the VM host. If not consistent with what shows on the VM (FreePBX), it’s a virtualization issue. The VM should be using bridged networking, with no filtering rules.
If tcpdump on the host shows echo requests going out but no replies, it’s a problem with your hardware router/firewall or modem. If your router supports packet capture on its WAN interface, check there to see whether the router is blocking packets.
Yeah I’ll have to try some experiments. I’ll see if debian packages a command line wireshark that I saw recently on lxer or someplace. Although tcpdump isn’t hard. I thought freepbx would have turned of iptables or firewalld when I “turned off the firewall” but I can check that too. Thanks for giving me something to check.
Chance that this is a provider block is between slim and none:
OP had verfied that he can’t ping from the PBX but can from another host on the same LAN.
So for this to be a provider issue, he would need multiple public IPs, with the two hosts routing through different addresses, all three of his providers blocked the PBX address, in a way that affects icmp.
Any computer on the same subnet would also get blocked and I verified I could ping from any other. Besides it is working since I moved to a new vm. I’m keeping the other vm to help troubleshoot.
So after 2 days off the broken vm is now working. Rrrrr what ever was blocking is temporary but lasted hours. I was pinging on my other system at the same time so I know it was something on the vm.