I’ve just spent the last couple of hours trying to find a way to export the public key from a locally generated, self-signed X.509 certificate on a Juniper SRX-100 firewall. Apparently there is no Junos CLI command to do this, so after poking around the filesystem from a shell on the box, I found the location where Junos stores local certificates and key-pairs.

In the directory /cf/var/db/certs/common you should see at least the following two subdirectories:

drwx------  2 root  wheel  512 Jul 20 16:14 key-pair
drwx------  2 root  wheel  512 Jul 20 16:16 local

In the key-pair directory you should see files for each of your key-pairs, eg. self-cert.priv. In the local directory you will find the actual certificates, eg. self-cert.cert. Both the key-pairs and certificates are stored in binary DER format, which can be read by OpenSSL and converted to the more universal base64-encoded PEM format.

Private keys should really be left alone where they are on the Juniper, but you can safely copy the certificate to other locations, since it does not contain any private key material. Simply scp the certificate file to somewhere that has the OpenSSL tools installed, then use “openssl x509” to read the certificate:

daniel@thinkpad:~$ openssl x509 -in self-cert.cert -inform DER
-----BEGIN CERTIFICATE-----
MIIDSDCCAjCgAwIBAgIRAKybOo9tijNXkhgT9fe0ZFMwDQYJKoZIhvcNAQEFBQAw
TzELMAkGA1UEBhMCREUxJTAjBgNVBAoTHFNldmVudGggU2lnbmFsIEx0ZC4gJiBD
.....
co9vOYXqYv81xnIxg5I0brLqCzruKULy4zc6YHzJAGICMOw2wS9BwRkQUR1B2EZH
2QWUSn4Enj2JJkT3p044U8/q4BKdJ9V52mxQfA==
-----END CERTIFICATE-----

There you have it folks… a base64-encoded PEM-format public certificate.

My CCNP was due to expire in August, so I needed to pass any 642-* exam to renew it. I decided to sit the Cisco QoS exam (642-642), since it was one of two remaining exams I need to become CCIP. After a few weeks of study on and off, I’m pleased to say I passed the exam without much effort, thus renewing my CCNP for another three years. If I sit the BGP+MPLS exam next (642-691) I’ll also finally have CCIP, which should be a nice stepping stone along the way to CCIE.

Unfortunately my current job doesn’t really put my Cisco expertise to much use, which makes it a bit harder to keep the knowledge “fresh” in my head. That knowledge is also continually getting edged out by other things, such as OpenSolaris and all the daily, run of the mill sysadmin stuff I do.

I think my skills are becoming a little bit too rounded, and it’s time to really specialise in something.

I recently had to install a Cisco Wireless LAN Controller (2112, if you’re interested), and had the usual fun and games with getting it to properly understand DHCP Option 43. For the uninitiated, option 43 is a vendor specific option, which, in the case of Cisco WLCs, is/are the manager IP address(es) of controllers that LWAPP access points should attempt to join when they boot up.

Different model APs require this option to be in different formats. For example, Aironet 1000 units require the option response to be type 0×66, and a comma-separated ASCII list of controller IP addresses, whereas Aironet 1130, 1200, 1230 and 1240 units require the response to be type 0xF1, followed by the length (number of addresses x four), then the hexadecimal representation of the controller IP address(es).

Cisco documentation exists for this, however their documentation for ISC’s dhcpd is incorrect. Unlike most corporate customers I run into, who run Microsoft DHCP server (for better or worse), this particular customer was running ISC’s dhcpd.

The first step is setting the option 43 type. I’m going to concentrate on the 1130, 1200, 1230 and 1240 units here, since this is the area where Cisco’s documentation is incorrect. I’m going to follow Cisco’s documentation here.

option space LWAPP;
option LWAPP.controller code 43 = string;

Then we have a vendor class, for the 1200 series units:

