I’m now busy with my so called Masterclass and for that I’m attending a lot of courses. A couple of weeks ago I attended a five-day VMware vSphere course and in a while I will take an exam and try to get my VCP4 certification.

At home I’ve created a labsetup so I can fiddle around with ESXi, vCenter server, etc. without breaking any setups. Today I was trying to get a connection to my vCenter server from work but that involves opening a couple of ports in your firewall or, in my case, tunneling a few towards my home. At first it was unclear to me which ports should and shouldn’t be opened. I found this page which provides this pdf. This is a great diagram mentioning all ports for all connections typically used in your vSphere environment.

I found this to be very usefull and therefore like to share it with you as well.

Last weekend I decided to give observium a try. Observium is a network monitoring system and fully snmp-based. There are also alternatives like Zabbix and/or Nagios but Observium differs that it’s very very easy to set-up.

I’ve spent like half-an hour installing observium on a clean debian server and after those 30 minutes it was already graphing 3 devices in my network. I’ve spent a couple of hours after that toying around, discovering what’s possible and what not.

Something observium does is when it discovers a problem, for example a device that got disconnected, it sends an e-mail to the snmp-syscontact (or if overridden another email address).

I usually also have an irc window open when I’m sitting behind my computer like many of you I suppose. And I almost immediately had the wish that the irc-bot (jsonbot) that I have running would be connected somehow to observium and inform me of those messages. A couple of friends also use observium (one of them has been pushing me around a lot when o when I would start using observium ) and they also liked the idea.

So today I got up around 8:30 in the morning brewed a fresh pot of coffee and opened my editor. Now some hours and I don’t know how many cups of coffee later I’d like to present to you my observium-jsonbot-plugin!

What it does is check an imap e-mail box for new messages and inform you about it. The features it provides are:

• Present a list of unread e-mails
• Display the contents of a given message
• Automatically check for new messages (by default every 60 secs. when enabled)

Here’s how it works! First of all you need to configure your bot with the options for the observium imapbox. The following options can be set:

These options can be set using:

When you’ve configured the plugin these are the commands available to you:

If you’ve enabled the watcher for a certain channel the bot will check the mailbox every 60 seconds (unless you’ve changed the interval) and if new messages have been found it will post a list of subjects in the channel.

Of course you’ve been waiting for the downloadlink: well here it is: Download

You should put this file in <yourbotdirectory>/jsb/plugs/socket/
Then restart your bot and enable the plugin using:

I hope you have fun with it and if you’ve got any comments and/or find bugs, please let me know

Kind regards,

Lammert

As I’ve mentioned before I’ve wanted to create a VPN setup between my home and my VPS’es. Not because it’s necessary but just because it’s possible and I learn something from it.

A couple of weeks ago I finally started this project, reading documentation and try to get it working. I started off creating a suitable test-setup here at my house. I booted one of my Cisco 2651XM’s with a IOS 12.4 image and gave it a clean configuration. 1 ethernet port connected to my home-network so I had a way in and the other connected to a dedicated server which I provided with a fresh Debian install just for this exercise.

With this test-setup I had clean configs, no software or other things that might interrupt this exercise and if I somehow created a big mess it wouldn’t interfere with my production setup.

So with all things ready it’s time to start configuring everything. Before I start pasting and explaining my configs let me remind you of one thing. Everything i did is a way of doing it. It’s not the right way, it’s not the wrong way, it’s just the way I did it and there are numerous other ways of accomplishing the same result.

There are a couple of ways setting up an IPSec tunnel. You can use pre-shared-keys or PSK in short. Or you can use certificates. I used pre-shared-keys so I won’t go into using certificates as I’m sure there are plenty of websites covering that subject.

The other thing that’s useful to know, which is also a great help when you’re debugging IPSec, is that when setting up a IPSec tunnel it performs several steps creating the tunnel. Before your tunnel is up and running it performs a couple of checks and negotiations and when both sides agree your tunnel will come up. These steps for creating the tunnel are IKE phase 1 and IKE phase 2. IKE is short for Internet Key Exchange.

