Changed Web Server Static IP, then ERR_CONNECTION_REFUSED

After changing our old freebsd web server's static IP today, no one's able to browse to our website--either via the server's IP or our domain name. Firefox returns:
<IP or domain> refused to connect (ERR_CONNECTION_REFUSED)
I AM able to ping the server (and I'm able to ping yahoo, google or our domain from the server), so I'm guessing there's another conf file on the server containing our old IP that needs to be updated, but I've no idea what/where that is? Port 80 appears to be blocked at the server:
--- reading URL <new IP address>
--- contacting host [<new IP address>] on port 80
--- error: connection was rejected

Details...
1) I modified the following two lines in /etc/rc.conf:
ifconfig_vr0=”inet <new IP> netmask <new netmask>″
defaultrouter=”<new router IP>″

Then...
# /etc/rc.d/netif restart && /etc/rc.d/routing restart

2) After updating A Records for our domain's new static IP, an IP Lookup of our domain name returns the new IP, and a DNS Lookup of our domain name returns the correct new IP. So I know the updated A Records have begun to propagate.

3) Email is working. I can send/receive without issues.

I also rebooted the server just to be sure, but, otherwise, that's it.
Can someone tell me what I'm missing?
Many thanks in advance.
 
Which webserver are you running?

Usually the webserver's host configuration would reflect the IP address/interface that it is listening on.
For example, www/nginx config snippet:
Code:
server {
    listen 192.168.7.173:80;

    ....
}
Make sure that the web server config is adopted to listen on that new IP address.

You can run sockstat -4 -l to see all active listeners on your interface(s).
For example:
Code:
root@yourhost:~ # sockstat -4 -l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
www      nginx      10439 6  tcp4   192.168.7.173:80      *:*
www      nginx      10437 6  tcp4   192.168.7.173:80      *:*
www      nginx      10436 6  tcp4   192.168.7.173:80      *:*
www      nginx      10435 6  tcp4   192.168.7.173:80      *:*
root     nginx      10434 6  tcp4   192.168.7.173:80      *:*
root     sendmail   10426 4  tcp4   192.168.7.173:25      *:*
This can help to narrow down the problem.
You might also want to check/ensure that the firewall passes traffic on the respective port (apparently 80 in your case) through that interface (in case the firewall config would specify an IP rather than an interface).
 
Thanks for the quick response. I apologize for my naivete (I used to know most of this....really), but I haven't worked in 'BSD for 20 years and my skills are poor.

I honestly can't remember how to check the apache version, but I think it's probably apache1.something. I've tried httpd -v, but "Command not found".
But here's a screenshot of the output from sockstat...
 

Attachments

  • huntington.jpg
    huntington.jpg
    99.5 KB · Views: 75
Well now we have a problem because I haven't used apache in the last 20 years :D (not really 20 but was fun to say)

According to the output of sockstat that you showed, apache is running and configured to listen on ALL interfaces (note the wildcard).
As I understand from your first post, you are able to reach the server over the new IP. That is correct, right?
That would leave the firewall configuration as the most probable cause of issues. That would also align with the fact that the connection is being rejected.

You'd need to figure out which firewall you're using. On FreeBSD that would typically be PF, IPFW or something else I can't recall.
I'd assume that /etc/rc.conf would have some firewall config/setup going on which would tell you which firewall you're running. Alternatively, ps(1) would help.
Check the firewall configuration. Ensure that traffic on port 80 on that interface is allowed to pass.

At this point it might be helpful to post the contents/output of:
  • /etc/rc.conf
  • ifconfig
  • Your firewall configuration (whatever file that may be)
 
Yes, I AM able to ping the server via the new IP. Interestingly, I also just verified that I AM able to use a Windows-based ftp program to SSH into our email server (which is separate from the web server -- connected to it via ethernet) by way of the domain name. So the bottleneck is definitely within the web server.

I think the firewall's pf, which appears to be the case based on the output of /etc/rc.conf.
Again, I have NOT changed ANYTHING (including firewall configs) other than /etc/rc.conf between the time the web server was working (yesterday, with our old IPs) and today, with the new IPs. Hopefully, these will help..
 

Attachments

  • huntington 004.jpg
    huntington 004.jpg
    106.9 KB · Views: 61
  • huntington 003.jpg
    huntington 003.jpg
    79.7 KB · Views: 66
