Sunday, July 14, 2019

Point in network for S2S VPN Concentrator

I have seen a lot of network designs where S2S VPN Concentrators will sit “parallel” to the firewall, where it will have an “outside” interface in the “external segment” of the edge (same segment where the firewall “outside” port will sit,) and an “inside” interface on the full trust internal segment, like right to a distribution switch hanging off the core.

In this way the encrypted VPN traffic traverses directly between external router and VPN Concentrator, bypassing the firewall completely, and the decrypted traffic from the distant end of the tunnels is just dumped on the trust zone directly to the core.

Like I said, I’ve seen many such designs just like this: both in practice, as well as in the texts.

The logic is that VPN’s protect Confidentiality, Integrity, and Authenticates peers. For this reason the traffic is going from a Trusted zone to a Trusted zone, so no firewall inspection is necessary. All that’s necessary is restricting traffic to that “outside port” on the VPN Concentrator to only the appropriate ports and protocols of whatever IPSEC Suite you’re using.

One fear of mine, is this potentially exposes your datacenter to malicious traffic, if a branch got infected, so wouldn’t you rather terminate the “inside port” of the VPN Concentrator to a DMZ zone that has to traverse the firewall. One design consideration here, is how do you prevent spoke to spoke hairpinning from happening on the Concentrator, but rather force spoke-to-spoke traffic out that interface and to the firewall for inspection. Even if that traffic may hairpin on the firewall, but that would be acceptable.

Another step further would be “outside” and “inside” alike going to a DMZ, so both the encrypted tunnel traffic, and decrypted traffic is made to traverse the firewall. This would ultimately be the safest bet, so the VPN Concentrator is not exposed directly to the Internet, which makes it a potential critical vulnerability to accessing the network. After all, if compromised, it has an interface directly on the internal trust segment, granting unfettered access.

Clearly this discussion pertains to the single tenant enterprise environment, whereas cloud hosts have their own proprietary way of conducting business.

What are your thoughts? How would you deploy this, how have you seen it deployed, and what would auditors say about each methodology?



No comments:

Post a Comment