During phase 1 it will compare the policies on both sides checking if they agree on encryption, hash-algorithm, etc. and it will check if the PSK matches on both sides. If both sides have identical policies and PSK’s then they will proceed into the next step, IKE phase 2. If for some reason things don’t match up on both ends it will end in phase 1 and you’re probably need to debug to see what’s going wrong.

Next up is IKE phase 2. When phase 1 is successfully completed, phase 2 is started. Phase 2 negotiates the IPSec security associations and generates the required key material for IPSec. You can specify one or more transform-sets but they have to match on both sides for IPSec to work. If phase 2 is also completed without errors your tunnel will be operational and you can securely transfer data from and to both hosts in this setup.

Next I will show the necessary configuration for the cisco router as well as the configuration for the linux machine. I will try to explain these configurations as much as possible so you can understand which part is for which IKE phase and why it’s necessary.

The Cisco Side

I’ll start off with the Configuration for the cisco router, I assume you know how to configure a cisco router yourself because I will not be including those parts of the configuration. Only the necessary parts are shown.
Also i’ve used 3DES encryption for the sake of example, 3DES is not the most secure encryption around, you should use SHA256 of SHA512 instead:

I’ll walk through this configuration step by step explaining every part.

First up is our isakmp policy which you’ll find on lines 1 through 5. These lines specify your policy used in the IKE phase 1 part which I’ve mentioned above. Since it’s logical to assume you might want to create more IPSec tunnels than just 1 you can create more policies than 1. Because not all remote ends might use the same policy. I’ve created this isakmp policy with priority 1 which is the highest priority. The bigger the number, the lower the priority.

Within this policy we specify a couple of things. First of all on line 2 we say we want to use 3des encryption in our communications with the remote host. On line 3 we specify we want to authenticate using a pre-shared-key. On line 4 we say we want to use diffie-hellman group 2 which is a way of exchanging the PSK securely over an insecure medium and group 2 says it will be using 1024-bit encryption. On line 5 we specify a lifetime of 1 hour.

Line 6 specifies the pre-shared-key for the specified remote host in this case 10.20.30.42 be sure to replace YOURKEY with your own and more secure pre-shared-key. A way of generating a secure key is executing the following command on a *nix machine which will create a 32 character hex-string:

dd if=/dev/random bs=1 count=32 2>/dev/null | xxd -ps

Line 9 and 10 are specifying IKE phase 2. Line 9 creates an IPSec transform-set called hostb-transform (this can be any string you like) and i chose to use esp-3des and esp-sha-hmac for this transform-set. Line 10 is an important one, you can setup an IPSec tunnel in 2 modes: tunnel-mode or transport-mode. In transport mode only the payload is encrypted, in tunnel-mode the ip-header will also be encrypted. At first I didn’t specify any here. It took me a day figuring out why my IPSec tunnel wouldn’t work.

Next up are lines 12 – 16 defining the crypto map. A crypto map is needed for several reasons. Amongst others it’s used to specify which traffic should be protected by IPSec, which transform sets are to be used with the protected traffic and defining the peers. One could say the crypto map is the glue between different aspects of setting up an IPSec link.

First on line 12 we define the crypto map itself with in my case the name “hostb-cryptomap” a sequence number of 1 and we specify it should be an IPSec with ISAKMP crypto. You could also use IPSec with manual keying but that’s outside the scope of this post.

On line 13 we define our peer, which in my case is the Debian box with ip 10.20.30.42.

On line 14 we tell the crypto map to use the transform set we created on lines 9 and 10.

Line 15 could probably be left out but it never hurts to specify it once more. It tells it still wants to use a 1024 bit Diffie-Hellman encryption only this time it applies to phase 2 instead of phase 1. You could use Diffie-Hellman group 2 in phase 1 and group 5 in phase 2 if you deem it’s necessary. For now we keep things simple and use group 2 in both phases.

Line 16 is the last line in our crypto map definition and specifies the access list it should use to determine which traffic should be encrypted using IPSec. I’ll explain the ACL in a couple of moments.

The next block in the configuration is binding the crypto map to a network interface. In my case this is FastEthernet0/1. Everything is straight forward in this setup the only thing you should add to your network interface is what I’ve specified on line 22. Line 22 binds the crypto map we’ve just created to this interface and when traffic from and to our defined peer passes through it knows it should be encrypted. If you forget this part your IPSec tunnel won’t establish.

And the last step on the Cisco side of this setup is the ACL which is specified on lines 24 and 25. On line 24 you create an extended access-list with the name “hostb-list” which we’ve said we want to use in the crypto map. And on line 25 we define we want to allow traffic from the Cisco (10.20.30.40) towards the Debian box (10.20.30.42) and because this ACL is connected to the crypto map the traffic is encrypted using IPSec.

This concludes the Cisco side of this setup and now we’re going to setup ipsec-tools and racoon on the Debian box so the 2 machines can connect and setup IPSec.

The Linux Side

I also assume you know your way around a linux machine and how to install and configure one. For IPSec to work you need to install racoon and ipsec-tools and of course you need network connectivity. But that speaks for itself doesn’t it?

Note: I’ve used Debian as Linux OS of choice and the paths to config files I name might be different on your OS.

There are 3 files we are going to edit on this machine to setup our IPSec tunnel.

/etc/ipsec-tools.conf

I’ve stripped te file from comments so it’s a bit smaller to paste here and explain what it does. This file gets parsed by the program setkey which is in charge of the Security Associations and Security Policies.

The first line in this config is to specify which interpreter is used to parse the file and as I’ve said setkey is being used for this.

Lines 3 and 4 respectively flush the Security Association Database and the Security Policy Database (SAD and SPD in short). This is to make sure when you change things in this file and setkey parses this file again the possible existing SA’s and SP’s will be flushed.

The next lines 6,7 and 9,10 roughly do the same thing as the crypto map and the ACL on the Cisco side are doing. On line 6 you’re adding an entry into the SPD telling that any traffic originating from 10.20.30.42 (the debian box) towards 10.20.30.40 (the cisco) should be encrypted by IPSec. Line 7 requires it should be using the ESP protocol, that it’s an IPSec link which operates in transport mode (in tunnel-mode you should specify tunnel instead of transport). The space between the next 2 slashes is omitted because it’s not necessary in transport mode. In tunnel mode you should specify the source and destination as x.x.x.x-y.y.y.y. And with require you require the IPSec tunnel to be up before traffic is allowed towards the destination host.

Lines 9 and 10 do the same thing as lines 6 and 7 only this time for traffic originating from 10.20.30.40 (the cisco) towards 10.20.30.42 (the debian box).

/etc/racoon/racoon.conf

Now that we’ve created our security policies specifying what traffic should be encrypted, it’s time to create the config for racoon, the daemon which actually provides the IPSec link.

Above you see the contents from racoon.conf which has also been stripped of it’s comments. The first 2 lines are basic setup for racoon. As with cisco, when using PSK authentication, the PSK needs to be stored somewhere. On line 1 one can specify in which file the PSK’s are stored. In this case: /etc/racoon/psk.txt we’ll get to this file later on.

If you would be using certificate based authentication, which we aren’t in this example, you need to specify the path were certificates are being stored. This is what line 2 does.

Next up is the IKE phase 1 configuration like we did on the cisco. Starting on line 4 where we specify the ip-address of the remote host which in this case is 10.20.30.40 (the cisco).

Line 5 sets the exchange_mode which is used when starting the buildup of an IPSec tunnel. Usually main or aggressive is used. When using main mode like in this example there are 3 two-way exchanges between the initiator and receiver to establish, verify and secure communications. With aggressive mode there are fewer exchanges and almost all information is squeezed into one packet. Aggressive mode is a bit faster setting up the tunnel it is also less secure than main mode. Because when using aggressive mode both sides have exchanged information before there’s a secure channel and therefore it’s possible to sniff the line and discover who formed the new Security Association. In this example we’ll be using main mode as the exchange mode.

If you’re interested in the specifics of these exchange modes you can search for “ipsec exchange mode” on the internet. It is outside the scope of this post to go deeper into this subject.

