I apologize in advance if I use any technical words in the wrong way. I'm still a newbie to Linux/networking
Ive been trying to figure out this problem for over a week and none of the related questions others have asked have helped me. I recently built a webserver running on apache2 to host my own website. I also intended to use it for SSH, FTP, and VNC. I registered a domain at GoDaddy, cokongwu.com. A static ip (192.168.0.105) has been setup for the server and I have setup portforwarding as well for port 80, 21, 23, 53 and 443 to the static ip. reading the guides on how to setup a publicly accessible webserver, I thought this was all that was needed, as it was working perfectly at first, but of course I found out that once I tried to access the webserver using the domain name outside the network, I couldnt connect. After some more searching I found out that I needed to change my A record in my zone file at GoDaddy to my public ip. Once I did that I found that I was no longer able to connect to my webserver at all, either inside the network, where I would instead be redirecred to the router page, as well as outside the network where the connection would simply time out. I later figured out that since my public ip couldnt be set to static I had to use a service, specifically dyndns so that it would be able to constantly update the ip when it changes. I setup the dyndns updater from the software update center and setup my dyndns account, cokongwu.com, with an A record that points to my public ip and an alias www.cokongwu.com that points to cokongwu.com. I also setup a hostname, cokongwu.dyndns.org which also points to my public ip and added the dyndns nameservers to Godaddy's nameservers. The A record I have for cokongwu.com at godaddy still points to my internal ip and the CName records (www and cokongwu.com) both point to cokongwu.dyndns.org.(however, since I replaced godaddys nameserves with dyndns nameservers, I can no longer manage the zone file for the domain)
After all this, trying to access hostname.com still provides the same problems as before. Accessing it points to my public ip instead of my internal ip, but within the network I just get forwarded to my routers setting page and outside the network it just times out. I'm out of ideas as to how to fix this, so any ideas are welcome. Shouldnt it(the public ip) be redirected to my internal ip?
Once again sorry if I'm using any of these technical words in the wrong way, I'm still very new to this whole thing.
I know a lot of questions related to this post certain commands so I'll do the same:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:5556 0.0.0.0:* LISTEN 3387/dyn_updater
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 2729/vino-server
tcp6 0 0 :::80 :::* LISTEN -
tcp6 0 0 :::21 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:631 :::* LISTEN -
tcp6 0 0 :::5800 :::* LISTEN 2729/vino-server
tcp6 0 0 :::5900 :::* LISTEN 2729/vino-server
udp 0 0 0.0.0.0:5353 0.0.0.0:* -
udp 0 0 127.0.1.1:53 0.0.0.0:* -
udp 0 0 0.0.0.0:39124 0.0.0.0:* -
udp 0 0 0.0.0.0:631 0.0.0.0:* -
udp6 0 0 :::5353 :::* -
udp6 0 0 :::53973 :::* -
ufw:
sudo ufw status
[sudo] password for fender:
Status: inactive
000-default.conf:
<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
ServerName cokongwu.com
ServerAlias www.cokongwu.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Best Answer
From what i understand you're having the following problems:
1 - Unable to access the web server (using the FQDN, "fully qualified domain name" www.cokongwu.com) from inside the LAN?
2 - You're unable to verify functionality of the website from the outside?
1 - Access to the web server from the inside using FQDN.
I can't see in your question from where you're trying to access the web server, so i'll asume it's from a separate client inside the LAN.
Since you're most likely using an external dns server, your request for www.cokongwu.com will resolve the publicly available IP number, meaning the outside of your your internet router(see below). Since that router wont route traffic coming to the external IP number from the inside back to the inside, traffic will stop at that point.
For things to work inside the network, www.cokongwu.com wil have to be resolved as your internal IP number (192.168.0.105). You can try to browse the web server using the internal IP number, but since you plan to use SSL, eventually that will require you to access the web server using the FQDN or you will get certificate errors.
The "hard way" to fix internal name resolution is to setup an internal DNS server, but the above will work trouble shooting and small scale deployments. You seem no stranger to google and if you want to set up an internal DNS server, there are many guides to that on the internet.
Once internal name resolution gives you the internal IP address, browsing to the web server will give the same reply as if you we're a client coming from the outside.
2 - external access to the web server.
Resolving www.cokongwu.com with
dig www.cokongwu.com +noall +answer
gave me the following reply.www.cokongwu.com. 0 IN CNAME cokongwu.com.
cokongwu.com. 59 IN A 69.171.137.28
This shows that the www host is a cname (alias) pointing towards cokongwu.com which is a A-record. Doing a reverse lookup on 69.171.137.28 with
dig -x 69.171.137.28 +short
gives:dsl-69-171-137-28.acanac.net
This looks like a dynamic host. If the dyndns update is working, that should be your current public IP address. Verify this with the following command at a command line:
(shamelesly stolen from here) Or by browsing to www.whatismyip.com
Assuming this is your current, browsing to www.cokongwu.com should work from the outside ...
I tried that and it didn't work, which could mean any or a combination of the following:
A - The dyndns service hasn't updated your IP address
B - The forwarding in your outside router isn't working
C - The web server isn't replying
Doing a quick test using
telnet <ip number> <port number>
gives no replies from any of the port numbers you listed above. This would lead me to believe that the reason should be A or B. If it is B, it could be that you either didnt port forward correctly or if you're using a router in conjunction with your modem, you haven't properly bridged the modem to the router to allow it to handle all portforwarding requests.Some further thoughts
I notice that you mentioned port 53 as one of the ports forwarded to the web server. Port 53 UDP is the standard for incoming dns requests. Unless you actually have a dns server running on the web server machine, you can safely close this port ... it wont serve any purpose anyway.
I also noticed you mention using ssh and ftp, but opened port 21 and 23 in the firewall and forwarded to the web server. Port 23 is the telnet port and port 21 is the FTP port. I would strongly advise using neither of these services, since they're both unsafe protocols that will transmit everything in clear text, including usernames and passwords.
I recommend only opening and forwarding port 22 in the firewall. Port 22 is used by ssh, which is the encryopted replacement to telnet. Port 22 is also used by the scp service, which use the ssh service for file transfer. Using ssh and scp instead of telnet and ftp will keep all your traffic to and from the web server secure.
A further recommendation would be to use a different port for incoming ssh, preferably a port number over 1000, like port 1522 (just an example). This is to avoid the incoming ssh service to be discovered by external port scans. Simply change the incoming port from 22 to a higher port number (i.e. 1522), but still keep it forwarded to port 22 on the web server. Then access the ssh server from the outside using the high port number (1522) and from the inside using port 22.
I hope this is of any use to you and hope you solve your problem =)