Networking Lesson .1
TL;DR
Do not assign IP address ending in .1, even on a private network.
I learned a valuable networking lesson when setting up multiple virtual boxes within a private network.
This article documents the process of using virtual boxes in private networking mode, methods to testing network connectivity, finding HTTP connection issue and the resolution.
Requirements
If you would like to replicate my work, install these items:
- Vagrant
- Virtualbox
- Clone Vagrantfiles from this github repository
Set up
I want to set up four virtual machines using vagrant on a private network. I set up four Vagrantfiles in their own folders as so:
The Vagrantfile contents:
With four hosts on a private network, I would like each host to correspond to a logical IP address, such that: host1 is 192.168.100.1, host2 is 192.168.100.2, etc.
To configure this, the main difference between each hosts’ Vagrantfile is:
host | IP Address | configuration |
---|---|---|
host1 | 192.168.100.1 | HOST_IP="192.168.100.1" |
host2 | 192.168.100.2 | HOST_IP="192.168.100.2" |
host3 | 192.168.100.3 | HOST_IP="192.168.100.3" |
host4 | 192.168.100.4 | HOST_IP="192.168.100.4" |
This looks straight-forward, let’s bring each up by running command:
Ping Test
To confirm each host can reach the other, let’s have them ping ech other with the following commands:
The outputs of each command have the general shape:
Each host can reach the other using ping. Great!
HTTP Test
With ping confirming each host can reach the other, I expect each host is connectable to the other over HTTP.
Let’s run a quick test since each host has nginx and the server is running.
A successful output of the curl command in this situation would be curl retrieving the default nginx page::
HTTP Test Results
host1:
command | output |
---|---|
$ cd host1 && vagrant ssh -c ‘curl 192.168.100.2’ | successful nginx output |
$ cd host1 && vagrant ssh -c ‘curl 192.168.100.3’ | successful nginx output |
$ cd host1 && vagrant ssh -c ‘curl 192.168.100.4’ | successful nginx output |
command | output |
---|---|
$ cd host2 && vagrant ssh -c ‘curl 192.168.100.1’ | successful nginx output |
$ cd host2 && vagrant ssh -c ‘curl 192.168.100.3’ | successful nginx output |
$ cd host2 && vagrant ssh -c ‘curl 192.168.100.4’ | successful nginx output |
command | output |
---|---|
$ cd host3 && vagrant ssh -c ‘curl 192.168.100.1’ | successful nginx output |
$ cd host3 && vagrant ssh -c ‘curl 192.168.100.2’ | successful nginx output |
$ cd host3 && vagrant ssh -c ‘curl 192.168.100.4’ | successful nginx output |
command | output |
---|---|
$ cd host4 && vagrant ssh -c ‘curl 192.168.100.1’ | connection error |
$ cd host4 && vagrant ssh -c ‘curl 192.168.100.2’ | successful nginx output |
$ cd host4 && vagrant ssh -c ‘curl 192.168.100.3’ | successful nginx output |
In the siutations where there is a connection error
, the output is:
Ping Test Again
This HTTP connection failure makes me wonder and I directly confirm using ping again:
Pinging from host4 => host1:
Hmm… this is strange, why can host1, host2, and host3 connect to each other over HTTP because the curl request succeeded but host4 and host1 cannot? All the other hosts can connect to each other, except these two?
Curl Details
When I run curl -v
, to get more verbose output, this is the response:
This does not add up… hosts1 refuses the HTTP connection from host3, but the ping connection works??
Other Possible Solutions??
I tried solutions such as flushing the firewall entries (which would deny connections from other computers). That did not work, this makes sense since I did not do anything to trigger an entry to the firewall.
I destroyed everything and rebuilt each virtual machine, when I saw this message during the build for host1:
Oh, now I get it… any network address ending in .1 is a router address.
In my quest of have matching hostname numbers with the actual address, I inadvertently assigned a host’s address to the router address.
The really funky part about debugging this was that ping between all hosts worked, but curl worked between host1 and host2, which made the issue weirder.
Conclusion
The ultimate goal of the lesson: do not set the address of anything to .1. It’s just not worth the debugging headache. :-)