Next, on line 6, we specify the lifetime of the IKE SA. An SA should not last indefinitely, in this example we give the IKE SA a lifetime of 1 hour which starts running the moment the SA is established. One minute before expiring the system renegotiates the SA and new key material is exchanged. Because the system does this before the SA has expired the user won’t notice a thing and is able to continue his work and communications with the remote side without interruptions.

Lines 7 through 12 specify the phase 1 policy like we did with the “crypto isakmp policy 1″ on the cisco. Everything defined in these lines is the same on the cisco because the has to be a matching policy.

Lines 15 through 22 define the phase 2 part of the IPSec setup. First we keep maintaining a Perfect Forward Secrecy Group 2 (remember the Diffie-Hellman comments earlier in this story?) on line 17. Next we also set a lifetime for the phase 2 SA on line 18 like we did a couple of moments ago for phase 1.

Line 19 and 20 will look a bit similar to the transform set we’ve created on the cisco. This is also what these lines represent. Needless to say they need to be the same on both sides. You’ll probably noticed that on the cisco we specified esp-3des and esp-sha-hmac and now in racoon we only specify 3des and sha-hmac. Well you’ve noticed correctly but if you look at ipsec-tools.conf we specified that communications require esp and when you match those up you’ve got esp-3des and esp-sha-hmac.

Last thing in this file is the compression_algorithm on line 21. Racoon requires this line to be present even if you’re not using compression. As far as I know “deflate” is also the only option possible at this moment, so just put it in there and forget about it.

/etc/racoon/psk.txt

the last step we haven’t completed, but mentioned before, is the PSK. So fire up your favorite text-editor one more time (my favorite is vim ) and edit this file.

Since we have only one IPSec tunnel setup this file needs one line containing the ip of the remote host and the PSK so for this example it should contain:

Finished!

If you’ve followed my instructions correctly you should be finished now. Try pinging the cisco (10.20.30.40) from the Debian box for example. It should start responding within a couple of seconds because it needs to setup the tunnel first. Also the ping times are a little higher than a direct link without IPSec because traffic has to be encrypted. In my case (I’ve used a crosscable between the cisco and debian box) my pingtimes were 2ms slower than without IPSec.

You should check if your IPSec link really got up by tailing /var/log/daemon.log on your debian box and check if you see messages from racoon passing by. This is also a very useful file if things don’t work, it tells you what might be wrong and on which IKE phase things are failing.

The same can be accomplished on the cisco by using one or more of these commands:

And last but not least to check if your traffic really gets encrypted fire up a tshark session on debian box monitoring the network interface you used to setup the IPSec link.

Of course you need to install tshark and replace eth0 by the network interface you used. If you’ll open up a ping to the remote host you should see ESP packets passing by.

I hope this was a useful howto and gave you a little more understanding in the world of IPSec. I know it worked for me, first figuring out and setting up the IPSec link but also whilst writing this post i got a greater understanding in how things work and why certain things are needed.

Please leave a comment if this has helped you or if you found mistakes or just because the fun of it

Kind regards and see you in part 2,

Lammert

I thought to be nice to perform an update on my personal site, which you’re reading right now, obviously

What is updated you might ask… well: i’ve updated my “About Me” page with my newly created linkedIn profile. I’ve added the “follow me” button on the left of this site with links to my twitter and my linkedIn profiles. And i added this post

So what’s been happening lately in my life… about 2 months ago i “finally” graduated i am now “Bachelor of Engineering”. In less than a week i’ve got a full-time job at my employer. I must say it’s a lot of weight of off my shoulders, no fuss about graduating anymore. Just working full-time and having fun in my weekends, i’m loving it.

At home i have a lot of things which keep me busy, i’m having trouble deciding what to do first A couple of weeks ago i started a new project called [R4CK]. You can read all about it on the website. But don’t expect it to be finished anytime soon because at this point my network is consuming a lot of my time.

Last week i ordered and received a Cisco 7940 IP Phone. A great toy to play with, i hooked it up with my Asterisk setup and i’m able to place and receive calls with it. But there’s so much more, for example the address-book which the phone is able to access. I figured i want to do this with LDAP but i want to have the LDAP server running at one of my vps’es and not at home where my phone is.

