Uptime – simple http monitoring utility

I found an very interesting http monitoring tool called Uptime using node.js and mongoDB. I directly installed Uptime on one of my Linux servers and from the first look I find it really cool 🙂 before you start you need to get node.js and mongoDB installed on your server and the rest is then very easy.

Ones the Uptime is running you can access the web interface and create the first checks, here some screenshots:

Here you create your http checks and define some settings:

Detailed check overview with graphs:

If you are interested then have a look here: http://fzaninotto.github.com/uptime/

Cisco SSL VPN Configuration

At the moment I play around with Cisco SSL VPN (WebVPN) and here some steps how to configured these on an Cisco ASA. SSL VPN is on one hand the Cisco Anyconnect client and on the other an Clientless SSL VPN over a portal what is running on the ASA.

I will not go into much detail here, it’s more basic configurations steps you need to configure to get it running.

For a basic set-up we need two network objects

object network inside-subnet  

object network sslvpn-subnet  

Then we define the DHCP pool for Anyconnect connections

ip local pool SSLVPNClientPool mask

We also need to make sure that Anyconnect clients communication with their original IP address and for that we need the following nat statement

nat (inside,outside) source static inside-subnet inside-subnet destination static sslvpn-subnet sslvpn-subnet

Here you select the Anyconnect package what you need to upload to your flash before and enable webvpn on your outside interface

  anyconnect image disk0:/anyconnect-win-2.4.1012-k9.pkg 1  
  enable outside  
  anyconnect enable  

In the SSL VPN client policy we define name server, domain name and DHCP pool. We also define here Anyconnect with ssl-client and the portal with ssl-clientless

group-policy SSLVPNClientPolicy internal 
group-policy SSLVPNClientPolicy attributes  
  dns-server value  
  default-domain value domain.com  
  address-pools value SSLVPNClientPool  
  vpn-tunnel-protocol ssl-client ssl-clientless  

We configure an SSL VPN tunnel group for remote access and set default policy to the SSL VPN client policy we configured in the step before

tunnel-group SSLVPNClientProfile type remote-access 
tunnel-group SSLVPNClientProfile general-attributes  
  default-group-policy SSLVPNClientPolicy  

Next, we define an external aaa server in my example an Windows Active Directory

aaa-server ldap-group protocol ldap
  aaa-server ldap-group (inside) host   
  ldap-base-dn OU=Departments, OU=DE, OU=Company, DC=domain,DC=com   
  ldap-login-dn cn=LDAPReader, OU=ServiceAccounts, OU=Company, DC=domain, DC=com   
  ldap-login-password secretpassword   
  ldap-naming-attribute sAMAccountName   
  ldap-scope subtree   
  server-type microsoft   

After we configured the external aaa server we need to link that in the tunnel group

tunnel-group SSLVPNClientProfile webvpn-attributes  
  group-alias SSLVPNClient enable  
  authentication-server-group ldap-group  

One of the last steps we enable the tunnel group within webvpn and configure sysopt permit-vpn

  tunnel-group-list enable  
sysopt connection permit-vpn

With the following command you can enable NTLM for a whole subnet if you use Windows IIS and integrate authentication

auto-signon allow ip auth-type ntlm

That’s it, quite easy and clear setup over the command line, you can also click yourself through the ASDM but it will definitively take longer.

Strange VPN behaviour between Juniper ISG and ASA

Always something new what is not working, this time a site-to-site VPN tunnel between a Juniper ISG 2000 and a Cisco ASA 5520. After the initial set-up what a colleague did everything seemed to work fine with the VPN, the tunnel come up and communication was possible. What my colleague not did was to do some intensive testing and check in detail the configuration.

The problems began ones these VPN tunnels were used for production traffic, they worked fine for some hours or maybe days but then suddenly you were not able to send or receive any data over the tunnel and mostly it happen over night where it was difficult to troubleshoot. In the beginning everybody said that it was a problem within the internet but when it happened three or four times a week I got suspicious that its something wrong with the boxes or even configuration.

First thing was to check the configuration and quickly I found a difference in the IPSec Phase2 default timers, the Juniper uses 1 hour and Cisco has 8 hours. I was happy and thought I found the reason for the connectivity problems but then two days later it happened again… 🙁

There where some strange syslog messages about anti-replay checking failed:

ASA-4-402119 IPSEC: Received an ESP packet (SPI= 0xFBEFD496, sequence number= 0x1C24) from (user= to that failed anti-replay checking.

These messages always came when we had the connectivity problems and that could be only now the last reason. I have to say I didn’t really found much but there were some articles that Juniper doesn’t support Cisco Anti-Replay checking and that you need to disable that on the Cisco side.

Here a release note I found from Juniper but it’s about Cisco’s GET VPN:


In the end that was the only thing I found and I thought give it a try and disable the anti-replay checking on the ASA when we had the problems again. I did so I waited until the problem happened again and disable the anti-replay checking with the following command:

crypto ipsec security-association replay disable

It’s global command were you disable the checking for the whole device. Here some more information:


When I disabled the checking the communication was suddenly possible again and since then the problem never happened again so the anti-replay checking was the cause of the connection problems between the Juniper and the Cisco. Always something new to learn 🙂

Cisco ASA TCP Syslog Problem

I ran today into a big problem with configuring an TCP syslog server on an Cisco ASA.

logging host "interface_name" "server_ip" tcp/514

After I put in the configuration and someone from the server administration restarted the syslog server and suddenly the whole communication through the ASA stopped working completely.

I saw the following messages in the ADSM and quickly realised that this could be only caused by the TCP logging configuration.

%ASA-3-201008: Disallowing new connections

I didn’t looked before if the feature is disabled to block new connections when a TCP-connected syslog server is down. This is very important that you disable the feature before you configure TCP syslog servers otherwise you ran into the same problem like me.

Here the command to disable the feature:

logging permit-hostdown

In my case I just forgot to check before and will definitively remember for the next time 😉