Getting Started with the FWSM

Posted on April 30th, 2008 in FWSM, Firewall, Cisco, Security by Aaron Conaway

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.

Anyway, we won’t be going over any configs this time, but we can get some in the future. I just wanted to go over some stuff that you may need to know to get an FWSM working.

The FWSM does not have any physical ports on it. It uses the backplane of the switch to get a foot in the networks that you need it to. What does that give you? Well, it’s ultrafast on the 256Gbps backplane, which is a lot better than the 1Gbps on a physical interface. It also lets you have more interfaces than you could ever have on a firewall appliance (I think you can have 128 interfaces…someone correct me). I don’t know any firewall appliance that has more than 20 or so interfaces. It also is good for your cabling guy since there are no cables. I love it since I’m the cabling guy, too.

The FWSm can be set up with several security contexts. That means that you can chop up the resources of the module into “virtual firewalls” that operate separately from each other. This is pretty cool, actually, since you can, say, make a firewall for each of your hosting customers so that configurations on one don’t affect the others. You can also set the thing up in single context mode so it acts just like a single firewall. You’ll have to do some research to figure out what you want to do, and there are a lot of possibilities.

You can also set each context up in either routed or transparent mode. Routed mode is the “traditional” way to set up a firewall, where each interface is a different IP network with packets being routed through the FWSM. Transparent mode is where the FWSM has two interfaces that bridge the same IP network. I’ve always used routed mode everywhere, but you may have some use for transparent mode.

You also have to do some stuff on the 6500 to get the FWSM working. You make a vlan-group (a list of VLANs) to present to the FWSM and then assign that to the module. If you have more than one FWSM, you can have multiple vlan-groups; different FWSMs can control access in and out of different networks. Remember the context thing? If you have an FWSM in multiple contexts, you present the module with all the VLANs on all the contexts and split them up when you get to the context config part.

No configs. This is weird, but you’ll need to get all this information straightened out before you can get an FWSM configured properly.

ASA + HSRP/VRRP/GLBP = undef

Posted on April 4th, 2008 in GLBP, ASA, Firewall, HSRP, Cisco by Aaron Conaway

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.

Cisco uses two different methods to handle this issue - a failover cable or a failover interface.  On a PIX (above the 501s and 506s), you’ll see a DB-15 interface labelled…wait for it…”failover”.  When a very expensive Cisco cable is placed between the failover ports of two PIXes, the boxes do some election stuff over it and decide on an active and a standby state for each (it does all sorts of stuff, but I won’t go into it).  The other method is basically the same, but, instead of an expensive, proprietary Cisco cable, it uses one of the interfaces to connect the two.  You basically connect a crossover cable between two of them, do some configuration, and we’re good.   The ASA doesn’t come with a failover cable so it uses the interface method, but you need a license for that (imagine that).

Just for the record, if an ASA or PIX becomes the active member of the cluster, it takes over both the IP and MAC address of the primary.  There’s no election and configuration of a standby address.  The use of the real addresses, along with the constant sync of the state data, means a very fast and seamless failover.  I actually SSHed through an FWSM (think of it as a PIX on a blade) and pulled the power plugs from it; I actually only lost one packet.

DHCP on the ASA 5505

Posted on April 2nd, 2008 in LAN, DHCP, ASA, Firewall, Cisco, Security by Aaron Conaway

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.

dhcprelay server 192.168.14.11 inside
dhcprelay enable guests

Another piece of cake, right?

Setting up the 5505 to be the DHCP server requires a few more lines, but, again, it’s easy. In the simplest setup, you only have to define your DHCP scopes and enable it on an interface. Let’s set up a DHCP scope for the inside interface of 192.168.14.101 - 120.

dhcpd address 192.168.14.101-120 inside
dhcpd enable inside

You probably want to serve a DNS server to the DHCP clients as well. You have two options — you can provide your own DNS server or have the 5505 serve the DNS servers it got from the upstream provider (like your cable modem provider) via DHCP. To serve out your DNS server at 192.168.14.12, just do this.

dhcpd dns 192.168.14.12

