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>

<IfModule mod_gnutls.c>
        Listen 443
</IfModule>

# 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.
        #ServerName www.example.com

        ServerAdmin admin@dirkmittler.homeip.net


 

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
dirk@Phoenix:~$


 

What I expect to see, is instead:

 


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


 

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:

 



http://127.0.1.1/blog/


 

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 ‘0.0.0.0:80‘.

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.

Dirk

(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 have a little glitch in my OpenVPN configuration.

One of the subjects which I have written about before, is that I host a VPN, which uses the OpenVPN protocol, and that I have used my own, hand-written configuration files for it.

There are certain ways in which this VPN is atypical, in its configuration. For example, what most system administrators will do, is assign a range of IP addresses on their virtual LAN, which do not overlap anywhere with the IP address range on their physical LAN. OTOH, what I have done is to use the configuration lines:

 


ifconfig 192.168.2.129 255.255.255.128
ifconfig-pool 192.168.2.130 192.168.2.254 255.255.255.0
push "route-gateway 192.168.2.129 255.255.255.0"

 

In my thoughts, I was assigning the IP address range from 192.168.2.129 through 192.168.2.254 to the VPN. But whenever my OpenVPN server starts or restarts it does so with a warning, that this IP address range overlaps with the existing IP addresses of my physical LAN, which go from 192.168.2.0 through 192.168.2.255 .

This is how I made a little mistake: My configuration unwittingly also included IP address 192.168.2.255 in the range, which will be routed as belonging to the VPN. And this is due to the first line above, which simply has 255.255.255.128 as its subnet mask.

This can cause the following problem. As part of my physical LAN, address 192.168.2.255 sometimes serves a purpose. It is the UDP Broadcast address of my router, and can be used by clients to find all the connected LAN clients.

Probably because I have done this, the command ‘nmblookup‘ will not work on my machine ‘Phoenix’, which is also my server (as I discovered for the first time last evening). But beyond that, this could be why setting this server to act as a WINS server creates a failure in the configuration of my LAN. This may not really be due to any intolerance on the part of my Windows 7 machine ‘Mithral’, of a Linux box acting as a WINS server.

Also, the command ‘nmblookup‘ works fine on both the other Linux machines on my LAN: On ‘Klystron’ and on ‘Walnut’.

If I was determined to make my configuration better, I could try tweaking this OpenVPN configuration, let us say with a subnet mask of 255.255.255.192 instead of with 255.255.255.128 . Of course, I would then also have to reduce the number of possible, available connections to my VPN accordingly, let us say so:

 


ifconfig 192.168.2.129 255.255.255.192
ifconfig-pool 192.168.2.130 192.168.2.191 255.255.255.0
push "route-gateway 192.168.2.129 255.255.255.0"

 

In other words, I can create a 6-bit subnet, the addresses of which are prepended by the bits ’10’. However, it was incorrect of me to have a 7-bit subnet, which was simply prepended by the high bit ‘1’, because unfortunately, doing so also masks the UDP Broadcast Address of the router.

For the moment, not being able to use the ‘nmblookup‘ command on ‘Phoenix’ has not had significant consequences for me, and one main reason might be the fact that in general, Linux avoids using NetBIOS. Also, the graphical browser I use, does not seem to depend 100% on this command, or on the local machine being the WINS server, in order to work.

So this error has little urgency for me, and also did not impede my use of the computers.

Dirk

(Edit : ) Minutes after writing this posting, I have applied the change in configuration as described. With great joy, I find that my ‘nmblookup‘ command works fine now.

Now, this error should not strike people as serious, because it was only according to the LAN, as seen by one client (‘Phoenix’) that this address belonged, incorrectly, to the VPN. However, sometimes routers have been programmed in their firmware to offer as an extended feature, to reflect whatever IP address assignments are reported by one client. If mine is such a router, then of course, this one IP address would have been spotted as a conflict, and overridden by the router, so that the other machines on my LAN, continued to see the correct mapping.

Continue reading I have a little glitch in my OpenVPN configuration.

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.

Dirk

 

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.

Dirk

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.