Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 21925 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.

Reply Children
No Data
Unfiltered HTML