sagency
Forum Replies Created
-
So trying to get this straight between both your responses. The 4 hours+ it took us the other day on behalf of our client that we can’t bill for. No one is going to pay hundreds of dollars for an IP issue that might have been a false positive, yet that client wouldn’t have the experience to ask some of the right questions and be concerned when they got notifications from Wordfence their site could be vulnerable.
What really caused this? At this point it sounds like a SiteGround ip redirection strategy or application that didn’t go so well, not a Wordfence issue. Never really getting to an answer here. Just got explanations from Siteground chat agents, supervisors and escalation team over and over again that SiteGround had nothing to do with it. Wordfence seems to say their plugin wouldn’t generate that warning from any sort of caching issue.
@hristo-sg Glad it will soon be over, but I’d really like a straight answer on this because it had a very negative impact. I’d like to keep all our agency clients at SiteGround.
@wfgerald @dipaksaraf
The issue was resolved yesterday I think after a lot of persistence with Siteground escalation team. I really don’t think more propagation time after 4 days was the reason, it seems there is a temporary redirect Siteground puts in place so if people have their domain at another host the new server address will still work.How and when that temporary redirect is removed by Siteground I don’t know, but in another post the Wordfence developer said other people contacted Siteground and *poof* the problem was gone. Leads me to believe there might be a way they can kill the original redirect which was mean to be helpful. I dunno. Server stuff is beyond me.
Siteground is a great host. Usually excellent service. Just some confusion over how this is happening and how some people seem to get it resolved with no issues and in my case it took about 4 hours of working with them between chats and tickets. 4 hours I could not bill my client.
@dipaksaraf I recommend making sure you update your domain settings exactly to the specs Siteground told you to and after 72 hours if IP detection is still off, contacting their escalation team and notifying them, asking them to check for a redirect issue.
And like we said before, we DID change the A record correctly to Siteground specifications (verified by Siteground) and after 4 days the IP detection was still off. Still think it’s highly unlikely that it wasn’t fully propagated.
We removed and reinstalled Wordfence, same problem. Another user here tried a different plugin and it STILL indicated IP detection issues.
@wp510 very insightful a different IP analyzer had the same issue. We had our A record changed for 4 days and even removed and reinstalled Wordfence and had the issue until we persisted with the Siteground escalation team. Then *poof* the error went away.
Still find it interesting the Wordfence plugin author says other people contacted Siteground and the problem went away. For me it was hours of chats and tickets. Hoping this trail of info will help Wordfence users and Siteground. Gotta be a way to improve this situation. Siteground is a great host.
- This reply was modified 6 years, 4 months ago by sagency.
@hristo-sg you recommend disabling Wordfence 48 hours, but as I stated before, this client had the A record properly changes for 4 DAYS!
@wfsupport can you speak to whether that is indeed a WordFence long caching issue? I kind of doubt it because I removed and reinstalled Wordfence and the problem persisted. Until I pressed SiteGround’s escalation team and then it magically went away.
- This reply was modified 6 years, 4 months ago by sagency.
@starsknight my limited understanding is Siteground has some sort of redirect from old server to new in case owners are slow to get domain records changed. It sounds like during that time a flood of traffic could come from the old server location to the new and appear as a brute force attack. I’m piecing that together from Siteground’s updates.
@hristo-sg
“There is an IP redirect in place for those customers who haven’t updated their A records.”Our client properly changed their A record 4 days ago. Don’t you think an A record would have already propagated? Why would SSL be working if it hadn’t? All the DNS checkers indicated it was done, your own techs said it all looked fine, but the IP issue continued.
Was this a redirect somehow from your old server to the new Google one that was not removed in a timely fashion? Just trying to understand here and for the benefit of everyone else who runs across this warning in Wordfence.
- This reply was modified 6 years, 4 months ago by sagency.
@hristo-sg
“There is an IP redirect in place for those customers who haven’t updated their A records.”Our client properly changed their A record 4 days ago. Don’t you think an A record would have already propagated? Why would SSL be working if it hadn’t? All the DNS checkers indicated it was done, your own techs said it all looked fine, but the IP issue continued.
Was this a redirect somehow from your old server to the new Google one that was not removed in a timely fashion? Just trying to understand here and for the benefit of everyone else who runs across this warning in Wordfence.
Reporting back so that anyone with Siteground may benefit.
After 4-5 hours of on again / off again chats and tickets and escalations they blame a recent migration to their Google server and DNS propagation. I’m suspicious of that because it was one A record that was changed about 4 days ago at GoDaddy to point to Siteground’s new server. Never had a propagation last that long which leads me to wonder if it is a configuration issue.
My recommendation if you are a Siteground customer who they forced onto a new Google server and experience this issue is to put in a ticket about this and specifically ask for it to be escalated. My hope is after my incident and “assertiveness” they have some documentation for their techs to either take care of the issue or advise you about the propagation. Dimitar Dimov
is a Technical Support Supervisor there and when he gave me the final report back on the ticket somehow magically the problem was fixed.- This reply was modified 6 years, 4 months ago by sagency.
@wfsupport @starsknight @bracked
Reporting back so that anyone with Siteground may benefit.
After 4-5 hours of on again / off again chats and tickets and escalations they blame a recent migration to their Google server and DNS propagation. I’m suspicious of that because it was one A record that was changed about 4 days ago at GoDaddy to point to Siteground’s new server. Never had a propagation last that long which leads me to wonder if it is a configuration issue.
My recommendation if you are a Siteground customer who they forced onto a new Google server and experience this issue is to put in a ticket about this and specifically ask for it to be escalated. My hope is after my incident and “assertiveness” they have some documentation for their techs to either take care of the issue or advise you about the propagation. Dimitar Dimov
is a Technical Support Supervisor there and when he gave me the final report back on the ticket somehow magically the problem was fixed.- This reply was modified 6 years, 4 months ago by sagency.
Reporting back so that anyone with Siteground may benefit.
After 4-5 hours of on again / off again chats and tickets and escalations they blame a recent migration and DNS propagation. I’m suspicious of that because it was one A record that was changed about 4 days ago at GoDaddy to point to Siteground’s new Google server. Never had a propagation last that long which leads me to wonder if it is a configuration issue.
My recommendation if you are a Siteground customer who they forced onto a new Google server and experience this issue is to put in a ticket about this and specifically ask for it to be escalated. My hope is after my incident and “Assertiveness” they have some documentation for their techs to either take care of the issue or advise you about the propagation. Dimitar Dimov
is a Technical Support Supervisor there and when he gave me the final report back on the ticket somehow magically the problem was fixed.- This reply was modified 6 years, 4 months ago by sagency.
Sure @starsknight. Going on a couple hours of Siteground’s escalation team either saying it isn’t them (contrary to what @wfsupport wrote) or not responding to ticket updates which is unusual. They are usually great about service and quickly.
They moved my client’s site to a new server and instructed him to go to GoDaddy and change domain settings. All that went well and was done correctly, but apparently Wordfence didn’t like something about the change.
I will surely post any informative results from Siteground once I have them so people know specifically what to ask of them.
So to get rid of the 500 error…
Removed
auto_prepend_file = ‘/home/budgetca/public_html/wordfence-waf.php’
from php.ini and the site came back.Uploaded and re-activated the plugin, added the auto_prepend line back in and Wordfence is working as before.
Hope this helps someone else.
Siteground is EMPHATIC this is not something they can fix and it’s Wordfence’s problem. I’ve wasted two hours on this. How do we get this fixed or do we have to just bail and go with All in One Security instead?
Siteground makes it so hard to to setup your plugin firewall with php.ini. Half the time we can do it ourselves and other times following the same directions they have to do it.
- This reply was modified 6 years, 4 months ago by sagency.
Siteground is emphatic this is a problem with Wordfence and has sent me back to you.