Unable to move traffic on port 80

[grymlock]

Our PBX in a Flash system has been running perfectly for about 5 months now with no glitches until last Friday. On last Friday accessing the FreePBX interface became extremely slow as well as on other browser based apps we use. It takes approximately 4 to 5 minutes to get to the interface. The other browser based apps we have use non- standard ports and work just fine. No system updates or new programs have been added in over two weeks.

I ran a netstat to see what was running and noticed this line:

tcp 0 53 10.10.1.240:52696 174.37.6.70:80 FIN_WAIT1 -

This has been there for a quite awhile. I did an nslookup and found the IP to equate to gw.wardmundy.com. This process has been on port 80 for a few days. I am unable to clear it, not even by rebooting the system. Does anyone know why the system is going to this address and what is does?

Also, in the message log I see this error every hour (which might be related):
Jun 29 17:12:34 pbx yum-updatesd-helper: error getting update info: Cannot retrieve repository metadata (repomd.xml) for repository: base. Please verify its path and try again


Any assistance would be appreciated as I have been working on this all weekend and have not found the answer.

Thanks, Jeff

 

[MyKroFt]

check and make sure your dns queries are resolving. I added a 2nd dns server to my resolv.conf file as a fall back.

 

[grymlock]

We are using IP addresses, not FQDNs....Also, this is on the inside network as well as the internet....Going from my workstation to the server on the same subnet of the internal network gives the same result....

 

[MyKroFt]

well, i had the same problem one time and it was because it could not resolve ips to fqdns

dunno what it was trying to look up

 

[grymlock]

I have three DNS servers list, one internal and two public.

 

[MyKroFt]

does the machines hostname resolve?

 

[grymlock]

Yes it does...

 

[dswartz]

" tcp 0 53 10.10.1.240:52696 174.37.6.70:80 FIN_WAIT1 -"

I find it hard to believe the same socket is stuck when you reboot. Does the port number on your end (in this case 52696) change next time? FIN_WAIT_1 means your end tried to close the connection, but the other end never replied (never even ACKed it for that matter.) Do you have a router/firewall between you and the outside world? I wonder if it is blocking the ACK from his end?

 

[grymlock]

I do have a Firewall and a Router between the internet and the internal network. I have power-cycled both to make sure the issue was not there and it is. This is happening on the inside as well....

 

[dswartz]

That wasn't my point - I wasn't implying the router was stuck, I was more getting at: maybe it is blocking the return traffic for some reason. You also didn't answer my question about the port number changing.

 

[wardmundy]

Put the server in the DMZ temporarily and see if it eliminates the problem. If not, it sounds like DNS on your server is hosed. If so, something is blocking necessary packets between your server and the outside world.

 

[dswartz]

Ward, this is not a DNS issue - that would not explain sockets being stuck in FIN_WAIT_1 state. I do agree with your DMZ suggestion though.

 

[grymlock]

I have a question, if the issue exists on the inside of the firewall, will putting in the DMZ help?

Also, I noticed another error I am getting....

pbx yum-updatesd-helper: error getting update info: Cannot retrieve repository metadata (repomd.xml) for repository: base. Please verify its path and try again

Would the above error be caused by this issue?

 

[grymlock]

We found the culprit. Our Nagios server was causing the issue. The minute I stopped Nagios from monitoring the PBX in a Flash system everything started to work. Now all I need to do is find out why after it has been monitoring the PiaF server since day one......

Thanks for all the help....