Here's a snippet of the last few entries in the pf log....
 

Attachments

  • huntington 009.jpg
    huntington 009.jpg
    93.4 KB · Views: 73
It looks like I'm also running ipfw because I have an /etc/ipf.rules that we use to limit server logins to a single IP (my home PC connection), which I change regularly (and update /etc/ipf.rules with each change).
But, again, I doubt that's the problem (unless one or both of the firewall conf files contains our old IP address) because server's been running running that way for years.

Here's the output of a web scan of the server's primary ports...
--- performing Server Scan on "<new IP>", please wait...
--- contacting server [<new IP>]

--- HTTP: (80)
(connection refused)


--- POP3: (110)
+OK Qpopper (version 4.0.9) at pitcher.<domainname> starting. <3182.1642733645@pitcher.<domainname>

--- SMTP: (25)
(connection refused)

--- IDENT: (113)
(connection refused)
--- Server Scan completed
 
Here's a question: Could the new modem/router the ISP installed along with our new IP be set to block port 80 by default?
I DID ask the tech, but he said, "It should be wide open, but if there's a specific port you need, let me know and I'll check it".
 
Like minds...
I'm logged into the modem, but I don't have the username/password to get in an check to see if port 80's blocked. So I've emailed the tech who installed the modem (he left his card for just this reason) and asked him to login and let me know what he finds.

In the meantime, based on the last few screenshots I posted, does everything look copasetic to you? Just trying to prepare for my next move in case the tech reports no blocked ports tomorrow....
 
but I think it's probably apache1.something
If it's truly Apache 1.3 then leave the host offline. Seriously. That version expired more than 10 years ago. So your FreeBSD install is probably just as old, I'm guessing release 6, maybe 7. Both ancient versions and have been end-of-life for a long time.

www/apache13
 
If it's truly Apache 1.3 then leave the host offline. Seriously. That version expired more than 10 years ago. So your FreeBSD install is probably just as old, I'm guessing release 6, maybe 7. Both ancient versions and have been end-of-life for a long time.
It's definitely old, but it's what we've got and suggesting that we dump the lot isn't helpful. I certainly would never say something as dismissive as that to you.
 
Not dumping the lot, migrate it to a recent, and supported, version and put that back online. This host is not only a high risk danger to your own infrastructure, it also affects the overall security of everyone else that's connected to the internet (your platform will get abused to attack other hosts).
 
It's definitely old, but it's what we've got and suggesting that we dump the lot isn't helpful. I certainly would never say something as dismissive as that to you.
I assure you that SirDice has only the best of intentions on his mind.
Could you elaborate how/why you perceived his post as dismissive? You're coming to this forum asking for help. You are apparently running some very, very old & outdated software which has been EOL'd a long time ago. The suggestion provided is pretty much the best in terms of help you can get/expect.
Other than in respect of your own security it's also very bad practice to leave a machine like this connected to the internet as it can (and most likely will) definitely end up in a bot net or similar used to attach other systems.
Leaving a system like this connected to the internet will not motivate any decent sysadmin to help you with your "actual" issue.

For historic reasons, can you provide the output of uname -a?

Something else I meant to mention yesterday: If you need to post information (eg. the content of a file) rather than taking photographs you can also just netcat to termbin.com. It's a simple pasting service.
Pasting a file:
Code:
cat /etc/rc.conf | nc termbin.com 9999
That will post the contents of /etc/rc.conf and return the URL on the console. You can then navigate to that URL on a web browser and copy-paste into the forum here.
This of course only works assuming your host has a working internet connection (which seems to be the case here).
I hope that's gonna save you some pain in the future :)
 
It's definitely old, but it's what we've got and suggesting that we dump the lot isn't helpful. I certainly would never say something as dismissive as that to you.

If you have not updated a system for ten odd years, then it is you who have already 'dumped' it.
 
If you have not updated a system for ten odd years, then it is you who have already 'dumped' it.
The system was running just fine prior to the IP changeover. And I still use a flip-phone, too. If it ain't broke.
 
Other than in respect of your own security it's also very bad practice to leave a machine like this connected to the internet as it can (and most likely will) definitely end up in a bot net or similar used to attach other systems.
Leaving a system like this connected to the internet will not motivate any decent sysadmin to help you with your "actual" issue.

For historic reasons, can you provide the output of uname -a?
4.11.
I'm aware of the system's age and, therefore, unpopularity. However, we have a number of custom scripts running on it that will likely not run on current kernels; and, based on previous experience, I lack the time, experience, confidence and 'BSD skillset to migrate the current system's goods onto a new one. So whilst I'm aware of the many shortcomings of the server, I'm also aware that, prior to the IP changeover, it was running quite well and I can see little good to be gained by risking the life of an otherwise healthy patient to administer preventative medicine. If there's now a requirement that only those running approved OS's can request help here, just say the word and I'll not inconvenience anyone here further.
 
However, we have a number of custom scripts running on it that will likely not run on current kernels
That is highly unlikely. You may need to tweak a few things here or there but overall the scripts should work just fine on a modern version.

I lack the time, experience, confidence and 'BSD skillset to migrate the current system's goods onto a new one.
This is the real issue here. Not the age of the system, or the potential migration issues.

If there's now a requirement that only those running approved OS's can request help here
This isn't anything "new". We've had the Forum Rules and Guidelines (REQUIRED READING) section from the start of the forums.

Topics about unsupported FreeBSD versions
 
check the ipfw list

In your rc.conf you have pf_enable which is for pf firewall and also ipfilter_enabled. So check your pf rules. You are not using IPFW but ipf (IPFilter)
 
However, we have a number of custom scripts running on it that will likely not run on current kernels;
One of the major reasons why I personally like (Free)BSD is exactly that: Stuff doesn't just change. Unlike other popular (server) operating systems, you can look at documentation from 10 or 20 years ago and it's still applicable. The same applies to software utilities. The system architecture is pretty static (I don't mean that in a bad way) and the kernel & surrounding system (world) are tightly coupled. There is no such thing as changing the init system two times a year or similar shenanigans. The same applies to the overall kernel (& kernel interfaces). You should be able to upgrade the system / migrate your custom stuff to a new FreeBSD version with ease compared to other operating systems.
 
JLAIP If I'm guessing correctly, your page involves <frameset> (which is also many years obsolete) and is trying to load the index page from somewhere else. That is where the error occurs. Look into that. Your server is being accessed just fine.
 
And I still use a flip-phone, too. If it ain't broke.
There is nothing wrong with using a Flip-Phone I'd say. There is also nothing wrong with using "old" server Hardware. This is about software & security.

"If it's truly Apache 1.3 then leave the host offline. Seriously."
You've now posted publicly that your site is down. Together with your username & profile picture it's easy to guess which one that is. The fact that no "usable" website is currently being served. You've disclosed publicly an internet-facing host with information regarding the software you're running (outdated Apache, outdates OS) together with the information on how to reach it. You're just asking for trouble at this point (this is not a threat). Hence the advice of SirDice to just take it offline which I assure you is in your best interest to follow.

Look into that. Your server is being accessed just fine.
That is actually correct. The favicon is being served just fine (200).
 
This isn't anything "new". We've had the Forum Rules and Guidelines (REQUIRED READING) section from the start of the forums.
Topics about unsupported FreeBSD versions
I read the forum rules when I joined.

From the link you posted...
"...we strongly encourage [my emphasis] users asking for help with these version to upgrade to a supported FreeBSD version before anything else, because it is quite likely that your problem is actually caused by running an outdated version....If you are not at liberty to upgrade to a supported version, you may still receive a reply to your question, but you must be prepared for continuous pressure from fellow users and forums staff to upgrade to a supported version."

In this case, the "outdated version" has nothing to do with the issue I'm seeking assistance with. I reckon I'd have exactly the same problem with the current/latest kernel. But I came for help, not to argue.
 
There is also nothing wrong with using "old" server Hardware. This is about software & security.
Exactly. I have systems that are many years old (technically they've been written off a long time ago), they still work fine with a modern FreeBSD version on it.

In this case, the "outdated version" has nothing to do with the issue I'm seeking assistance with.
Read the next paragraph.

We prefer not to encourage any further use of these unsupported versions. If you are not at liberty to upgrade to a supported version, you may still receive a reply to your question, but you must be prepared for continuous pressure from fellow users and forums staff to upgrade to a supported version. Moreover, some users may not feel like participating in topics that deal with unsupported versions at all. So be prepared for a lack of replies.
 
Back
Top