Surprising Revelation about the Apache Listening IPs

One of the details in my Apache configuration which I had placed emphasis on, was that this Web-server is supposed to listen on all IPv4 as well as all IPv6 interfaces, on the host-machine I name ‘Phoenix’. And so in the configuration file ‘/etc/apache2/ports.conf‘, I have set up so:


# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
        Listen 443

<IfModule mod_gnutls.c>
        Listen 443

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet


And, in the file ‘sites-enabled/000-default.conf‘ I have stated:


<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.



But, when I run the command ‘netstat‘, what that command seems to reveal is:


dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 80
tcp6       0      0 :::80                   :::*                    LISTEN
dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 443
tcp6       0      0 :::443                  :::*                    LISTEN


What I expect to see, is instead:


dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 80
tcp        0      0    *               LISTEN
tcp6       0      0 :::80                   :::*                    LISTEN
dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 443
tcp        0      0   *               LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN


Yet, contrarily to what catastrophic expectations might suggest, I find that my site is accessible to IPv4 addresses to begin with. Not only that, but I routinely use the internal, IPv4 loopback-address, and the URL:


To access my own blog. The surprising fact about this setup, is that it still works, and I could come up with some creative ideas, about why this has been working all along.

  • The router could be forwarding all the IPv4 traffic from the WAN, to a LAN-specific IPv6 address belonging to my host-machine,
  • The way the kernel works could be such, that if any server is listening on ‘:::80‘, it is also automatically listening on ‘‘.

My actual router settings only show my host as having an IPv4, LAN address.

I don’t understand it, but as long as this has not been creating any malfunctions, I’m not going to dig deeper into the subject for now. If indeed, my server was no longer listening on any IPv4 WAN addresses, I would have obtained notifications to that effect by now.


(Edit : )

This has just been confirmed as the standard behavior of Apache (to use just one socket), as described in this external BB posting.


I am working to establish IPv6 access to my site.

This little project kept me up late last night, and also accounted for a brief interruption in my server availability between 21h00 and 22h00.

I have set up a Teredo gateway, which gives limited IPv6 availability by way of an IPv4 tunnel, and which presents the local computer with a virtual IPv6 NIC. The ultimate goal of this exercise was, that people in the WWW who have native IPv6 access, should be able to access my site using this IPv6 address.

Right now the global address in question is ‘2001:0:53aa:64c:302a:2849:b9e5:30c7′, but it may change at any time.

While it seems superficially that I may have succeeded at achieving this goal, I am unable to give it a thorough test, because the Teredo gateway also does not allow loop-back access. For me to try loop-back access, I need to use the IPv6 address of the loop-back interface provided by my kernel, which is ‘::1′. The problem with this is, that it does not provide a thorough test, or even an adequate test. Certain single Web-pages display fine.

But in order for my blog, for example, to display correctly, it is not only the main, home page of the blog which must get served up, but also the many individual URLs embedded within that main page-view. And then what seems to happen with my own PC, is that even if I specified the IPv6 address literally as a URL to fetch (which requires embedding it in square brackets), all the embedded URLs are still resolved to the IPv4 DNS addresses by my browser, resulting in an inconsistency, which I believe will prevent any complex page from displaying.

The only way this blog will display correctly using its IPv6 address, is from a client, on which every reference to my host URL has an IPv6 resolution.



Loss of Internet Connection, Downtime

I take the unusual approach, of hosting my blog on my own private Web-server at home. One nasty side-effect of this is, that if my domicile loses its Internet connection, which for most homes would only be a minor inconvenience, my Web-site and blog actually go offline. This also differs from what other bloggers might experience, who host their blogs on professional servers, where professional admins do their best to avoid downtime.

This morning, starting at about 4h30, my home Internet started to experience instabilities. One of the details which I do not really know yet, is what might have been causing this. But my Internet was effectively out, from 4h30 until 14h30, at which time I took the step of power-cycling my router, which means, to unplug the router from its AC wall outlet, to wait for 60 seconds, and to plug it in again. Then, already having lost my connectivity, I also thought it best just to reboot my host-machine ‘Phoenix’.

So it could be, that my blog was visible to the Internet again by 14h45 this afternoon.

I still do not really know whether my connection is fully stable again, but it seems that way, except for my IPv6 connectivity, which is managed through a Teredo gateway. That Teredo gateway is still experiencing intermittent issues. One aspect of this problem which worries me, is that between 4h00 and 8h00, I had 3 changes to my IP address, assigned by my ISP. I have a system in place, called ‘DynDNS’, which updates this IP address to allow readers to resolve my URL. But when there are several changes within a few short hours, this automated system will also fail to keep updating the IPv4 address. And, the fact that this was happening also seems to suggest, that there was not one failure of my Internet connection, but perhaps rather, some malfunction of the router itself.

I apologize for the problems, to anybody who might have been wanting to read my blog, on a rainy Saturday afternoon.



DSL Modem Failure, Downtime

Atypically, I host this Web-site on my private server at home. When I got home today, I found that the DSL Modem / Router, which I rent from my ISP, had gone into a partially failed state, in which WAN access was still ‘normal’, but where attempts to obtain new IP addresses were not succeeding – i.e. My smart-phone could not connect to my WiFi when I got home. Also, maintenance access, which has only been enabled from within my LAN, did not succeed to check the router status.

The only solution I could think of, was to unplug the modem, wait for 60 seconds, and then plug it in again. This seemed to work, and my maintenance password to the Modem / Router has not been changed. I.e., I was not hacked. I was able to log into the Router again.

But power-cycling a router like that causes the network (LAN and WAN) to be unstable for several minutes. As a consequence, my site, and this blog, were not visible to the Internet from about 13h05 until 13h20.

I apologize for any inconvenience.


P.S. Also, I now have a new, dynamically-assigned IP address. But this could be routine, as my domain-name should resolve to the new address anyway.

(Edit 09/11/2016 : ) I gave the command at 13h16 the same day, to propagate my new IP address, and my own router, acting as my DNS server, reflected the new IP address, still within 13h16. It should not really have taken most readers until 13h20, before their browsers would have been able to fetch my URLs again.