[c-nsp] ASA 5505 multiple netblock functionality

[Kaj Niemi]

Hi,


The default license allows for 2 unrestricted vlans + 1 restricted  
('dmz'). The restricted one cannot initiate traffic towards one of the  
other vlans.

# sh ver

Cisco Adaptive Security Appliance Software Version 8.0(4)16

...
Hardware:   ASA5505, 256 MB RAM, CPU Geode 500 MHz
...
Licensed features for this platform:
Maximum Physical Interfaces  : 8
VLANs                        : 3, DMZ Restricted
Inside Hosts                 : 10

To get around this restriction you would need to buy another license  
(Security Plus). As for 'multiple contexts' - the 5505 does not  
support any.

Refer to http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps6120/product_data_sheet0900aecd802930c5.html 
  for more info.



Kaj

On Mar 5, 2009, at 00:55, Jonathan Brashear wrote:

> Apologies if this has been addressed previously, I looked through  
> the last 12 months of c-nsp threads and didn't see this mentioned.
>
> There is some debate going on in my department over a particular  
> implementation and the 5505's capability to handle multiple  
> netblocks. A quick primer on the situation:
>
> Firewall IP: 1.2.3.4(publicly routable, but changing for cust privacy)
> Customer netblock: 5.6.7.0/26(it's publicly routable as well, I'm  
> changing for sake of cust privacy)
> Customer NAT: 192.168.0.0/24
>
>
> The /26 is statically routed to 1.2.3.4 from the router level, and  
> the customer wants to run NAT for their internal devices(db servers,  
> etc.). Our implementations guy states that the 5505 can't handle  
> assigning 3+ netblocks because they can't run multiple contexts. My  
> experience with the ASA firewalls is limited so I very well may be  
> wrong, but I believe the 5505s should be able to handle multiple  
> netblocks on the internal side of the firewall using something such  
> as sub-interfaces or similar. Can anyone help explain why this is or  
> isn't feasible?
>
> They don't need to be on the same physical interface necessarily, we  
> can run them to separate physical interfaces because this customer  
> is hairpinned behind a switch(and the servers are connected to said  
> switch instead of the firewall directly) so port density isn't a big  
> issue(to a point).
>
> We can assign a netblock to each internal port on the firewall if  
> need be - which seems to be the best solution from what I'm  
> uncovering - and that works as a reasonable alternative. It doesn't  
> scale very well obviously, but I don't think this customer is going  
> to chew through netblocks at a rate where this will be an issue.
>
> Network Engineer, JNCIS-M
>> 214-981-1954 (office)
>> 214-642-4075 (cell)
>> jbrashear at hq.speakeasy.net
> http://www.speakeasy.net
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/





Kaj
-- 
Kaj J. Niemi
<kajtzu at basen.net>
FI +358 45 63 12000
KSA +966 54 52 43277