class "Cisco AP c1200" {
match if option vendor−class−identifier = "Cisco AP c1200";
option vendor−class−identifier "Cisco AP c1200";
vendor−option−space LWAPP;
option LWAPP.controller f1:04:c0:a8:f7:05;
}

Note the “f1:04″ at the start of the string. This means type 0xF1, followed by four bytes of vendor specific data. The “c0:a8:f7:05″ is the hexadecimal representation of the IP address 192.168.247.5. This results in dhcpd transmitting “2b 08 2b 06 f1 04 c0 a8 f7 05″ for option 43.

Ok, let’s take a look at this string. The “2b” indicates this is a vendor encapsulated options field (type 43), and “08″ means it’s eight bytes long. The next “2b” is where things start to go wrong. This is because the Cisco documentation told us to define LWAPP.controller as type 43 also, which is incorrect. The “06″ indicates that six bytes follow for this sub-code, and then we have our “f1 04 c0 a8 f7 05″ string verbatim. This causes the WLC to report an error parsing the option 43, saying that it cannot parse “2b 06 f1 04 c0 a8 f7 05″.

What we should have configured in dhcpd.conf is actually:

option space LWAPP;
option LWAPP.controller code 241 = string;

class "Cisco AP c1200" {
match if option vendor−class−identifier = "Cisco AP c1200";
option vendor−class−identifier "Cisco AP c1200";
vendor−option−space LWAPP;
option LWAPP.controller c0:a8:f7:05;
}

Note that we also dropped the “f1:04″ from the hex string, since we are now correctly specifying LWAPP.controller as code 241 (0xF1), and dhcpd automatically populates the “04″ for us, after counting the length of our hex string (four bytes = one IP address). This results in dhcpd sending “2b 06 f1 04 c0 a8 f7 05″.

Again we have our “2b”, indicating vendor encapsulated options, but this time the field is only six bytes long. Then we have “f1 04″, indicating our LWAPP.controller code, with four bytes of data – our controller IP address. This time around, the AP will correctly see the option 43 “payload” of just “f1 04 c0 a8 f7 05″, and correctly parse the sub-option 0xF1.

Of course, what this field really is (and this is more clearly detailed in Cisco’s instructions for configuring Microsoft DHCP server), is an array of IP addresses. You can eliminate the need to specify the addresses in hexadecimal by defining the LWAPP.controller as:

option LWAPP.controller code 241 = array of ip-address;

and then simply listing your controller IP addresses:

option LWAPP.controller 192.168.247.5, 192.168.247.6;

This would result in dhcp server sending “2b 0a f1 08 c0 a8 f7 05 c0 a8 f7 06″. Note the “f1 04″ changed to “f1 08″, since the array length is now eight bytes (two IP addresses).

Why Cisco didn’t simply publish this, is beyond me. They’ve made it very confusing for users who don’t understand DHCP vendor specific information. I suspect the person who wrote the dhcpd section of the Cisco documentation didn’t fully understand how ISC dhcpd handles vendor specific options.

In any case, our configuration can be made somewhat clearer, and consistent with dhcpd’s documentation, as follows:

option space LWAPP;
option LWAPP.controller code 241 = array of ip-address;

class "LWAPP" {
match option vendor-class-identifier;
}

subclass "LWAPP" "Cisco AP c1200" {
vendor-option-space LWAPP;
option LWAPP.controller 192.168.247.5;
}

For each additional type of AP you have to support, just add another subclass, using the appropriate vendor class identifier string.

Have you ever needed to set up a bunch of equipment on a boardroom table or some other temporary location, and needed both native and 802.1q tagged VLANs, but only had one available switchport?

A quick n’ dirty solution is to use an unmanaged switch, such as one of the numerous 8-port desktop switches from manufacturers such as D-Link, Netgear, Linksys etc. Configure its upstream switchport as a trunk port, thus allowing your required VLANs to pass tagged frames to your unmanaged desktop switch.

Wait a second, you say…. unmanaged switches can’t do trunk ports. How can an unmanaged switch understand VLAN frames?

