devnull22
asked on
How to best secure a network with many servers you do not control completely, VLAN or firewall on switch?
Hello all, We are planning to host servers for our clients and employees, mostly as a favor and not as a core business, and we are in planning of the network part of the infrastructure.
Basically, we would like to use a firewall (cisco ASA 5510) and switches, but don't want to have 1 firewall per server. Also, the setup gets more complex because some servers need to be in a domain, but we would like to secure them so that they can speak with the domain, but not see other domain members (ip wise) but as the servers themselves have users that can manage them completely, a software firewall is out of the question.
So I have two likely scenarios, and one spinoff that's a mix and match of both, and I would love your input as to which products would work well, and how to configure this so it's secure, efficient, and if possible, manageable without taking too long to set up a new server ;-)
1) Use different VLANs for each "client" network, with the firewall acting as a router to route vlans. I am a bit unfamiliar with a setup with the many vlans that would need to be created (upwards of 20 eventually) and how that would work on an ASA with 5 interfaces. I imagine a trunk port on the switch, and trunking on the ASA but the docs I found so far have confused me more than helped me. That still causes me a problem for different vlans that need to be in the same domain though.
2) Use 1 vlan, one subnet, but use port security to dictate which ip can communicate with which ip and on which port. That solves the firewall's problems, but makes it more complex to manage the switch, and the switches I'm used to working with (29XX series) mostly do not have this feature. I would need help on which models would work best in this scenario, since performance on the switch side will be needed more than scenario 1
3) Though I read this isn't a good idea, a switch split by vlans, but on one subnet, and DCs and the firewall in all the vlans. I know a vlan splits the broadcast domain, thus making it impossible to ping, or cummunicate without routing, but this is sort of the purpose needed, but I have no idea if domain members need to speak to each other for any reason, if we do not wish them to be able to.
Any other suggestions are welcome!
Basically, we would like to use a firewall (cisco ASA 5510) and switches, but don't want to have 1 firewall per server. Also, the setup gets more complex because some servers need to be in a domain, but we would like to secure them so that they can speak with the domain, but not see other domain members (ip wise) but as the servers themselves have users that can manage them completely, a software firewall is out of the question.
So I have two likely scenarios, and one spinoff that's a mix and match of both, and I would love your input as to which products would work well, and how to configure this so it's secure, efficient, and if possible, manageable without taking too long to set up a new server ;-)
1) Use different VLANs for each "client" network, with the firewall acting as a router to route vlans. I am a bit unfamiliar with a setup with the many vlans that would need to be created (upwards of 20 eventually) and how that would work on an ASA with 5 interfaces. I imagine a trunk port on the switch, and trunking on the ASA but the docs I found so far have confused me more than helped me. That still causes me a problem for different vlans that need to be in the same domain though.
2) Use 1 vlan, one subnet, but use port security to dictate which ip can communicate with which ip and on which port. That solves the firewall's problems, but makes it more complex to manage the switch, and the switches I'm used to working with (29XX series) mostly do not have this feature. I would need help on which models would work best in this scenario, since performance on the switch side will be needed more than scenario 1
3) Though I read this isn't a good idea, a switch split by vlans, but on one subnet, and DCs and the firewall in all the vlans. I know a vlan splits the broadcast domain, thus making it impossible to ping, or cummunicate without routing, but this is sort of the purpose needed, but I have no idea if domain members need to speak to each other for any reason, if we do not wish them to be able to.
Any other suggestions are welcome!
Sorry i meant 2960 series cisco switch
ASKER
I agree that the ASA will not be able to do the VLAN itself, my concern was mostly on how to configure the ASA once the switch has, say... 20 VLANS.
My license is as shows:
Licensed features for this platform:
Maximum Physical Interfaces : Unlimited
Maximum VLANs : 100
Inside Hosts : Unlimited
Failover : Active/Active
VPN-DES : Enabled
VPN-3DES-AES : Enabled
Security Contexts : 2
GTP/GPRS : Disabled
VPN Peers : 250
WebVPN Peers : 2
Advanced Endpoint Assessment : Disabled
This platform has an ASA 5510 Security Plus license.
I just am not sure how to proceed to configure the ASA to route through the 20 or so VLAN I might end up having in scenario 1. =) That still leaves me with figuring out how to stop "some" servers from seeing each other, but seeing the domain (custom app, needs domain, multiple client using the app in the same domain, which is not something we have control over due to licensing of the app) Separate vlans here to stop the servers from seeing each other is problematic, and software firewalls is an issue cuz it could be disabled by the users on the server/station which need admin access on their stations.
My license is as shows:
Licensed features for this platform:
Maximum Physical Interfaces : Unlimited
Maximum VLANs : 100
Inside Hosts : Unlimited
Failover : Active/Active
VPN-DES : Enabled
VPN-3DES-AES : Enabled
Security Contexts : 2
GTP/GPRS : Disabled
VPN Peers : 250
WebVPN Peers : 2
Advanced Endpoint Assessment : Disabled
This platform has an ASA 5510 Security Plus license.
I just am not sure how to proceed to configure the ASA to route through the 20 or so VLAN I might end up having in scenario 1. =) That still leaves me with figuring out how to stop "some" servers from seeing each other, but seeing the domain (custom app, needs domain, multiple client using the app in the same domain, which is not something we have control over due to licensing of the app) Separate vlans here to stop the servers from seeing each other is problematic, and software firewalls is an issue cuz it could be disabled by the users on the server/station which need admin access on their stations.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Generally you should be fine sending 20 vlans through your ASA, but if you have a large amount of traffic on each vlan then you might overload the interface.
"Separate vlans here to stop the servers from seeing each other is problematic"
The ASA will be able to route traffic between vlans if you want specific vlans to communicate with each other.
"Separate vlans here to stop the servers from seeing each other is problematic"
The ASA will be able to route traffic between vlans if you want specific vlans to communicate with each other.
If you used a protected port, you would have to route at Layer 3 any data you want between it and any other protected port. Enabling protection on a port restricts it from sending and data at all at Layer2 levels. I could see this becoming anoying and difficult to maintain.
protected ports is exactly what he is looking for.
Your client PC can not see smell or touch the other networks but you don't protect the DOMAIN controller all clients can see the DC but not eachother.
It is one command per switch port (How is that hard?)
Configuring 20 different VLANS is much harder to maintain.
Just to be clear this is eactly how Hosting companies do their networks(except they have fancier setups with private vlans sometimes and promiscous ports)
Your client PC can not see smell or touch the other networks but you don't protect the DOMAIN controller all clients can see the DC but not eachother.
It is one command per switch port (How is that hard?)
Configuring 20 different VLANS is much harder to maintain.
Just to be clear this is eactly how Hosting companies do their networks(except they have fancier setups with private vlans sometimes and promiscous ports)
Reread the statement
If you used a protected port, you would have to route at Layer 3 any data you want between it and any other protected port.
Span that across a few switches, combine with routes for "special" reasons (which would require additional hardware)
Quote
"Just to be clear this is eactly how Hosting companies do their networks(except they have fancier setups with private vlans sometimes and promiscous ports"
/Quote
Except they do it with VLANS... thats what im talking about doing
If you used a protected port, you would have to route at Layer 3 any data you want between it and any other protected port.
Span that across a few switches, combine with routes for "special" reasons (which would require additional hardware)
Quote
"Just to be clear this is eactly how Hosting companies do their networks(except they have fancier setups with private vlans sometimes and promiscous ports"
/Quote
Except they do it with VLANS... thats what im talking about doing
Thats fine he can use VLANs if he doesn't want to use protected ports. I'm telling you it is industry standard that is all I'm saying. This requires a managed switch the poster may not have one. But this is such a common solution that it is supported by most vendors.
PS the point of using protected ports is that one port on the same subnet needs to see common ports but not other hosts. So their is no reason to route between them because that would defeat the whole point which is that they don't talk.
ASKER
I might end up using a mix of VLANs and protected ports, but am unsure the models of switches we are using so far will suffice as we had smaller needs up till now.
From which models can I expect protected ports to work, as I cannot compromise features for switching performance?
Another point I failed to mention (as I got briefed more thoroughly after posting) is that we also might end up using ESX 3.5 and protected ports alone won't be able to work since it shares one network card, but can use 802.11q to tag packets with VLANs. So my setup just got a bit more complex...
As for my initial question, how would one go with configuring the ASA with using many vlans, as I am used to use the physical interfaces, but not using vlans...
Secondly, has anyone used the same subnet with many vlans, even if not recommended, it could amount to the same as protected ports, but would work with ESX.
From which models can I expect protected ports to work, as I cannot compromise features for switching performance?
Another point I failed to mention (as I got briefed more thoroughly after posting) is that we also might end up using ESX 3.5 and protected ports alone won't be able to work since it shares one network card, but can use 802.11q to tag packets with VLANs. So my setup just got a bit more complex...
As for my initial question, how would one go with configuring the ASA with using many vlans, as I am used to use the physical interfaces, but not using vlans...
Secondly, has anyone used the same subnet with many vlans, even if not recommended, it could amount to the same as protected ports, but would work with ESX.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you all for your help and comments, I am gonna pursue the VLAN option, as dealing with ESX leaves me little choice. I will investigate all options suggested for the rest though, as protected ports sound good for other setups we will eventually have to use.
On the switch you will separate the connected devices into vlans and then connect the switch to your ASA. The asa can handle all the routing and you can configure centralized security on it.