For remote sites, with a VPN backup connection back to the Headquarters, It would seem prudent to make sure that the tunnels coming in “hot off the Internet” should pass through an edge firewall and IDS before it terminates to the routers/security appliances acting as Concentrator.
My question is, should the decrypted segment off that Concentrator then directly touch the core of the network, or should it pass back through the firewall once again before gaining access?
I realize not one size fits all but I’m looking for a general sense of “best practice.”
And if the remote sites have a provider-managed L3VPN as their primary link, should that go through a firewall as well before reaching the Core? Should we tunnel through that as well?
i.e. L3VPN and IPSEC VPN both “meet” at the same point and share routing across tunnels?
You obviously know more than me, so excuse the ignorance but I do want to make one point. Why even bother slowing down the traffic with a IDS/IPS when that encrypted traffic won’t really be scanned well? Scan it after it’s decapsulated and bare on the network towards it’s intended destination.
should pass through an edge firewall and IDS before it terminates to the routers/security appliances acting as Concentrator.
Why? Unless it’s SSLVPN with MITM intercept, what could these devices possibly do to the traffic other than pass it through?
should the decrypted segment off that Concentrator then directly touch the core of the network, or should it pass back through the firewall once again before gaining access?
I don’t think I’ve ever seen a VPN link hairpin through a firewall after terminating on the concentrator. Most concentrators, like ASAs and Fortigates, already have basic IPS features like anti-scanning. I generally rely on host security features to make sure the remote site is secure, as that software has access to more data than the network.
tl;dr just route the decrypted segment to your core
And if the remote sites have a provider-managed L3VPN as their primary link, should that go through a firewall as well before reaching the Core? Should we tunnel through that as well?
Generally you want your MPLS L3VPNs to have encryption on top of them, as many providers won’t guarantee they’re encrypting CE-to-CE. That usually means terminating it on something firewall-like, although if it’s not a dedicated security appliance you may have to enable a bunch of non-default features to get basic IDS and IPS.
It would seem prudent to make sure that the tunnels coming in “hot off the Internet” should pass through an edge firewall and IDS before it terminates to the routers/security appliances acting as Concentrator.
Most VPN concentrators are firewalls themselves. What benefit would a second firewall in front of it add?
should the decrypted segment off that Concentrator then directly touch the core of the network, or should it pass back through the firewall once again before gaining access?
That depends entirely on your security policy. If it’s “trusted” traffic then it should hit your core, preferably in a separate VRF than your servers. Then you can have a standardized security policy between branch offices and servers. If it’s untrusted traffic it should be further filtered and utilize an IPS/IDS. We do this with Firepower on our VPN concentrator and core firewalls.
And if the remote sites have a provider-managed L3VPN as their primary link, should that go through a firewall as well before reaching the Core? Should we tunnel through that as well?
This is another one that depends on your security policy. If it’s sensitive data it needs to be encrypted. It doesn’t necessarily need to be firewalled, but it depends on how much you trust your L3VPN vendor.
i.e. L3VPN and IPSEC VPN both “meet” at the same point and share routing across tunnels?
I’d say: Your Site-to-Site VPN hub router should be connected to the core of your network or WAN distribution. It shouldn’t have a local connection to the internet (everything from the outside destined for it should have to pass through your main firewalls)
As for L3VPN, it’s meant to be treated as an extension of your routed network, so you’d put your CE devices off the Core or WAN distribution. If you are worried about privacy, you could always run DMVPN or some variant on top of it.
There are quite a few opinions on this, I’ll tell you how we do it.
We leverage cheap, flexible, easy devices to terminate the IPSEC tunnels. For us, that is Cisco ASR 100X. We use separate ASRs for corporate S2S terminations and B2B partner terminations.
The firewall that sits between the ASR and the internet has 4 DMZs. There is the dirty Internet, the Dirty DMZ, the Clean DMZ and the Internal Network.
The dirty internet has routable IP space and the Dirty DMZ has routable IP space. Clean DMZ and Internal Networks are RFC1918. The Cisco ASR IPSEC termination has two interfaces, one in the Dirty DMZ and one in the Clean DMZ.
Firewall rules allow IPSEC, IKE, ICMP and whatever else is needed for IPSEC to talk to the dirty DMZ IP address of the Cisco ASRs. The Clean DMZ rules allow whatever is needed. If it’s Corporate remote offices, it’s pretty much wide open. If it’s B2B partners, it’s pretty much least access.
All threat protection scanning is done on traffic between the Clean DMZ and the Internal LAN, as discussed elsewhere, no need to scan the IPSEC traffic.
We do not terminate IPSEC on the firewalls themselves because IPSEC encrypt/decrypt overhead weighs heavy on the firewalls and cause CPU issues, moving the IPSEC termination to a discreet device is the only way in our environment.
Going to echo most others. I would (and have) terminated the VPNs at the edge say on an ASA, then filter IPS/IDS on a separate physical FW device inside of that.
I don’t worry too much about stuff hitting the edge vpn peer firewall as it is a firewall and should be more than capable of handling its own on the internet and blocking traffic it doesn’t want.
That’s absolutely what you want to do. Assuming each of these functions is on it’s own box, you’d decrypt (so that you have something you can filter accurately), then do your cheap filtering, then your more expensive filtering / analysis.
They make sure only tunnel traffic (ike and esp) from the branch public ip is permitted. You don’t want to have external internet traffic of any kind penetrate your network without going through a firewall
I wonder where did this myth that MPLS offers encryption came from. Totally don’t understand the assumption that people thought MPLS connections were encrypted.
Same for previous ISP I worked for. People wanting encryption within the MPLS core were often the same people asking whether their “traffic was being carried over the internetz” because they observed public IP’s in a traceroute (we didn’t disable TTL propagation).
These same people didn’t want to pay extra for this. Nor could they actually explain what unencrypted traffic between CE’s they were looking to protect. Probably all that HTTPS.
Because the original service offering was “MPLS L3 VPN.” VPN just means virtual private network, it doesn’t mean encryption. A VPN can be as simple as a VLAN, it virtually separates traffic that shares the same physical network.
But VPN=encryption in a lot of people’s minds so I’m not surprised people think that’s what it is even though MPLS is just routing/switching segregation…VRFs and MPLS tags on a service provider network.