Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 22343 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Microsoft DirectAccess and WAF

zontor

Greetings,

I'm trying to configure DirectAccess to work with WAF. I currently got it to work with setting up a Full NAT but reading various forum posts on here suggest this approach is not ideal. I have been Googling and making changes such as #3 in the Rulz but have not had much success.

Using WAF, I can use a web browser and hit the domain and traffic is logged as intended. When a DirectAccess client attempts to hit the same domain, it never connects and no traffic is logged. I have looked through logs DNS proxy, Application Control, Firewall, IPS, WAF, and web filtering but can't seem to find where this traffic is being logged. Using Wirehark, I see the Client Hello with protocol TLSv1.2 but the server replies with '61 Alert (Level: Fatal, Description: Handshake Failure)' with protocol TLSv1.2.

I'm not sure if under the hood something else is occurring of the DirectAccess client that WAF doesn't support or vice versa that is causing the handshake to fail. Regarding the RealConfig screenshot, I tried setting the real server to use HTTPS but read a post setting to HTTP would lower the strain on the server.

Now if I disable WAF, and enable the Full NAT, I see the traffic come in through the Firewall log. Wireshark sees the client hello and the server responds with the server hello and certificate.

Not sure if what I want to accomplish is even possible or supported but I want my internal web server shielded from external traffic so it seems I should go down this route. Any assistance would be greatly appreciated.

Josh



This thread was automatically locked due to age.
Parents
  • 0

    WAF only handles http or https over one specific port.  It also has trouble with Citrix ICA which is nonHTML data in an https session.  My guess is that this Microsoft product uses an odd protocol or a primary and a secondary session on different ports.  If that gues is correct, WAF will not be your answer.

  • 0 in reply to DouglasFoster

    DouglasFoster said:

    WAF only handles http or https over one specific port.  It also has trouble with Citrix ICA which is nonHTML data in an https session.  My guess is that this Microsoft product uses an odd protocol or a primary and a secondary session on different ports.  If that gues is correct, WAF will not be your answer.

     

    Well that sucks. Thanks for the response. I think you may be right in that it may be using nonHTML data in an https session. DirectAccess is a 'always-on' VPN solution that only connects on port 443. That may be why browsing to the domain through a browser works but using DirectAccess fails at the SSL handshake. Looking through https://docs.microsoft.com/en-us/windows-server/remote/remote-access/directaccess/tlg-cluster-nlb/step-6-test-directaccess-client-connectivity-from-behind-a-nat-device it states IP-HTTPS connection will fail if the proxy requires authentication or if the web proxy performs outbound SSL inspection. AFAIK I dont have these options enabled.

    Since I'm only allowing 443 traffic to this server, other hardening techniques on the host itself should still be applied correct? Any other traffic directed at the host is dropped.

  • 0 in reply to zontor

    Suggest you move back from the technology and look for the business function.

    1) All remote access should use two-factor authentication.   PCI DSS requires it, and abundant evidence confirms it.   UTM provides that capability.  Does Microsoft have a two-factor solution baked into their technology, or do you have to add it in.

    2) UTM SSL VPN requires (a) a download to a chosen PC, and supports 2-factor authentication.   So it is really a form of three-factor, especially if you keep the download awy from the user portal and require that it be installed by I/T from the WebAdmin screen.   (Alternatively, only enabled it for a short window while the user does self-install.   Then you can control available IP addresses with VPN profiles, and tune them further using firewall rules based on user ID.   You also have automatic break-in evasion.   Can you assemble all of these pieces at no-extra-cost with any other remote client VPN technology?

    2) If at all possible, avoid VPN completely.  HTML5 VPN to RDPO is a great alternative to Go-to-my-pc, but with 2-factor authentication and without dependence on a third-party server in the cloud.

  • 0 in reply to DouglasFoster

    Thank you for your assistance. We have decided to use the Full NAT configuration and adjust security as needed for now.

  • 0 in reply to DouglasFoster

    I had a brief look at DirectAccess after this thread was started. Seems it uses a dual tunnel approach.

    The first tunnel is always connected and serves for it admin purposes only eg updates, gpo etc so that when the client is turned on, now matter where it is, it is updated.

    The second tunnel only comes up when the user authenticates and is used for all the other stuff eg file transfer etc.

    The advantage this has is that it is not reliant upon the user bringing/or not bringing a vpn up as the minute it is turned on its looking for GPO's, updates etc

    I suppose if you couple it with bitlocker, locked down policies etc, it may be a fairly secure way of doing things and may alleviate vpn client overheads.

    That being said, there is always the fear of exposing an M$ product directly to the internet

  • 0 in reply to DouglasFoster

    Great suggestions, Doug.  The caveat with the HTML5 method is that it is very compute-intensive for the UTM and should only be used for a few individuals to have occasional access.  Having several active sessions at once will bring most "correctly-sized" UTMs to their knees.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Great warning about Html5 Rdp. Any reason to hope that CPU load is improved in v9.5?

  • 0 in reply to DouglasFoster

    I bet not, Doug.  I've seen more than one Sophos person say that it's meant primarily for use by a few occasional accesses.  Say a Windows server specialist or an Apache guru.  For regular, broad use, I prefer SSL VPN configured to use UDP.  As you point out, it's possible to use triple-factor auth with that - a belt and two suspenders.[:D]

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    We are looking to implement DirectAccess due to the lack of user involvement. I've had a good read of it and it's a fairly secure system using certificates and entries in AD.

    It can also use OTP, Radius for authentication.

    Coupled with WAF, it would be fairly secure I think.

    So our plan is:
    WAF > Outside DMZ > Direct Access Server > Inside DMZ > Corporate Network

    You only need to expose TCP 443 so it's basically like the Microsoft RDS Gateway and fairly secure.

Reply
  • 0 in reply to BAlfson

    We are looking to implement DirectAccess due to the lack of user involvement. I've had a good read of it and it's a fairly secure system using certificates and entries in AD.

    It can also use OTP, Radius for authentication.

    Coupled with WAF, it would be fairly secure I think.

    So our plan is:
    WAF > Outside DMZ > Direct Access Server > Inside DMZ > Corporate Network

    You only need to expose TCP 443 so it's basically like the Microsoft RDS Gateway and fairly secure.

Children
Unfiltered HTML