A couple of times in the past month I’ve been asked where a SSL VPN appliance should be deployed in relation to the firewall. In both cases it was relating to the Juniper Secure Access / MAG platform, but best practice should apply equally to any IPSEC or SSL VPN platform, so I thought it would be interesting to walk through the options.
Without doubt, VPN devices belong behind a firewall. All the Enterprise grade devices I’ve ever worked with are hardened appliances, but they are designed to live behind a firewall. You will need to enforce access control to the administration interface, let alone filter out obscure features/protocols such as SMTPS support. Buy a firewall. Even a cheap one.
One Leg (DMZ)
As a minimum one should have one network interface (leg) connected to a De-Militarised Zone (DMZ). The VPN protocols will be permitted through the firewall, probably via a static NAT. Firewall rules will also need to permit access to the LAN from the DMZ. The one legged approach is simple to deploy and doesn’t require any fancy firewall policy. In this scenario often the VPN appliance will share it’s DMZ with other services, such as mail relays (people still have those, right?).
From a security perspective this is not a great solution. Mixing Clean and Dirty network traffic on the same interface is generally frowned upon; should the appliance become compromised or the firewall subjected to a successful spoofing attack, an external threat actor would be on the LAN very easily. These things are all bad in a theoretical security kind of way, but I’ve never seen them enacted in 10+ years of VPNs.
Two Leg (DMZ-LAN)
The Two Leg design is very popular in Enterprise networks. In this scenario, Dirty Internet traffic is terminated on an external interface which only deals with encrypted traffic. Some appliances (such as the Juniper SA/MAG) have a dedicated interface with protocol hardening. Port-scan it and you’ll probably get some really weird results. Once connections have been terminated and authenticated on the external interface, internal proxies re-establish the connections from the internal interface. This creates two (or more) distinct routing tables on the appliance. Anything received on the external interface is routed back out the way it came, and a separate gateway of last resort is configured on the internal interface. This often creates two sorts of confusion;
What happens when a remote client tries to communicate with something on the external DMZ (such as a web server)? Once the connection has been decapsulated, the VPN appliance forwards it the internal interface, picking up whichever route is configured. It’s entirely possible the connection will be forwarded back into the network core before eventually being blocked by a perimeter firewall. For this reason, it’s recommended that dedicated DMZs are used; there is no good reason why a de-encapsulated session should try to reach the private, external DMZ address space.
What happens when the user needs to surf the web via a VPN with split-horizon disabled? Again, the internal side firewall will probably dump the connection. As a result, you either need to permit the internal address space (and DHCP scope) outbound access to Internet, or more sensibly, use VPN client features to forward the client to an internal proxy server.
This provides better security than the single legged approach, but is still not ideal. In most cases, the internal interface is terminated on a dedicated VLAN segment somewhere near the LAN core. This makes routing nice and tidy, but doesn’t really help when a good user does something bad, as they will probably have direct access to the entire network. The counter-consideration is that the VPN device has much more state information about the user than a regular Layer 4 firewall, especially if host-checking features are enabled.
Anecdotally, this approach provides the best performance as there is (probably) no firewall getting in the way once the tunnel is established. I’ve noticed this with applications such as Outlook Web Access that create a tonne of short-lived HTTP connections which the firewall has to deal with before page can finish rendering.
On paper, the most secure option is to use a double-DMZ approach. Both the internal and external interfaces are connected to dedicated DMZs, ideally on physically separate firewalls. Theoretically, this makes for the most secure design but for practical reasons it is rarely seen outside of Financial services (who have lots money) and Government (who don’t have a lot of sense). Traffic is traffic is inspected twice, once at the edge (except it can’t because it’s encrypted) and again once it’s been decapsulated (but without any meaningful user context). This is a problem. It’s not unusual for gateways to support 1000’s of concurrent users, all of which may be doing very different and apparently insecure things. In my experience, 2nd leg firewall rule bases tend to be Any-Any-Accept. They are unable to meaningfully differentiate between users or groups. A firewall with an Any-Any-Accept policy is just a really expensive router that generates lots of non-user specific logs; it achieves very little.
One Point Five Legs (DMZ-IDS)
The best compromise between security and operational efficiency is to use a combination of techniques. An external firewall is clearly a must, and the on-LAN access is incredibly convenient, but the best way to improve security is to add a separate layer of intrusion detection on the Internal leg of VPN appliance. This removes the need to create meaningless firewall policies and allows you to block only what is expressly denied (i.e. bad stuff) without creating an operational overhead. Decapsulated traffic gets a final inspection before it actually hits the LAN, mitigating the good user doing bad things scenario. However, even this scenario is not without caveats. IDS/IPS systems are significantly more expensive per Mbps than regular firewalling. Furthermore, unless they are properly tuned and regularly maintained they can be a regular pain in the butt. That said, clever systems (read: Juniper Secure Access and their IDP product (PDF)) can actually talk to each other; they can share state information. If a user does something bad, that user can be kicked off or more helpfully, sent into remediation without impacting any other users, even on the same address.
My view is that if you are really concerned about what is coming into your network, your best opportunity is to scrub the connections at the edge before they get anywhere near the LAN. One can either thoroughly analyse the endpoint to ensure that it is healthy (i.e. patched) or more likely, adopt the thin client/VDI approach and prevent the endpoint from connecting directly to the LAN. The former impacts the user experience as it is time intensive, the latter costs more money and is more work for the administrator. Combining these techniques (and I’ve seen it done) will give you a high level of assurance of inbound connections, but are likely to be extremely unpopular with the users. This should be avoided as it often spawns dark VPNs; users finding their own (terrifying) solutions to corporate remote access. And no-one wants that.
Visio Symbols courtesy of: http://www.endless.net.au/