Networking

IP addresses – don’t use leading 0’s!

Bix

First thing you might wonder with the title of this article, is why the heck would you write leading 0’s in IP addresses? Well, fair enough. But read on about this little story of mine.

We have Excel sheets here listing all fixed IP addresses from our networks, to know which servers have them, and for which reason.

For a reason unbeknownst to me, we have put leading 0‘s in the addresses in those sheets. Well, thinking of it, maybe it was for cosmetic reasons or easier column sorting, but in that type of document we could have simply typed the IPs from a VLAN in a certain sequence once and for all.

Anyway, so we have this Excel file with these addresses, and server names/comments I don’t copy here:

A good-willing Operator had to configure a new server, so he went to the Excel file, chose a free address in the list, which was

, and copy-pasted it to the deploy wizard.

Some time later (when the server was actually brought online), we got a reported IP conflict on the network, and nobody understood why.

So check this out, let’s ping the address of the new server:

IPoctal_01
I said 25 damnit, not 21 !

Yeah well, the .21 address was indeed already used. It turns out that using one leading zero in front of any IP chunk, will convert this chunk in octal (base-8).  So the address 192.168.147.001 is read correctly in decimal, but .025 means 25 in octal, thus 2×8^1+5×8^0  i.e. 21 in decimal.

So even if in some software the correction might be done, never ever write your IP addresses with leading zero’s.

Now let’s have some fun. You probably now that “0x” is the prefix for the hexadecimal notation right?

IPoctal_02
Every chunk can have its own radix.

Now WHY on earth you can do that, remains a mystery to me.

Remote desktop error on Windows 2012

Bix

You want to connect with remote desktop to a fresh Windows 2012 server  (any edition) and you get the “Remote Desktop can’t connect to the remote computer for one of these reasons” generic message that isn’t giving anything except maybe a headache and the will to punch your screen:

Remote2012_00
For once, the Microsoft-style error message doesn’t totally lack of sense, especially about the last point: “is not available on the network”.

I don’t actually remember how it is with a Server 2008 out of the box, but I don’t remember having had those issues – then again, the guys at work making the templates for our virtual machines in 2008 had perhaps already fixed this…

Anyway, we’re talking here about Windows 2012 (“R1” or R2).

First things first, ensure the remote desktop is enabled.  Connect to your machine with the console (VMware/Hyper-V/whatever, or physically to the server if it is … a physical server)

Ensure the following is checked: Control Panel > System and Security > System > Advanced system settings > Remote > Allow remote connections to this computerRemote2012_01
This is greyed out here because we activate this through GPO.
Also, note that the checkbox below is NOT checked; this is to allow us to use software such as mRemoteNG (that I strongly advise). In a closed and secure environment, this is OK not to check.

So, Remote connections are allowed but you still get the error message, so there is a firewall issue as you may guess.

Of course you can totally turn the firewall off, but if you’re like me a bit, you don’t like opening all the doors of your home just because someone in your household hasn’t got the key to open one.

So let’s use cool powershell/prompt commands to solve this:

will output the three rules and their current Enabled status. You should see it to “False”

will open what needs to be opened.

will double check that everything is OK.

The global output should look like this:

Remote2012_02

Enjoy your remote connection!

Sources & additional info: