Mac OS X L2TP VPN to Cisco IOS

Just spent a couple of hours trying to get a Mac OS X laptop connected to a Cisco IOS IPSEC/L2TP server. The existing configuration worked fine for windows and linux servers but the Mac just refused to establish a connection. The Cisco logs contained the usual cryptic message.

Dec 16 16:53:47.955: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local=, remote=,.
    local_proxy= (type=1),.
    remote_proxy= (type=1),
    protocol= ESP, transform= esp-3des esp-sha-hmac  (Transport-UDP),.
    lifedur= 0s and 0kb,.
    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x800
Dec 16 16:53:47.955: Crypto mapdb : proxy_match
    src addr     :
    dst addr     :
    protocol     : 17
    src port     : 1701
    dst port     : 49561
Dec 16 16:53:47.955: map_db_find_best did not find matching map
Dec 16 16:53:47.955: IPSEC(validate_transform_proposal): no IPSEC cryptomap exists for local address A.B.C.D

After much googling I discovered that the problem was dst port: 49561 . Unlike most other L2TP clients the Mac uses a random source port for the L2TP part of the connection. Most others use 1701 for source and destination.

So relaxing this

ip access-list extended L2TP
 permit udp host eq 1701 any eq 1701

to this

ip access-list extended L2TP
 permit udp host eq 1701 any

solved the problem.

It would now normally be the time for me to rant about how IPSEC has to be one of the most badly implemented protocols by all vendors and how getting two different implementations to talk to each other always takes a minimum of 2 hours even if you’ve done it before but it would just be too exhausting.

Melbourne Cup Dip2

To quote Justaan:

This is what we call the Melbourne Cup Network Effect

Melbourne Cup network effect

It seems it really is the race that stops the nation. This is a graph of Bulletproof’s outbound web traffic for today. That’s a 37% drop in outbound traffic just after 3pm.

Make sure you take note of my l33t gimp skills!

Disabling “Subscribe to feed” in firefox

At Vquence we do a lot of crawling of various video hosting sites and where possible we like to use APIs or RSS feeds instead of page scraping. A semi-recent features of firefox is that when you click on an RSS link you get a “Subscribe to this feed in your favourite reader” header and then the formatted contents of the feed.

This is really annoying if what you really want to see is the raw XML. Sure I could hit CTRL-U to see the source but thats an extra step and a whole other window I now have open. I couldn’t find any way to disable this functionality so I ended up writing a greasemonkey script called disable_subscribe_feed.js.

The meat of the script looks like

// Pick three element ids that appear in the "Subscribe to page" and probably 
var tag1 = document.getElementById('feedHeaderContainer');
var tag2 = document.getElementById('feedSubscriptionInfo2');
var tag3 = document.getElementById('feedSubscribeLine');

// Show the source
if (tag1 && tag2 && tag3) {
    location.href = 'view-source:' + document.location.href;

Basically it tries to detect the “subscribe to feed” page based on a couple of tag ids that exist on it and then performs a redirect to view-source: for that page. Which gives us nicely formatted XML.

Firefox popup blocking

Wouldn’t it make more sense for firefox to allow popups based on the destination site rather than on the source?

For example most popups I click on are for YouTube. Now some on these are on random blogging sites. Which means that to jump to the YouTube page for that video I have to allow popups for some random blog, which can now popup as many ads as it wants.

Wouldn’t it make more sense to allow YouTube as a popup destination. It really comes down to the fact that I trust YouTube more than some random blog embedding YouTube videos.

I haven’t thought about this very much so maybe there is a good reason why you wouldn’t want this. If a few other people agree with me I’ll go file a bug. Hmm I wonder if you could write an extension to do it.

Update: Peter raises a good point as to why this is a bad idea.

Google Analytics new tracking code

As I was setting up a new site in Google Analytics today I discovered that there is now new tracking code you are supposed to use. The old code is now unsupported. Your javascript snippet should now look something like.

    var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
    document.write(unescape("%3Cscript src='" + gaJsHost + "' type='text/javascript'%3E%3C/script%3E"));

    var pageTracker = _gat._getTracker("PUT_YOUR_TRACKING_ID_HERE");

This has been a community service announcement. đŸ™‚