So i’ve decided i also need a site-to-site vpn tunnel towards my vps’es (this has been a wish of me for a longer time) but i would like to create my vpn tunnels over IPv6. And since a short time my provider (xs4all) supports native IPv6 to my home (the first provider to do this in the world i’ve been told). But to use this i needed IOS 12.4 on my router, before i could run this new version i needed to upgrade the memory.

Last week i received and installed this memory and i now have native IPv6 at home \o/ but this week i discovered it wasn’t enough for IPv6 vpn tunnels, i need a 12.4T image for that and if i want to run that i need more flash memory, more ram and another bootrom in my router so i’ve accepted this won’t be happening. So now i’m at the point i’m about to configure vpn tunnels and BGP over IPv4.

Once that’s complete i can focus on LDAP and then back to configuring my phone (which it all started with). On top of that, the server of a friend of mine crashed last week so i’ve also been busy configuring his new VPS.

So you can imagine don’t know what to do first and last. Luckily i have some days off next week maybe i can finish some of the tasks mentioned above And maybe i have some time to read in my new book which i ordered last week (link) it should arrive this week.

Until the next post.

Once in a while i use this system to put some files onto it and then i turn it off again. To be able to also do this remote i’ve bought myself an APC PDU (model AP9212) a couple of months ago. Since that time i always had an idea to automate a backup job which would perform the following steps for me:

1. Turn on my storage system
2. Mount the backup share
3. Transfer the backup onto the share
4. Unmount the backup share
5. Send a shutdown command to my storage system
6. Turn of my storage system

The day before yesterday i finally put my hands on this idea and started looking how i could get and set data to and from my PDU using SNMP. A while ago i already figured out the specific OID’s needed for this job.

So i started searching and reading and found that the net-snmp package comes with python bindings. The small example for an snmpget looked simple enough so i started programming. Within the hour i had written a small script that reads the names and statuses of all 8 ports. (see example code at the bottom of this post)

Unfortunately my hopes were up and this was all the easy part and i was stupid enough to think that an snmpset wouldn’t be much harder, ok in the end maybe it wasn’t but getting there…..

Documentation for the net-snmp python bindings isn’t widely available i discovered you pretty much have to rely on the README provided with the net-snmp package. Searching for code examples is a quest without suitable results (it returns a lot of snmpget examples which i didn’t need).

And while trying different ways to get my code working and actually controlling a port on my PDU did take me several hours. I ran into all sorts of errors for example when i used the following piece of code trying to get it to work:

i got this error:

ok so diving into the README once again i changed the first line to:

now my code actually ran but nothing happened on my PDU… i thought. I started inspecting my network traffic because i was curious what actually was being sent to my PDU.  I made a pcap file with tcpdump and inspected it with wireshark and that showed me the response from the PDU:

Ok, so it was clear that somehow snmp couldn’t find this OID and wasn’t able to write a value to it. But how is that possible? i’m certain that my OID is right. So a lot of trying, searching, cursing and more cursing later i started digging in the net-snmp package.

In this package i found a unittest for the python snmp bindings so i’ve decided to enable the snmp daemon on my server and run this unittest and to my big suprise this worked including the snmpset method. And when i dug through the unittest code i found nothing really different from my code.

After careful reading the code over and over again i suddenly realised that they put a value in sysDescription.0 but their varbind looked like this:

and i realised that they split up sysDescription.0 in the varbind call so what if i do the same thing? so i started an snmpwalk to look at the values again and i made my varbind look like this:

and when i ran my code again i saw that port 5 which i was testing on suddenly turned on i started cheering because this was the thing i was looking for, my code was working. (i added INTEGER into the call because without it it was still producing an error).

I hope that with this post i save some of you the same trouble i had to undergo. I can now continue writing my backupscript, i can now perform the first and last task now the ones that lie in between

The SNMP Get example (reading the names and statuses of port 1 through

The SNMP set example (setting port 5 to status On)

Use code at your own risk, i only posted it to provide an example of how it can be done. Also the ip address of my PDU and community string have been changed, change to your needs if you want to try it. If you have any questions, comments or compliments please leave a comment below.

I’ve just installed my new blog, soon i will add some posts with things that i come across and/or keep me busy during my daily life