Serving the same DNS servers that the firewall got from the provider via DHCP is a little weird. Who puts underscores in commands? Assuming your outside interface is toward your ISP, just do this.

dhcpd auto_config outside

There’s the basics, but you can do all sorts of stuff with it. Change the lease time. Set the default search domain. Set a WINS server. Notice one thing, though; there’s no way to configure a default gateway. The ASA 5505 (and the rest of the 5500 series) only serve their own IPs as the default gateway, so be aware.

Setting Up VLANs on an ASA 5505

Posted on April 1st, 2008 in Switching, Trunking, VLANs, ASA, Firewall, Cisco, Wireless, Security by Aaron Conaway

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.

When you have the base license and the ASA is in routed mode (you have IPs on interfaces), you can have three VLANs configured. One of them, however, has to be configured to not forward to one of the other VLANs. I had to go over that a few times before I got what the doc was saying. Basically, you have two VLANs that are fully functional and one that can only initiate traffic to one of the others. At home, I consolidated my network down to three VLAN — outside (I’net), inside (Users), and a DMZ (Guests). The inside interface can initiate connections to both outside and the DMZ, but the DMZ can only talk to the outside VLAN. This is probably not a very big deal to an average user, but I’m a network guy and will add networks just to say I’ve got one more subnet than you do. :)

I also had some confusion over the number of trunks available on this guy. My Aironet 1231 is set up to tag multiple bridged VLANs to the Ethernet so that I could have multiple SSIDs on it with each in their own VLAN. I did this by making the switch port on the 2950 into a tagged trunk. With the base license on the 5505, you don’t get any trunks. I didn’t find any docs that said you couldn’t, but it’s pretty obvious from the “show version” info.

VLAN Trunk Ports : 0

This really puts a damper on my AP setup. I had to reconfigure it to just use a single, untagged bridged interface with a single SSID. If I wanted to implement the Aironet 1231 the way I had it beforehand, I would have to upgrade my license on the 5505. I’m not paying any more money for this thing, so I’ll have to get one of my lab APs in place for guests. Thank God for eBay.

So, how do you configure this thing? First, let decide on our VLANs — say VLANs 11, 12, and 13. The configuration is just like any PIX 7.X

interface Vlan11
description OUTSIDE
nameif outside
security-level 0
ip address dhcp setroute
!
interface Vlan12
description GUESTS
no forward interface Vlan13
nameif guests
security-level 10
ip address 192.168.13.1 255.255.255.0
!
interface Vlan13
description USER
nameif inside
security-level 100
ip address 192.168.14.1 255.255.255.0

The interface VLANs are what handles the IP addresses. We’ll put specific ports in the VLANs in a minute, so hold tight. The configuration is pretty self-explanatory with VLAN11 being the outside (I’net), VLAN 12 being the DMZ (guests), and VLAN13 being the inside (users).  There is, however, the one line that reads no forward interface Vlan13. This is the line  that makes dictates which VLAN is a DMZ with respect to the base license and that this VLAN (VLAN12) can’t initiate connections to VLAN13. You also might have noticed the line ip address dhcp setroute. You can read one of the earlier articles on that guy.

The last thing you do is to put ports in VLANs. The ports on the 5505 are labeled Ethernet0/0 - 7, and you treat them just like an IOS switch with the switchport access vlan X command. At home, you would plug your cable modem (or whatever) into one of the interfaces (say, Ethernet0/0) and put that port into VLAN11.

interface Ethernet0/0
switchport access vlan 11

Plug all your stuff in, put the ports in the right VLAN, and enjoy.

Default Route via DHCP on an ASA 5505

Posted on March 22nd, 2008 in ASA, Firewall, Cisco by Aaron Conaway

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.

%ASA-6-110002: Failed to locate egress interface for UDP from inside:x.x.x.x/1028 to y.y.y.y/53 

I had no clue what this really meant until I checked the routing table; there was no default route at all.  For some reason, the ASA 5505 was ignoring the default route from the DHCP server upstream.  The fix?  Assuming your outside interface is VLAN 1, just do this.

interface Vlan1
ip address dhcp setroute

The box will go out and get the DHCP default route by itself, so no need to shut/no shut.

NAT on a PIX/ASA

