I just decided (early this morning) to give my radware appliances a firmware roll/update. I had a few incidents with the running firmware… and I decided to go to the non-ga releases, since after reading the extensive release notes and maintenance release notes, it turned out that the new versions carried a LOT of bugfixes, and huge performance improvements (even if I didn’t ever notice a slowdown). After a few hours of careful upgrading the machines (a couple of wsd (AS1) and a couple of ct100) are now online with the latest firmware… or nearly.

I discovered in fact that the latest firmware changed name… the new products are named AppDirector (for wsd) and AppXcel (for the ct100). Radware also suggests to upgrade to those new releases… but despite my bleeding-edge orientation, I decided not to go that way… for a couple of reasons:

– I don’t see major improvements, for the moment.

– Configuration will surely be different and since I put up a really complex scenario… it’s not time to mess it up so lightly.

– My experience tells me that radware’s stable releases are stable after a few months of GA… and maybe more… and since the 2 new firmwares have been on the shelves for a couple of weeks… well… I won’t test these for them…

Anyway… I’ll keep an eye on the new App* stuff… We’ll see if cool things show up in the future.

sslexplorer logoIn my last post, I stated that openvpn could be considered the perfect vpn solution nearly always. Well, “nearly” was there since another great opensource project appeared to me a few months ago: sslexplorer. While openvpn and sslexplorer share ssl as a security layer, their approach to vpns is totally different. Openvpn is a client-server based solution which uses ssl as a secure way to encapsulate ip traffic over a secure udp/tcp connection, while sslexplorer is a browser based vpn solution, which relies on https for communication security.

sslexplorer is a java based project that greatly simplifies the burden of distributing and configuring clients that other vpn solutions impose (while openvpn is way easier, though, than all the ugly ipsec stuff in general). Simply put, the client doesn’t exist… or at least the relevant part needed for secure communication is activated as a signed java applet after the user accesses the sslexplorer portal via a standard web browser. The java applet is responsible for the secure communication (ssl based) from the client to the server and back, and sslexplorer itself acts in general as a proxy to the corporate resources. Among other things, it can allow you to reverse proxy corporate intranet sites, redirect tcp ports for e.g. the corporate mailserver, or maybe give you access to a java applet that acts as an ssh client to your *nix servers. All this lives inside the browser session, so you can easily be at your favorite internet cafe @whatever place and without any sotware requirements other than a browser with a decent java plugin, you can get full access to your corporate resources in a snap.

But they went even further! If you do have your preferred email application (thunderbird, of course) at hand, why would you rely on that uncomfortable intranet webmail app? Just fire up the “bird” and configure it so that it points to localhost:xxxx where xxxx is the port number your friendly sslexplorer java applet is proxying versus your intranet imap/smtp server, for example.

Many other things not covered here make sslexplorer another great great opensource project (like, e.g., its powerful web based management interface).

Obviously, while sslexplorer is a great solution for roadwarrior vpn setup, it isn’t the right solution for site2site architectures. But for this, guys, there’s openvpn 🙂

Jump in the openvpn & sslexplorer club… we’re having a hell of a party 😉

openvpn logoA couple of years ago I discovered OpenVPN (www.openvpn.net). What an amazing piece of software! I digged into it very deeply, and concluded that’s imho the perfect vpn solution in most cases (or all cases, maybe). It’s an userspace application (no more kernel fiddling), it’s multiplatform, it’s udp OR tcp based, it uses openssl as crypto library (openssl is damn good!), it can pass through proxies, it can use certificates (or not!), it can authenticate users via pam or whatever… the feature list is endless, and I found everything to work even more than expected. It’s way way robust and stable and secure… And client deployment is hassle-free!

Having it tested (on the client side) on linux, win, and osx boxes, I thought at that stage that one could never ask of something more from a vpn solution. Then, it came to me that I own one platform that could bring openvpn coolness even further: the pocketpc. After a few post on openvpn’s official mailing list, I found that many other desired a openvpn pocketpc port, but a few people around seem to be able to develop on that platform (me… not for sure!).

As always, I kept my interest alive for this great project… till one day I saw on openvpn.net homepage a note about an ongoing project for porting openvpn to the pocketpc. After the initial surprise, I found that the project was already at a good stage, even after few days of work about the almighty Ziggurat29 (project mantainer).

Well… believe it or not, even the first alpha made my imate jasjar fly over my openvpn server @ my company. It was already stable and implemented nearly all of openvpn’s main source features. The openvpn for pocketpc community started to grow (with respect of pocketpc relative market share), and Ziggurat29 made an incredible job, providing us in a few weeks with an excellent openvpn client. Zigg is very conservative and considers openvpn for pocketpc at alpha or beta (at most) stage, but I can guarantee that I’ve been using it flawlessy for a couple of months now, and it allowed me to widespread the “always connected” philosophy inside my company (even one of the big big bosses is using an imate jamin for corporate email access via openpn).

Note that I banged my head for a while with windows mobile’s incarnation of a vpn… via l2tp/ipsec. Needless to say, it was a nearly complete failure. It helped me raise my hate versus ipsec, which I consider an old and absolutely obsolete protocol/approach to vpns in general.

So, all my respect to Jim Yonan for openvpn itself, and to Ziggurat29 for this great great porting project.

veritas logoI’ve been using Veritas Cluster Server for a few months now, and I can say that it performs really fine, with many more features than I could expect. One thing that bothered me from the beginning, though, is that 9/10 of my servers being part of a cluster were cluttered of strange/weird messages in the dmesg about the llt protocol/subsystem.

llt (low latency transport) is the protocol used in Veritas Cluster Server for heartbeat communication between cluster members. As the (poor, in this case) documentation states, it should perform really much bettere than tcp-udp/ip, which is a must in case of clusters, and even more a must since afair, llt transports also locks/state information about Veritas Clustered Filesystem. This in particular is a piece of jewel imho, since I have been chasing a fast/reliable yet simple approach to a shared filesystems for ages ;-).

Well, about the llt issue, it appeared that apart from being so smart and quick, it complained in my poor dmesgs about “lost packets” or maybe “packets out of sync”. To put it simply, it turned out (after emailing a Veritas support representative) that in case you use more than one nic per cluster for heartbeat purposes (that’s my case, indeed 😉 ), they should by default not share the same networking hardware (hub, switch). In my case all clusters share the same couple of Gigabit Ethernet (copper) switches, which in turn are tied together by a h.a. setup.

In conclusion, there was a solution directly on the servers’ side. Just change one entry in /etc/llttab and you’re set. Actually, this caused the different nics to “pair up” to their right partner in the cluster (e.g. eth2 to eth2, eth3 to eth3). This is the so called “SAP”, which defaults to the hex value “0xcafe”, and which I have changed , as suggested, to “0xcaf0” instead. This had to be done on all nodes and according to the named interfaces (only on eth3, in my case).

Well… this probably may sound heavy voodoo (and mostly useless 🙂 ) to all the fellas that didn’t get the chance to dig their nose in the VRTS stuff… but once you’re at it… I can guarantee this cluster software is a really good piece of code. Expensive… but it’s really well worth the price. Actually, it’s one of the few non-opensource solutions that I would suggest (while I’m using succesfully MANY opensource clustering solutions… from openssi to linux-ha, from ultramonkey to heartbeat, lvs and friends). Ah, and btw it cleaned up my poor dmesgs at last… and afaik even the clustered filesystem and the cluster overall should perform even better.