Skip to main content

Charter users unable to access my server

GoWilkes
I've been having an issue for about 24 hours where Charter / Spectrum users can't get to any site on my server. IBM / Softlayer blames it on Charter, Charter blames it on them, so no one is actually working to fix it >:-( This is particularly hard to track down because I can't recreate it on my end, I have to rely on my users to do the heavy lifting for me! As far as I can tell, though, when I run "mtr" from the server to their IP they are all failing at the same location: b8.10.35a9.ip4.static.sl-reverse.com 169.53.16.184 The traceroute from my home PC (not using Charter) doesn't hit that particular hop, though, so this feels like a likely culprit. It belongs to IBM / Softlayer, but I don't find it on any blacklists and I'm able to ping it just fine from both the server and from my home PC. So I'm not really sure what's causing the failure for Charter users. To rule out anything on my end, I turned off CSF entirely, but it had no impact. I also turned off cPHulk (even though I'm almost positive it wouldn't affect the site loading), but no word yet on whether that helped. Is there anywhere else that the server might be blocking an IP? If not, any other suggestions on where to look?

Comments

5 comments

Date Votes
  • cPanelLauren
    It's entirely possible there is a network issue, if the MTR stops at that hop and the SoftLayer IP you're noting times out, if your provider is SoftLayer and that IP is not yours showing them the traceroute from your server should be sufficient. If neither is related to your server it's likely a networking issue with charter communicating with Softlayer on route to your server and the only way to prove this though would be to have a charter customer perform a traceroute/MTR from their local machine to your server.
    0
  • GoWilkes
    Well, it took 30 hours to get Softlayer to assign a tech to the case, but once they did he had it fixed in less than 10 minutes. I have an unrelated ticket that I opened on 2/27 at 11am, and the only response so far was from a bot at 2/28 at 1:30pm that said "Please standby for further updates from our technical support team". After IBM bought out Softlayer, they are by far the worst imaginable... and I once used BigBytes! I've gotta find a new provider.
    0
  • cPanelLauren
    I'm sorry to hear that but I am happy to hear that they were able to resolve the issue. Did they let you know where the block was?
    0
  • GoWilkes
    Nope, no real input at all >:-( But for future readers, I DID discover that Linux has a built-in firewall separate from CSF, called iptables. I've had a dedicated server for 10+ years and had never seen it before!! I had an issue yesterday where I couldn't FTP to any of my accounts other than root (which was also happening when I posted the thread), and I traced it back to iptables. Mine has been running for 5 years and is HUGE, so I suspect it has been the source of at least some of my problems. To see what's going on with it, SSH to your server as root and run: # iptables -L This will show the entire list... mine was still running after 15 minutes, so I used Ctrl+C on my Windows keyboard to break out of it. You can stop iptables using: # service iptables stop Note that when you restart the server it will start back. Stopping it only takes a second, though, and you can see if it's causing your problem. If so, you can flush the tables using: # iptables -F Mine ran for 30 minutes, timed out, and then the server wasn't responding so I had to reboot. When it came back online the file hadn't been flushed at all, so I'm going to try to flush it with CSF tonight using: # csf -f Once the tables are flushed, iptables -L should return a much smaller list (or none). Then you can start iptables using: # chkconfig iptables on # service iptables start I hope this helps others!
    0
  • cPanelLauren
    To better explain this, yes CentOS uses iptables/ip6tables this is the only firewall on the server, the other services you add like APF, firewalld (The default) are Firewall Management Services - they provide you a more user-friendly method to interface with iptables. On CentOS 7 which uses systemd as opposed to init.d the commands to manage the firewall are a bit different (they're mapped to the old methods but won't be forever) Stop iptables: systemctl stop iptables
    Start iptables systemctl start iptables
    I prefer this format for listing rules: iptables -nvL
    To properly flush the iptables rules (including those CSF or another firewall management system has added) - We'll use CSF as the example. You'd want to perform the following: Disable CSF (this will keep it from restarting automatically) : csf -x
    In most cases you'll see that the iptables rules are flushed automatically when this occurs - to see if any rules still exist you can do the following: iptables -L
    or mine which is: iptables -nvL
    If you still have rules present you can flush iptables temporarily by doing the following: iptables -F
    Restarting iptables will bring these rules back unless you first run the following: iptables-save
    When you save you save the configuration as it is. Either way when you restart CSF the CSF specific rules will come back. To re-enable CSF you would perform the following: csf -e
    start it would be: csf -r
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post