This is a simple one, but still a good one that might make someone’s VPN life a little easier: how do you assign static IP addresses to ASA VPN clients
This is a simple one, but still a good one that might make someone’s VPN life a little easier: how do you assign static IP addresses to ASA VPN clients when you use a local IP address pool on the ASA?
In most cases, your VPN clients can be assigned an any ol’ address from your local IP address pool, because they’re not providing any services on your network, right? But what if they are? What if one of your VPN clients belongs to a developer who writes code on his local machine and he wants to show other developers the results of the code he’s written? Or what if you have ACLs elsewhere in your network that need to apply to a particular VPN client/user, but not to others? A static client IP address might be the only way to handle those requests.
If you love multi-factor authentication like I do–ok, I don’t love it, we don’t know each other well enough for me to call it love just yet…it’s still a new relationship, ok? Don’t pressure me!
Multi-factor authentication is not a Security silver bullet. It’s just a way to add another layer to the “security onion”, making an authentication breach a little more difficult for attackers and making that vector a little less desirable. If you read about the RSA SecurID breach not so long ago, you know that even the most respected vendors can take a tumble.
So, this article is not about who has the best product or how to make your network impenetrable–it’s about providing another layer to your remote access security, using Cisco ASA and AnyConnect, along with a Microsoft CA server you may already have running in your environment. And as usual, I’ll focus on the Cisco configuration, rather than the Microsoft server config, since I don’t manage that device. Read more
Last time, I wrote about using samplicator to share netflow sources with multiple destinations in cases where the netflow source will only allow a single host–i.e., a Cisco router. The problem is that I really didn’t write much about what to actually do with all of that data, and chances are, you’d like some pretty pictures/graphs of it to amaze and delight your friends. At the very least, you’d probably like to have something to show someone else what you’ve been wasting all your time on.
So, let me introduce you to the dazzling combo, nfdump/nfsen–yes, I wrote dazzling. Nfsen, as you may have read, is a graphical interface for all the data nfdump collects, so you’ll see those pictures you wanted, and you’ll also have the ability to query the nfdump data to look at specific flows. Pretty cool stuff for $0, eh?
It started out simple enough: boy needs free, web-based application to send netflow data to, boy finds one and is happy with it, boy realizes that Cisco devices will only let him send netflow to two netflow collectors at most, boy has another problem to solve. Yes, it’s very sad, and so universal.
And, as has been the case so many times before, the right woman saved me. I don’t remember the exact question I posed to her, but in a matter of seconds Ms. Google pointed me to a Google Code project called samplicator that does exactly what I needed.