I am in the process of planning to implement Direct Access on Windows Server 2012 R2.
I'm currently planning to use a single network adapter behind an edge firewall (NAT).

I see in the DA configuration wizard that you can also deploy VPN at the same time so I assume it is supported.

1. What I am unsure of is can I do this on my planned server configuration of one nic behind a NAT firewall?
2. Can it use the same IP address as Direct Access or will a separate one be required?
3. PPTP is not recommended due to security vulnerability but which is the better choice in this case L2TP or SSTP (clients are Windows 7)?
4. We will be creating an external dns record (da.companyname.com) for our direct access. Will it conflict with the VPN and will it require it's own external facing DNS record and issued certificate?

Appreciate any advice. Thank you.

• Edited by Barkley Bees Wednesday, February 04, 2015 11:12 PM

Although this is possible you would not want to do it :)

If you have DA behind NAT it can only use IP-HTTPS and because it's a TCP protocol the performance is terrible. This is because TCP handshakes and you suffer a double encryption penalty, (which is apparently not an issue in 8/8.1)

http://directaccess.richardhicks.com/2014/06/24/directaccess-ip-https-null-encryption-and-sstp-vpn/

"However, null encryption for IP-HTTPS is no longer available in the scenario where client-based remote access VPN is configured on the same server as DirectAccess."

If have quoted this blog post from Richard Hicks many times, I unfortunately learned the hard way before there was a post available.

Ryan Betts

blog.ryanbetts.co.uk

• Edited by Ryan Betts 92 Thursday, February 05, 2015 11:05 AM

Thank you for your reply. How have you found performance to be impacted? Is it network performance for connecting client PC's or overhead on the DA/VPN server itself (CPU?)? What number of concurrent connecting clients do you have when performance becomes poor?

I have read from others that the while there is performance hit it is not unacceptable. This has me rather concerned now though.

• Edited by Barkley Bees Friday, February 06, 2015 7:12 PM

I have to disagree a little bit :)

Rich's post is true and when you enable VPN on a DirectAccess server it does force all of the IP-HTTPS connections to be doubly encrypted, which does cause slowness. But, once you start using DirectAccess you'll find that the majority of your connections would probably be IP-HTTPS anyway. Having Teredo enabled is always something that I shoot for in any installation, but it's not always possible. You need to have public IP addresses on the External NIC of the DirectAccess server (this implies you need to run two-NIC mode - which I absolutely recommend anyway - I've had too many bad experiences with single-NIC mode to ever recommend it for a production environment). As soon as you NAT traffic coming into a DA server, Teredo is off the table. Also, most people turn on DA by using the Getting Started Wizard, which also disables Teredo. Even in cases where Teredo is available on the DA server side, anytime that the client is sitting on an ISP connection that blocks UDP, which is the case more and more with port restricting routers being installed into hotels and coffee shops and everywhere, Teredo isn't going to be able to connect in that situation anyway and the client will fall back onto using IP-HTTPS. I only make these points to show that most DA installs are running IP-HTTPS only, and the speed is not unusable.

When you compare Teredo and IP-HTTPS side by side, yes Teredo is faster on the client side. But speed of DA, as with any VPN, matters quite a bit on the client's internet connection. A slow internet connection is going to equate to a slow DA connection, no matter what transition protocol is carrying their IPsec tunnels.

I know many companies who use combination DA/VPN servers for their only remote access solution, and are very happy with it, both Windows 7 and Windows 8, usually a combination of the two.

Just wanted to chime in from my own experiences of this. As Jordan pointed out, Teredo becomes problematic in support/manageabilty scenarios because of transit providers (e.g. ISPs/Mobile Networks) blocking UDP. Inevitably, I end up defaulting to IP-HTTPS because it's the only transition protocol that flat out works. IP-HTTPS only becomes a hindrance when you're dealing with a combination of poor network performance (throughput/latency), protocols designed for the LAN (earlier versions of SMB/proprietary client/server etc) being accessed via the DA client and use cases that excerbate those constraints, e.g. large file transfers. In other words, there are numerous factors in play that can hinder performance and use of IP-HTTPS should be viewed in light of what is .. double encryption giving a moderate tax hit on performance. Having said that, there are a number of other issues that come into play with dealing with larger rollouts: concurrency, support for different Windows versions, their functionality and how DA scales out . I suspect that's something Ryan was to

Yeah I actually have read your book Jordan and thought it was great, but I have seen the same issues across multiple different clients and now advise to stay clear of DA.........