It doesn’t need to. What is an 802.1q tagged frame, other than a standard 802.3 ethernet frame with four additional bytes inserted? These four additional bytes are the 802.1q VLAN ID field and 802.1p CoS field. As long as the unmanaged switch does not truncate frames to the 802.3 standard 1518 bytes, it will happily forward the 1522-byte 802.1q tagged frames just like any other. The last time I encountered a switch that would not forward these slightly “oversized” frames, was about four years ago… and it was a very cheap and nasty brand (name withheld to protect the innocent guilty).

This trick also comes in handy when you have a user with a two-port VoIP phone (such as most Cisco, Snom, Polycom etc phones), using a voice-VLAN, and the user requires more switchports than are currently available at his/her desk. Simply connect the 8-port unmanaged switch before the IP phone (ie. to the upstream port), and connect the IP phone to the unmanaged switch. The phone still gets it’s tagged voice-VLAN frames, the PC gets its untagged data-VLAN frames (tag-stripped if necessary by the IP phone), and the user has 6 other ports available to connect whatever… including, if necessary, other VLANs (so long as they’re tagged, and the end device can work with tagged frames, since the unmanaged switch won’t strip the 802.1q tag).

Beware though, this should only ever be used as a temporary measure, since it does open a few security holes. If the “allowed VLANs” is not carefully configured on the upstream port, the opportunity exists to VLAN-hop, or flood traffic into other VLANs. And of course, since the unmanaged switch is, well, unmanaged, there is no individual “allowed VLANs” security on those 8 ports. All ports are effectively the same as that one upstream trunk port.

Have you used this method before? What brand/model unmanaged switch did you use? What were your experiences with it, and did you encounter any problems?

I’ve had a job offer since approximately the middle of August, with a German network consultancy firm. At first, the contract specified a start date of September 1st, but that was postponed because I didn’t yet have a work visa (or Arbeitserlaubnis, in German), until October 1st. With that date rapidly approaching, I still don’t have a work visa. In fighting the neverending red tape, I’ve wasted numerous hours of my life queueing, sitting in waiting rooms, or otherwise just growing old at the Ausländerbehörde.

It was so much simpler in Russia, even though I had to travel to Estonia (twice) to get a temporary tourist visa, and eventually a business visa. At least in Russia, there was always a good chance you could expedite the process by offering a nice bottle of vodka (or a big cake, in the case of women officials). No such chance in Germany, and I dread to think of the consequences if one tried this little stunt.

In a little over two weeks, if I still don’t have a work visa, I’ll be planning my exit from Germany – not by choice, but because my current residency visa expires on October 31, and can’t be extended. Super…

There are a couple of prerequisites before you can copy the config from a NetScreen or SSG via scp. First, obviously ssh and scp need to be enabled:

set ssh version v2
set ssh enable
set scp enable

And of course, you need to enable ssh management on the interface you’re going to connect to the device on:

set interface ethernet0 manage ssh

Once that has been done, from your PC, try the following:

scp netscreen@device-hostname:ns_sys_config ssg.cfg

And you should then have a file called ssg.cfg in that directory. Once again, simple when you know how.

It is also possible to load RSA/DSA keys against ScreenOS usernames, so that password-less login for ssh/scp can be utilised, allowing this method to form the basis of automated config backups.

Ok, now I’ve only tested this with routers running IOS – it may be a little different with Catalyst switches, since they store their config on flash, rather than nvram. On the other hand, it may be exactly the same, since we’re retrieving running-config, not startup-config.

First, you need to ensure that ssh and scp have been enabled. I strongly recommend that you run ssh version 2.

ip ssh version 2
ip scp server enable

Then, on your PC:

scp user@router-hostname:system:running-config .

You should then have a file called “running-config” in that directory. Pretty simple…

If you want to grab the startup-config instead of the running-config, try:

scp user@router-hostname:nvram:startup-config .

By using RSA keys to eliminate the password prompt at login, this method could be expanded to form the basis of an automated config backup. I know that various apps already exist, but a lot of them retrieve the config via “expect” scripts, basically executing a “show run” and capturing the output.

Another method of retrieving the config is via SNMP, however unless you’re using SNMP v3 with encryption, this method is potentially insecure.

I’m finally back in Berlin, after several unplanned delays. I’ll be here until at least April 2008, seeing how things pan out. I’m considering doing a TESOL or CELTA course, to open up the possibility of teaching English (either here, Russia, or Japan). Having had such a great time in Japan has made it difficult to decide where I next want to settle. I suppose time is still in my side… kinda.

On my way to Germany, I stayed five nights in Japan, doing a whirlwind tour of Tokyo, Nagoya, Kyoto and Osaka. Apart from the blood, sweat (and almost tears) of lugging 27 kg of gear through Tokyo train stations, Japan was a really cool place. The people are amazingly friendly and generous, and the whole place has a really good nightlife. You wouldn’t have to twist my arm very hard to convince me to return.

I recently had to upgrade a bunch of Cisco routers to an up to date IOS. These routers were scattered up and down the country, and I don’t have much to do with the servers sitting behind them, so I needed to do a remote upgrade over the Internet.

Now, TFTP is pretty hit and miss at upgrading remotely – and not particularly fast either. Given that TFTP runs over an reliable transport protocol (UDP), I tend to only use it on LANs, or for truly “trivial” things like backing up configs (and SCP is more secure for that). Since the routers were running an older IOS that didn’t support HTTP, I decided to have a crack at using FTP. What a drama…

Firstly, you need to realise that by default, the FTP client in IOS tries to use passive mode. The server I was hosting the new IOS images from was behind a firewall that was only configured for active FTP (ie, only port 20 and 21 open). So when the router tried a passive FTP download of the new image, the firewall denied the randomly-chosen port that the router had chosen to connect on.

Cisco “ip inspect” to the rescue. I added a stateful FTP inspection rule on the firewall (Cisco also) like so:

ip inspect fw-in ftp
!
interface Dialer0
ip inspect fw-in in
!

Now the firewall would do a stateful inspection of the FTP connection, and allow the subsequent randomly-chosen port passive FTP transfer.
That got a little further, but now the connection was stalling, even though vsftpd was showing a successful login and transfer begin. After searching for a bit, I came across some references to Cisco routers and FTP ABOR(t) commands causing problems with ProFTPD. I read through the vsftpd config on the FTP server and discovered an option for asynchronous aborts.

async_abor_enable=YES

I suspect the need for this arises from the fact that, when upgrading IOS, the router always checks to make sure it can actually read the file you specify, before it offers to wipe the flash. So, in this case, the router was starting an FTP transfer, then aborting it, then wiping the flash, then trying to start the transfer again. Once I had enabled that option, the transfer seemed to work. I say “seemed to work”, because I actually only got this to work on one router, and by this time it was about 2:30am. I was rapidly coming to the conclusion that the FTP client is a bit borked in older IOS releases.

So in the end I had to resort to upgrading a few routers via TFTP. Hopefully they are now running recent enough IOS that the FTP is a bit more reliable, or even better, supports HTTP (which is much more likely to succeed, since it carries control and data in a single connection).

It seems that the “ip inspect” feature of IOS is one of the most misunderstood commands of all, since I only ever see it being used in the outbound direction. Apart from using it to inspect outbound TCP sessions, and do away with the need for a rather insecure “permit tcp any any established” in an access-list, I don’t see a lot of point in inspecting outbound traffic. A few tricky protocols need a bit of assistance here and there, such as instant messaging and P2P protocols, to allow return traffic to establish an unrelated connection inbound. But the most use I see for it, is handling those tricky inbound connections such as when you’re hosting FTP, so that you don’t have to leave gaping holes in your inbound access-list.

I also found that http works a metric shitload faster if you don’t inspect it in the outbound direction. Even Cisco don’t recommend enabling it, unless you want to do Java blocking.

:-/