This is the 12th blog in an Internet Edge series.
Links to prior blogs in the series:
- Internet Edge: Simple Sites
- Internet Edge: Fitting in SD-WAN
- Internet Edge: Things to Not Do (Part 1)
- Internet Edge: Things to Not Do (Part 2)
- Internet Edge: Two Data Centers
- Internet Edge: Double Don’t Do This
- Internet Edge: Cloudy Internet Edge
- Internet Edge: Special Cases and Maintainability
- Internet Edge: Security Tool Insertion
- Internet Edge: Internet Edge: Traffic Steering Part 1
- Internet Edge: Internet Edge: Traffic Steering Part 2
- Internet Edge: Internet Edge: Traffic Steering Part 3
It seems like time to revisit the “Big Picture” and also cover a couple of other items.
The Big Picture
As I reviewed some of the prior blogs’ cluttered diagrams showing WAN and Cloud and Internet, I realized there were a couple of other “edge devices” they didn’t show. This was done by intent since the diagrams were getting cluttered as they were.
The missing network devices: Remote Access VPN termination point and Site-to-Site VPN termination (router, firewall, or SD-WAN).
So, here’s one diagram with “everything” in it.
Figure 1: The Big Picture
While your Internet Edge might have a plethora of other devices in it (load balancers, WAN optimization, security tools, etc.), I’m resisting opening that can of worms, at least in THIS blog article.
The other thing that has been striking me as I’ve been writing these Internet Edge blogs is just how many variations are possible. E.g., firewall all the links above versus some. If some, which? Etc. Plus, do you have one or two of each in each datacenter, or is high availability present because of the 2nd datacenter having a copy of everything? (Usually, a copy to save money is what I think is most common.)
Firewall Sandwich, Anyone?
Another realization (insight?) is that I used to draw two firewall layers, aka “firewall sandwich.” I don’t think I see that so much anymore, probably for cost reasons. If you’re government or a financial, maybe you want two layers so as to have firewalls from two different vendors protecting you. Otherwise, cost, and what’s the point of two layers from the same vendor when you get right down to it?
The DMZ used to be in the middle of the sandwich (and likely still is). But it can just be a stub VLAN (or several) off the firewalls. We’ve seen that in some of my prior blogs’ diagrams.
Having said all that, I do think I’m seeing more firewalling between users and servers. And with SD-Access or other segmentation technology, anything resembling VRF’s, it seems highly likely you’ll want a firewall controlling cross-access between VRFs and also filtering VRF to server access. Perhaps something like the following:
Figure 2: Campus / User Firewall
Note that the bottom firewall pair is in a position to control traffic from one campus-side VRF to another, as well as from user/campus VRFs to the servers. And the Internet / WAN etc. as well, if you want to put the policy there. You’ll still need the “outer firewalls” to protect the DMZ from the Internet; ditto the servers.
That strikes me as a form of the “SD-Access Fusion Firewall” (discussed in that series of blogs). Or something like it, even if you’re just doing VRFs across the campus (and WAN?) up to the data center edge.
Obviously, there are many other ways to design that too.
There’s one more thing I intend with the above diagram. I recently had a discussion where the two data center core switches are ACI leaf switches. I’m a big believer in modularity and recommended having a pair of “edge core” switches (for lack of a better term). We’ve built that at another site, where a pair of switches tie together the optical MAN, ACI, SD-Access / Fusion Firewall components, the cloud connections, and the edge core, including Internet connections, DMZ, remote access and site to site VPN, security tools, and firewalls.
By the way, if you’re doing SD-Access Transit with overall Border Node pairs in two data centers, be aware there are some routing / failure mode considerations that I intend to blog about. There is no clear Cisco Best Practice that I know of (and I’ve asked around).
Conclusion
There are many choices in how you build your Internet (and WAN and Cloud), and that’s not even taking into account non-firewall security and other devices that might go into your Internet (and WAN, etc.) edge.
“Choose wisely.”
