Cannot access my server from an external IP a second time

What are your firewall rules?

The server is running Ubuntu 16.04 OS and firewalled via the Xfinity router.

I can't seem to look at the rules within Xfinity.

Is your server also running firewalld?   I think that's the name of the daemon.     Use 'systemctl list-unit-files' to check.    What's the output from 'iptables -L'?  What about 'ip6tables -L'?     If you can, capture a tcpdump of the interface while a remote machine tries to access your web server.    If you get packets arriving on the interface but not making it up to apache for service then the problem is most likely in your apache configuration.    If you only see the initial connection to your web server and subsequent attempts fail, then look for a firewall somewhere.    If your iptables are clean then the next step is the router.

iptables -L does not refer to http at all - just https

ip6tables -L shows port 80

it will take a while to get my friend to access the server again - he's at work.

systemctl list-unit-files - unknown operation - list-until-files

iptables -L was lengthy - what do I look for?

You might try turning off Xfinity Advance Security though your account in Xfinity web site.

I could not get to my servers remotely and found Xfinity Security that was just turned on this morning by XFinity was now blocking.

The test was run and I did not see either attempt in the log. I just checked and I'm running the UFW firewall on the server with both ports 80 and 443 allowing two-way traffic on both ip4 and ip6. On the tcpdump I saw mainly ip6 router advertisements,

Check your usage of systemctl:

root@mail:~# systemctl list-unit-files | head -10

UNIT FILE                                                        STATE          

proc-sys-fs-binfmt_misc.automount      static         

-.mount                                                          generated      

boot-efi.mount                                             generated      

dev-hugepages.mount                               static         

dev-mqueue.mount                                     static         

media-cdrom0.mount                                 generated      

proc-sys-fs-binfmt_misc.mount                static         

sys-fs-fuse-connections.mount                 static         

sys-kernel-config.mount                             static         

root@mail:~# 

If you have a working firewall then iptables output may be long.    I disable it which results in 8 lines each:

root@mail:~# iptables -L | wc -l

8

root@mail:~# ip6tables -L | wc -l

8

root@mail:~# 

root@mail:~# iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination         

root@mail:~# 

*Before* you disable all of your iptables, get nmap and see what ports are responding.    Check 'localhost' as well as the DNS name/IP address of the system:

root@mail:~# nmap localhost

Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-13 14:45 MST

Nmap scan report for localhost (127.0.0.1)

Host is up (0.000032s latency).

Other addresses for localhost (not scanned): ::1

Not shown: 999 closed ports

PORT   STATE SERVICE

22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 1.66 seconds

root@mail:~# nmap mail

Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-13 14:47 MST

Nmap scan report for mail (192.168.64.46)

Host is up (0.000032s latency).

Other addresses for mail (not scanned): 2601:681:4800:5bcc:3e07:54ff:fe5d:6ece

rDNS record for 192.168.64.46: mail.home.comcast.net

Not shown: 999 closed ports

PORT   STATE SERVICE

22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 1.66 seconds

root@mail:~# 

Do the same for IPv6 by using 'nmap -6'.    

Notice that 999 other ports are closed and unreported.   The first 1000 ports are considered privileged, well-known ports.    The above will give you a good idea of what's open with your iptables enabled.    Do it again after disabling iptables and see what's changed.   You want to test localhost because iptables generally does not filter anything coming in on localhost.     If you see more open on localhost than you do on your IP address then you know something is being filtered, or, if you see a port that is 'open/filtered' that's another possible indication of a firewall.  

If access to your web server works with iptables disabled then you know where to start looking.  Iptables can be complicated.    Start with 'man iptables' and work from there.  🙂      Good luck!

PS - you may want to nmap your public IP address, both IPv4 and IPv6.   Your router is your first line of defense against intrusion and if you're punching holes for people to access your web server.... well better to know what ports are open and potentially vulnerable and which ports are not.

Wnt through all your suggestions. I could not get the 8-line iptables command to work (on ip4 or ip6) - with the '8' on the end I received no such file or directory errors.

nmap localhost showed 990 closed ports. The ip6 version failed to resolve localhost.

nmap on the IP address and on the FQDN gave the same results.

I then saved iptables to a tmp directory and disabled iptables.

All the resuts were the SAME!! except nmap on the FQDN locked up.

It remain locked up after restoring iptables but came back after doing a init.d/networking restart.

I'll need to look at the Xfinity rules somehow to see if that's where the problem lies.

Many thakns for all your help.

🙂   I'm not following.   The '8' is the number of lines of output from iptables -L; it wasn't meant to be an argument to any of the commands.    If you have more than eight lines then you probably still have some set of rules in use.  

The nmap should not have hung.  You can test specific ports with 'nmap -p 80,443 '.   This will test for a listener on port 80 (http) and port 443 (https).     Those ports should be forwarded by your router to the actual host serving your web pages.   If these are not open then that is a problem.