Point in network for S2S VPN Concentrator

VPN
1

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?

2

You still restrict traffic on the concentrator. Every VPN concentrator is going to at least allow ACLs, many also support IPS and are just firewalls that terminate VPNs.

3

I’ve done this design before.

​

We had:

Internet Edge Router ↔ Edge Firewall ↔ VPN Concentrator ↔ DMZ Firewall ↔ Core Network

​

It works, just have to add new rules on the edge to allow IKE and IPSEC to new branches and normal traffic rules on the DMZ firewall.

4

Most common design I’ve seen is VPNC outside interface on one screened subnet DMZ, VPNC inside interface on a different screened subnet DMZ on the same firewall. Alternatives have been VPNC inside interface in a sandwich DMZ between outside and inside firewalls of different vendors, and VPNC outside interface directly connected to the Internet router.

As long as you have done a risk assessment and can prove your assets are being protected by an appropriately monitored and managed set of devices, most auditors should be happy.

5

I’d have no qualms about allowing the VPN concentrator “protect” its own outside interface. It should be more than capable of dropping any traffic except what you’d have to permit in any other firewall anyway.

As for the inside interface, there’s no reason you can’t filter traffic headed to/from the VPN there. I’d probably prefer to do that filtering on the WAN firewall itself, just for ease of management/configuration, but it wouldn’t be a big deal for me either way. What to filter and which device to use for filtering are two distinct questions, and the one need not determine the other in a case like this.

6

It’s all about policy and weighing up what makes sense for you.

I wouldn’t bother putting the encrypted traffic through the firewall though. Waste of resources, FW can’t see inside it.

I would however also not put a default route on the VPN concentrator, rather only specifics for my remote sites, so that it can’t potentially communicate with anything “on the internet” apart from my own locations. Obviously depending on the size & scope of your network, and level of automation, this may be easier / harder to achieve.

7

We have the inside of the VPN connected to a zone on our Palo Alto firewall. While the VPN concentrator establishes the tunnel and uses acls for establishing the encryption domain, the PA is where we actually do policy enforcement. Works great and gives us granular control over whats allowed.

8

You are exactly correct (in observation and in fear) which is exactly why my company has been redesigning its branch office connectivity for the last 3 months, to be able to defend against a scenario just like you described.

Good luck!

9

As our entire network is L3 it does not really work that way, not for us, we do not have an “inside” we have 27 or so. So our VPN tunnels have to terminate into different VRFs and security zoned depending on the use case. In fact we normally create a DMZ just for the S2S as it’s essentially an untrusted external connectivity. We even places routes we receive over WAN from other sites in VRFs.

10

A proper security design would be to stick it in a DMZ and only allow traffic in through an edge firewall.

However, VPN concentrators are generally also firewalls, so if you want, you could put it in parallel with your edge firewall if you trust the filtering capabilities of the device.

It all depends on your design and your compliance requirements.

11

Maybe makes more sense for the larger organizations that stand up 100’s of VPNs. Maybe large scale DR sites like Iron Mountain, although mostly I’m only aware of people standing up their own equipment there and not using hosted solutions.

12

My data center fortigates do the job of 4 boxes we used to have: edge router, firewall, web filter, & VPN. But we normally only have a few people connected via VPN at the same time.

13

This is the design we’re going for in our new setup that we’re building out.

14

Yeah, that’s the only way I’ve seen it as well. Probably not infinitely scalable, but in all the situations I’ve seen, it worked great and avoided the problem OP describes.

15

I’d guess that the dedicated VPN concentrator is largely unnecessary nowadays. More CPU power and dedicated ASICs mean that your edge firewall can handle the termination duties and firewall/IPS/IDS functions in the vast majority situations… That wasn’t always the case. I remember crushing the CPU of an ASA 5500 ~10 years ago when we tried to consolidate the two functions. The next recap cycle we were able to without issue.

16

~1500 S2S tunnels on a Fortinet 500D as router/UTM firewall/VPN. Works great and sits at 10-20% cpu and 45% memory when pushing 2Gb/s of throughput. I kinda figured VPN concentrators were for MUCH larger organizations/implementations (10k+ tunnels) or were a thing of the past at this point…

17

Wow, thats awesome. I’m only running maybe 80 on an ASA5585.

18

So your tunnels use on average 1,3Mbit/s

19

It varies by site but yes most of the tunnels are low bandwidth. Total throughput averages 5-8TB a week across all the tunnels combined. Many are redundant tunnels where nearly no traffic is passed until traffic is routed over it. This is for ~900 sites.