If I can run a site to site VPN, NAT & Reflexive ACLs on a edge router (plus normal routing functions), what would be the use of running a stock firewall behind it?
For instance, Core Switch --> Firewall --> Edge Router --> ISP connections
Asked another way, why would you want to run VPNs & Reflexive ACLs on the firewall, and NAT + routing functions on the router, if the router can do it all?
What you don't mention, and what is important generally for these kind of questions, is specifically what kind of hardware you have, what your requirements are (throughput, concurrent connections, cryptography load, etc.). What's a snapshot of your traffic look like, where's it coming from, and what, ideally, should be going in and out?
(And you've also got to worry about worse case scenarios -- depending on who you are supporting -- the world, external customers with SLA's, internal clients, two people in an office -- you might have to worry about worst-case just a little, or potentially it might be at the core of your design).
With that missing, here are some general reasons why I would avoid all-in-one solutions:
most role devices -- routers, or switches, or firewalls --- particularly once you get out of the low-end commodity stuff -- are optimized for their primary roles.
This means hardware is optimized -- cryptography for IPSec or other VPN is offloaded to ASICs, switch backplanes become superhighways (or not), specialized chips handle layer 2 flows, etc.. Cisco switches have used ASICS forever. Juniper and Cisco have been doing routing for a long time and know how to offload to hardware appropriately.
...and software is optimized. Components might work, but if they are additions, not integrated from the beginning, you'll see the result in flexibility, resilience, and stability. In many cases, companies have acquired because they have devices that they shore up a weakness and do one or two things very well -- over time features have been added (and added, and added), generally only in software, so that you, the customer can buy a nice "well-rounded" product. You can see the consequences of this in everything from basic user interfaces to the the rigidity of reporting tools for some components versus others. If you have reflexive ACL's and VPN's and IPSec and packet capture and deep packet inspection on a device -- someone has to configure it, someone has to monitor it, and someone will have to, at some point, troubleshoot it. Are these things that come naturally, flow from the design of UI, or do you have to call support just to explain menu verbiage, or to analyze a core dump?
Ridiculous analogy number one -- you can put a spoiler on a civic, and it might even do a little something, but that spoiler is really just a decoration. (If your security is all about hitting the right boxes for audits, sometimes you can "get away" with decorations. But this isn't real security, and we know it.)
Having a product that does too much can show up in product support as well. If you have a problem on your Everything Device, how much support is there for it? How long have they been supporting the 96th and 97th add-on capability of this device? If it's an afterthought, this could be trouble. How many developers does the vendor have involved in regression testing, bug fixes, and new code releases?
For hardware, often you can add modules that give you extra power in some areas. Cisco sells a lot of cards and modules that will offload crypto, or 'anti-X', or IDS/IPS work, and these go in everything from ASA's to 6500 core switches. Great idea? That depends. Can you afford another device, or will you do more with less?
And routers are still best at routing traffic, core switches are generally better not fooling with access-lists, firewalls are better off not running OSPF and BGP.
To end, here's another ridiculous analogy -- an athlete can be a fantastic swimmer, or basketball player, or gymnast, but that doesn't mean that the same athlete should also fill up a position on the football or rugby roster. If you're an IT person, and you have a set of requirements, you can have one device take up all those checkboxes on your list -- fill all the available positions on your roster. But if you've got the budget and resources to buy and deploy a stronger solution for each need you have, I would certainly go far that as a more sustainable strategy.
Separation of concern. Yes, the router can do the job of a firewall, but a proper firewall will do a better job. You will have more control over the network, and have a fallback if the router is breached.
There is no point in adding a stateful inspection firewall or moving VPN and NATing to a stateful inspection firewall. This is because stateful inspection firewalls classify and control traffic by port numbers. Given the number of port-hopping applications and the number of applications which use Port 80 or Port 443, a stateful firewall is useless.
However, I would recommend deploying a "next generation" firewall (NGFW) behind your edge router. The key functions the NGFW would perform would be application identification and control, user control, internal network segmentation, policy-based routing, QoS, and threat prevention.
As most of the popular attacks bypass a packet inspection firewall by running over port 80, I would suggest a slightly different configuration.
First, ten years ago, the major firewall vendors incorporated routing protocols into their firewalls, so that the edge router could be eliminated, simplifying network design and deployment. Enough corporate IT security types agreed, so Nokia/Check Point, Juniper/NetScreen, and Cisco had a thriving business. Thus, at least by popular opinion based on sales, you can have a solid network design if the firewall and edge router are the same device.
I would suggest, then, that you have a firewall/router at the edge, and then some kind of proxy or Deep Packet Inspection device just inside. The firewall/router handles all the old,"easy", well understood stuff. The proxy/DPI provides some protection against the current stuff. All internal traffic must go through a proxy/DPI device, to validate that the traffic going out is acceptable (not from a trojan or worm, not going to sites that would get the organization sued) and that the responses coming coming back are not malware (not that you'll get 100%, but you can reduce potential exposure).
You could get a DPI VPN firewall with routing, all in one box, for a bunch of money. That would be fine. I would suggest, then, that you divide the functional based on load rather than just function. So, if you have a lot of VPN traffic, and that is tying up the CPU, then it makes sense to get a separate VPN device. If DPI/proxy is taking a lot of CPU, pull that out to its own box.
Finally, get some of the Defense In Depth religion. Think about what vulnerabilities you have when different components of the network, say end user machines or the Exchange server or the company backup server, are compromised. Doing each in turn, think about your network design, how you would detect that the component was compromised, what next steps an attacker could make, and how you could clean up the mess after the compromised was found.
