What does a netstat -an show for port 80?

tcp6 0 0 :::80 :::* LISTEN

Nothing for tcp? (as in, ipv4)

That depends how I define it in Apache: using 0.0.0.0:80 it listens only to tcp4 -

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN

with 80 it only shows the tcp6, which according to other source should be expected:

> The fact that netstat shows only tcp6 here is not the problem. If you don't specify an address to listen on, apache will listen on all supported address families using a single socket (for design reasons, sshd uses a unique socket per address & address family, hence showing up twice in your netstat output).

But with either solution, I can enter and connect from the outside with Apache, it just does not actually give any response….

Can you connect from the outside using curl and try`` curl -ILv`

```

Didn't try that with curl, but that gives :

> * Rebuilt URL to: ***/

• Trying ***…

• Connected to * (*) port 80 (#0)

HEAD / HTTP/1.1

Host: ***

User-Agent: curl/7.43.0

Accept: /

>

• Recv failure: Connection reset by peer

• Closing connection 0

curl: (56) Recv failure: Connection reset by peer

Which is the same as what I did try with telnet:

> ~> telnet *** 80

Trying ***…

Connected to ***.

Escape character is '^]'.

GET /

Connection closed by foreign host.

While exactly the same but locally (first logging in via ssh) responds fine:

> ~> telnet *** 80

Trying ***…

Connected to ***.

Escape character is '^]'.

GET /

Welcome

Connection closed by foreign host.

Or the more verbose response from curl:

> ~> curl -ILv ***

• About to connect() to *** port 80 (#0)

• Trying ***…

• Connected to * (*) port 80 (#0)

HEAD / HTTP/1.1

User-Agent: curl/7.29.0

Host: ***

Accept: /

>

< HTTP/1.1 200 OK

HTTP/1.1 200 OK

< Date: Thu, 12 Apr 2018 14:09:26 GMT

Date: Thu, 12 Apr 2018 14:09:26 GMT

< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips

Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips

< Last-Modified: Fri, 23 Mar 2018 12:46:03 GMT

Last-Modified: Fri, 23 Mar 2018 12:46:03 GMT

< ETag: "1c-56813ce9f9ee6"

ETag: "1c-56813ce9f9ee6"

< Accept-Ranges: bytes

Accept-Ranges: bytes

< Content-Length: 28

Content-Length: 28

< Content-Type: text/html; charset=UTF-8

Content-Type: text/html; charset=UTF-8

<

• Connection #0 to host *** left intact

Examine apache error log and make sure netstat -p shows you that it is apache (and not any proxy or whatever) that is listening on the web port.

If you're using vhosts, can you check the vhost block and make sure it's set to listen at "*:80".

I still have no idea what happened, but it must have been something at the university level that blocked or intercepted communication on port 80 (and not on other ports, I had a WebMin server running), since without me doing anything, it suddenly started working. So clearly the server was properly set-up, but nevertheless it did not work outside of the university… I didn't even know that was possible, but it clearly is.