Forum Discussion
STTR_85331
Nimbostratus
Mar 31, 2011LTM DMZ Design Question
Greetings,
We have been running a pair of LTMs in production for several years in what I would consider "one-armed" mode in that the traffic flows as follows:
Internet<-->Firewall...
Joel_Moses
Nimbostratus
Apr 01, 2011@Simon: You got the meaning right on "weak routes". I'm not a huge fan of them either; they're a bit of a bear to administrate unless your server folks are really on top of their game. But they do provide one additional layer of protection against attacks that try to generate arbitrary traffic through vulnerable web components.
We divide infrastructure stacks by different LTMs _and_ different VLANs; we share ACLs and firewalls, though, because it's easier to get an overall access control policy view that way -- and the bottleneck for our infrastructure stacks are almost never at the firewall because it's pretty much being used as a policy engine and not an IPS/IDS/WAF (we've got other components that do that to varying degrees in each stack. The stacks consist of two VLANs in the middle DMZ - one public numbered one ahead of the LTM, and one private numbered one just behind it where the DMZ servers sit. To Jason's point above, I'm not a fan of multiple interfaces on DMZ servers either -- we just use one interface and allow the routing table to do what I described earlier.
I should note that we DO have stacks that do not sit behind LTM that perform, say, outbound only functions. But those are the exceptions and not the rule.
Regarding the database servers -- we have another VLAN off the inside firewall where we place those; it allows isolation of datastores from the internal network except by authorized networks/administrators, and it provides control over which database servers/databases a particular web server can use. In the event of a direct server compromise (however unlikely), then other datastores not used by the application are largely inaccessible.
@Hamish: I agree with your assessment of not loadbalancing protocols that have built in load balancing (SMTP MX), but it is sometimes useful. Some organizations have inbound mail volumes that frequently overrun the ability of individual gateways to process (especially if those gateways do anti-spam and malware filtering), and each bump to a lower-priority MX means more delay time to email receipt. It's pretty easy to just pool a group of SMTP servers together behind a VIP to keep it from having to hunt -- if you have the bandwidth at your receiving site.
And that's a great list there. Should be enshrined on a velvet painting, IMHO.
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects