I’ll start off with a warning.  I’ve been running 8.3.1 on my home 5505 for a few hours now.  Not only is this not really enough time for a thorough review, it’s also not the environment to test enterprise-level configurations.  There are also a lot of details missing that I just don’t know about yet, so please do some research on your own to figure out what’s going to break if you upgrade your ASA.

Here’s a simple one since I haven’t updated in a while. I have my ASA 5505 at home and want to forward TCP/80 traffic to my public IP to my webserver at 10.10.10.10. There are two steps here – forward the port and open the ACL.

To forward the port, I would use the static directive, but there are two ways to do that. I can either set up a one-to-one NAT or a port redirection. In the one-to-one NAT, you have a outside address that’s mapped directly to an inside address, and any traffic to that IP is passed to the inside host (if it passes ACLS, of course). One of the limitation, though, of using this setup is that you can’t use that IP as your PAT address, and, since I only have one IP, no other inside hosts would have a outside address to which to be NATted. The other method – port redirection – is a much better solution. In this setup, I actually forward a protocol/port on a outside address to a protocol/port on an inside address. Since there are other ports available on that outside address, the address is still available for other hosts to use as a NAT address.

Have I talked about the Cisco Firewall Services Module (FWSM) before? It’s a firewall on a module for the 6500 and is based on the PIX firewall. The term “based on” is important here, since it does a lot of stuff the PIX does but everything. It obviously does connection inspection and filtering, but it does not do any VPN stuff. It’s not a license thing; it just won’t do it. If you want to do VPNs on the 6500, you have to get the IPSec VPN Service Module.  The VPN thing isn’t true, actually.  I believe version 3.1 and higher has support for VPNs.

I use Google Analytics to track the 2 or 3 hits I get a day, and sometimes I see some interesting search terms. Yesterday, some googled up the term “does the ASA 5505 run HSRP”; I think that deserves a short article.

The ASA and PIX firewalls don’t actually run any of the usual HA solutions you use on routers. They don’t do HSPR, VRRP, or GLBP at all. Since firewalls have all sorts of state tables, connection tables, translation tables, blah, blah, blah, they need to share more information than just if they’re alive or not, so they use different methods to provide HA.

Let’s keep going with our example setup on the ASA 5505 and set up DHCP on this guy. You can set it up to either forward (relay) DHCP requests to a DHCP server somewhere or have it be the DHCP server. Let’s do it.

To set up DHCP forwarding, you have to configure where the DHCP server is and then enable the relaying on the proper interfaces. Let’s say we have a DHCP server on the inside interface at 192.168.14.11 and we want it to serve IPs to the guests network. Setting up the DHCP server is beyond the scope here, so you’ll have to look elsewhere on how to set that up.

I’ve had my ASA 5505 in place at home on my Comcast cable for a few weeks now, and, let me tell you, this thing rocks. I did, however, have a few problems finding a clear answer on how I could set up my VLANs. It turns out that the base license on the ASA 5505 comes with a few restrictions with regards to VLANning – in particular the number of VLANs and the number of trunks.

I finally got my ASA 5505 up and running at the house, but I ran into a little problem – the box wouldn’t add the DHCP-provided default route into its routing table.  That one threw me for a loop since the box is made for SOHOs, but it makes sense in some corporate, lazy way.

I got an IP from the DHCPD on the 5505, but I couldn’t get to the Internet.  I checked the console, and it had an IP from the provider, so I checked ACLs; those were fine.  I looked at the log and found this.

NATting sucks and can be confusing. I’m sure everyone agrees to that, but you have to use it at some times. In a PIX/ASA, it’s easy to configure a simple setup, but can be super-complicated in larger networks. In a simple lab, we have set up an ASA with inside and outside interfaces, with the inside as your internal and outside as the Internet.

The NAT setup here is easy.

There’s a very-overlooked feature of access-lists – the remark. Yes, this is very basic, but it’s worth mentioning, as it has saved me anguish time and time again.

I use remarks to document each line of an ACL (on IOS, PIX, FWSM, ASA, etc.) so that when I go back later, I actually know what I did. They’re simple to use, and, I promise you, you’ll thank yourself for using it when the CTO asks why access to TCP/80 is open from the Internet to the development server.

I deployed a Cisco ASA at a location and couldn’t get logged in via SSH. I would get prompted, but, no matter what username/password I put in, it would just reject me. After some digging, it turns out that I forgot this command.

aaa authentication ssh console LOCAL

When I put this in, it let me right in as expected. I have no clue what the deal was. I guess I assumed that the ASA would use the local userbase if a AAA service wasn’t configured. I guessed wrong.