Just want to throw another data point into this confusing discussion. The low-end Cisco ASA 5505 requires VLAN configuration since it is just a switch.
The Cisco ASA 5510 has four Ethernet ports. If you need more, just use VLAN. Perhaps, Cisco is expecting a firewalled network to use managed switches. Is it best practice? Why is there a resistance to VLAN in the pfSense community? I had somebody asked about at least ten port pfSense router with ability adding more as needed. He wants to provide Internet to a building but wants each tenant to be on a separate network. I asked why doesn't he just use a managed switch and trunk everybody to the router? I sold a Cisco Catalyst 3500XL with 48 Fast Ethernet ports for $35 a couple of months ago on eBay. I don't think cost is the issue. Bao On Thu, Aug 5, 2010 at 10:08 AM, Adam Thompson <[email protected]> wrote: > Comments from another perspective on the must/should question: > > Best practice says to physically segregate networks by trust level and by > impact of error or breach. > > Somewhat self-evidently, this is to mitigate the impact of a) errors, and > b) security breaches. Of the two, errors (i.e. human errors) are by far > the more common problem. > > If you have a separate NIC for each network coming in to your firewall, > the cables are well-identified, the ports are well-identified, and the > other endpoint of those cables is also well-identified, it's much harder > to accidentally expose high-trust traffic to a low-trust network. > Specifically, it's far likelier that someone will notice that the cable > they're holding has an "AT&T" tag on it but the port they're about to plug > it into has a "PacBell" label over it. > > When you use a switch and VLANs to segregate traffic, you have to worry > about things like: in a pathological power situation (lightning strike, > UPS blows up, whatever) if the switch is suddenly reset to factory > defaults - and I've seen this happen - what will happen? Every port gets > reset to VLAN 1 with no filtering, and all your traffic is suddenly being > propagated to every network segment. > > Maybe you're thinking "big deal", but now consider the fairly-typical WAN > situation where you're running routing protocols across WAN links, say > RIPv2 without authentication (because you trust all the networks involved, > right? It's a point-to-point link, right?). Your network topology > suddenly collapses and takes [fixing or unplugging]+2hrs to reconverge. > > Or the situation I once found: two smallish WAN providers both (stupidly) > left STP turned on at the edge... when they were suddenly bridged together > (by accident, I made a typo when setting up the VLANs) I managed to take > down most of both providers' networks, and typical of STP both were down > for <time to figure out what I did and fix it>+5 minutes. Obviously I > wasn't happy, and when we all figured out what had happened they weren't > very happy with me, either. > > As to security breaches, it is extremely difficult to a) know about the > switch, b) target the switch, and c) hack the switch, but it's > *infinitely* harder to hack a piece of Cat5 cable than a switch! > > Having said all that, many of the firewall modules/blades you can buy for > chassis-based routers and switches (Cisco 3600 ISR, Catalyst 10000, > Juniper [something], etc.) require you to configure their ports entirely > using VLANs anyway. > > So it's hardly a universal "must", certainly not in the technical sense - > it's a very, very strong "should" that you should only disregard if a) > you're overconfident of your own abilities, b) you have no truly private > data, c) you don't care too much about pissing off your WAN providers (or > you know they won't even notice!), and d) you don't have enough space to > mount one or two more switches in the server closet. > > Note also that you might be tempted to use 802.1q-over-802.3ad > (VLAN-over-LAG), which does work... but also generally speaking turns off > a lot of the hardware acceleration your NIC can do for you. Many NICs > (certainly any half-decent one!) can still do IP offload with 802.1q (VLAN > tagging), but I haven't run into any that can still do IP offload with > 802.3ad (link aggregation, aka "bonding", or "etherchannel"). Bundling > links together (LAG) actually slowed my router down instead of speeding it > up. > > Another aspect is that if you're going to run your router in a blade > chassis, say, (virtualized or not) you really won't have much choice but > to use VLANs for everything - most blade chassis don't give you dedicated > physical Ethernet ports, certainly not more than two on any I've seen. > Most of 'em have an embedded NIC (or two, or four...) that plug straight > into a backplane and are only exposed via a switch module. > > (I am also noticing that pfSense 1.2.3 does not have good performance (for > me, at least) forwarding traffic between "virtual switches" on a VMWare > ESXi 4 host connected to the switch through a 4x V-in-LAG trunk. I > haven't had time to isolate the problem yet, although I observed slightly > better performance when I let VMWare handle the VLAN tagging instead of > pfSense (i.e. created 4 untagged virtual e1000 NICs instead of 1 tagged > vnic). Performance only seems affected if either ingress or egress > traffic is local to the ESXi host, I see more-or-less normal performance > if both src and dst are off-host.) > > -Adam Thompson > [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > Commercial support available - https://portal.pfsense.org > > -- Best Regards. Bao C. Ha Hacom OpenBrick Distributor USA http://www.hacom.net voice: (714) 564-9932 8D66 6672 7A9B 6879 85CD 42E0 9F6C 7908 ED95 6B38 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] Commercial support available - https://portal.pfsense.org
