Specific IP address not able to access vicidial on port 80

[dspaan]

Our callcenter can not reach the vicidial server anymore via HTTP.

At the same time we can connect fine to vicidial via HTTP from other locations.
We checked the firewall config but the callcenter IP should have access on port 80
We tried by disabling the firewall but no luck.
We checked the firewall log and fail2ban log but nothing in there either.
No errors in the apache logs.

Nothing, we can't find out why this is happening. You simply get a timeout message in every browser (IE or chrome) on all workstations. We also tried making an exception by attaching one workstation to the modem of the callcenter directly and bypassing the firewall in the callcenter but the problem remains the same.

I suspect this IP is still being blocked somewhere in OpenSUSE but we can't figure out where.

Or it's a routing issue somewhere else on the internet, but that doesn't make sense either because from that location i can ping the vicidial server and also access it by SSH on port 22. Only HTTP is blocked. We also tried binding apache to port 88 which worked fine from other locations but not from the callenter IP again. We also tried HTTPS but no dice.

We also tried to do telnet to the vicidial server. This works from any authorized location in yast firewall but again not from the callcenter IP location.

Any suggestions? Never seen this problem in 5 years working with vicidial.

[dspaan]

Solved: After a quick call with vicidial support we found that the issue was in /etc/asterisk/sip.conf

Before i gave this server the IP of the old server i gave it a temporary IP when i moved it from hardware machine to the other. This IP was still set in the sip.conf under the externip setting.

For some reason this value is not being update when you run the server update ip script. Or i made a mistake. Anyway, this also caused inbound calls not to come in and SIP connections getting killed after 60 seconds because of lack of RTP activity.

[williamconley]

That setting is the one that always avoids scripting because its "need to be changed" is different based on your carrier and networking configuration(s).

So you must ALWAYS check the value of externip during any IP change scenario, outside the ip update script.

Always.

[dspaan]

For some reason this tuesday out of the blue we were not able to access the vicidial server again from that same IP. I could not find any reason for it. I checked with the datacenter network department and they said that the IP is not being blocked. I could not find anything.

Is there some sort of security mechanism in the latest vicibox 7 apart from the OpenSUSE firewall and Fail2ban that could be causing this?

After about 2 days we could access the vicidial server again from that IP.

[williamconley]

Code: Select all

iptables-save

it'll be in there somewhere ... IF the vicidial server is dropping the packets.

there are also logging options within iptables to find out whose packets are being dropped.

And then there's the "reboot the router!" method and the "are you sure it's not DNS?" question.

[dspaan]

Hi Bill,

iptables-save show's the IP address but only ACCEPT rules.

There also is a Yast Firewall log which you can check if packets are being dropped and it showed nothing at the time.

Also it can't be DNS because we tested by connecting IP based.

And i can't reproduce it anymore because it started magically working again.

[williamconley]

I'd also consider:

What if you were experiencing a brute force attack on your outer firewall? Been known to cause similar issue.

I'll repeat that "reboot the router" bit from earlier.

And my personal favorite: It may not have been you, but an interlink somewhere between your ISP connection and the vicidial server's ISP connection. These happen from time to time and are usually very temporary. We've had several clients "cut off" for anywhere from a few minutes to half a day. Some have even had to call tech support for their ISP and actually had it fixed during the support call. And it was ONLY affecting their connection with a very specific range of IPs. In a couple cases, it was "Us" and "Godaddy". LOL

[dspaan]

If it was an attack other IP's would have had the same problem of if you mean the source IP then it would not have been able to access other hosts.

I think it was the latter but those problems are hard to tackle, ISP's always say it's your fault and not theirs.

[williamconley]

traceroute is a useful application sometimes.

firewall logging is also useful

and iftop is very useful.

[dspaan]

instead of traceroute i often use MTR which is a combo of traceroute and ping

[williamconley]

If it was an attack other IP's would have had the same problem ...

Not always. And it depends on which side of your problem is experiencing the attack, and how your router is handling the scenario. Some brute force attacks have been known to fill the MAC address table in a router, and no NEW access attempts will work after that moment. Networking is tricky. There are enough rules to make all the rules appear more like "guidelines", LOL