Posted on March 13th, 2008 in PIX, ASA, Firewall, Cisco, InterNetworking by Aaron Conaway

NATting sucks and can be confusing. I’m sure everyone agrees to that, but you have to use it at some times. In a [tag]PIX[/tag]/[tag]ASA[/tag], 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 [tag]NAT[/tag] setup here is easy.

nat (inside) 1 0.0.0.0 0.0.0.0
global (outside) 1 interface

This NATs everyone on the inside (0.0.0.0 with a mask of 0.0.0.0, or 0/0) to the IP of the outside interface (overload in the IOS world). The nat command says who gets NATted; the global command says what they get NATted to. Notice the number “1″ in both commands; this is the NAT group and allows you to have some flexibility in your NAT strategy. In essence, if you match a nat line with a “1″ in it, you’ll be matched to a “1″ on the global list.

What if you add a DMZ interface and don’t want to NAT when your inside network talks to it? That, my friend, is a little more complicated. We’ll assume your internal network is 10.0.0.0/24 and your DMZ is 192.168.0.0/24.

access-list NONAT permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0

nat (inside) 0 access-list NONAT
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 1 0.0.0.0 0.0.0.0

global (outside) 1 interface

That was painful, but what did it do? That’s a very good question.

We have multiple nat lines on the inside, so the firewall starts at the top and works its way down (there are exceptions). The first nat line has a group of 0, which is very special. If you match group 0, you are not NATted at all, and your connection is passed as-is with no changes. In our second example, you match if the ACL matches, so, if you’re going from the inside network to the DMZ, you won’t be NATted. If your connection didn’t match this line (like you’re downloading porn from the Internet), the firewall goes to the next line, which says to NAT everyone to group 1 just as we did in the first example.

Another twist here is the “nat (dmz) 1 0.0.0.0 0.0.0.0″ line. This says that anything from the DMZ is NATted to group 1 just as the inside traffic is.

So, if the inside network connects to the DMZ, it doesn’t get NATted. If the inside goes to the Internet, it gets NATted to the outside IP of the firewall. If the DMZ connects to the Internet, it gets NATted to the outside IP as well, but what if the DMZ connects to the inside? That’s another story. :)

Commenting Access-lists

Posted on March 12th, 2008 in ASA, PIX, Firewall, Cisco, Security, InterNetworking by Aaron Conaway

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 [tag]remark[/tag]s to document each line of an [tag]ACL[/tag] (on [tag]IOS[/tag], [tag]PIX[/tag], [tag]FWSM[/tag], [tag]ASA[/tag], 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.

Easy to use.

access-list 101 remark This line allows access from the Internet to the development server. See ticket 1234
access-list 101 permit tcp any host 1.2.3.4 eq 80

Now, when you get asked the inevitable question, you can look at the line and know to check ticket 1234 for more information. The remark is just a string, so you can put what you want. I like to put source and destination hostnames, protocol/port, ticket number, and date/time the line was entered for reference like this.

access-list 2001 remark *** I’net — HTTP -> dev.example.com, Ticket 1234, 12Mar2008-0853 ***

It works with the ip access-list command as well.

ip access-list extended INBOUND
remark *** I’net — HTTP -> dev.example.com, Ticket 1234, 12Mar2008-0853 ***

It might be a good idea to use a remark to document what the ACL itself does. For example, on a firewall with 28974 interfaces, you might want to do something like this.

access-list DMZ1_OUT remark This ACL allows traffic out of the DMZ interface
access-list DMZ1_OUT remark *** ….
access-list DMZ1_OUT permit …

Can’t Login to Your ASA via SSH or Telnet?

Posted on February 18th, 2008 in ASA, PIX, Firewall, Cisco, Security, InterNetworking by Aaron Conaway

I deployed a [tag]Cisco[/tag] [tag]ASA[/tag] at a location and couldn’t get logged in via [tag]SSH[/tag]. 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 [tag]AAA[/tag] service wasn’t configured. I guessed wrong.

I’m sure this will apply to telnet sessions as well. I’d also bet money that equivalent [tag]PIX[/tag] OS versions do that same, so keep an eye out.

afs