none
Windows Server 2012 DirectAccess behind NAT

    Question

  • Hello,

    I am trying to configure DirectAccess on Windows Server 2012 in conjunction with TMG 2010. I have only one public IP. Windows Server 2012 now supports DirectAccess with a single IP and behind a NAT. My configuration works correctly if I directly forward port 443 from the router to the DA server. However, I also need to access Exchange OWA on port 443. I read here (http://social.technet.microsoft.com/Forums/en-US/Forefrontedgegeneral/thread/1e176b77-6c4b-4bd7-8746-4b1fe95459d9) that it is possible using a server publishing rule in TMG. However, that results in the following error as there is an HTTPS listener already active for publishing Exchange Server websites:

    "Server publishing rule [%1] that maps %2%3 to %4 for protocol [%5] was unable to bind a socket for the server. The server publishing rule cannot be applied."

    Is it possible to publish DA services using TMG 2010 along with Exchange? If not, is there a way to change the port on which DA is listening to something else other than 443 (e.g. 8443)? Any help would be appreciated.

    Thanks,
    Arun


    • Edited by Arun_2144 Wednesday, September 26, 2012 2:19 AM Typo
    Tuesday, September 25, 2012 2:00 AM

Answers

  • Hi,
    No you can not run Exchange and IPHTTPS on the same external IP address and on port 443.

    Regarding your question about using a different port.
    Doing that would most likely work BUT one of the reasons that 443 is used is because it is often allowed out from internal networks.
    And another thing is that your setup would most likely be in an unsupported state if you would ever need to start a supportcase for some reason.

    If you would like to try it though, my suggestion would be to do a portforward from 8433 on the external IP to 443 on your DA server.
    Then you need to manually modify the client GPO to change the portnumber for the IPHTTPS interface
    That way you could revert the GPO settings back to the standard port if you need to involve microsoft support for something.

    Best wishes,
    Jonas Blom

     


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Proposed as answer by Jonas Blom Tuesday, September 25, 2012 8:52 AM
    • Marked as answer by Arun_2144 Tuesday, September 25, 2012 9:40 AM
    Tuesday, September 25, 2012 5:50 AM
  • Hi again,

    You need to open up the client GPO on a machine that has the admx files that comes with Windows Server 2012.
    Then you will be able to modify the setting below and specify alternative URL.
    (The below screenshot is from the DA server that has the admx files in the local store, no global store is configured)

    But like I tried to point out in the previous post, I would recommend against setting alternative ports for a permanent solution!

     


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Proposed as answer by Jonas Blom Tuesday, September 25, 2012 8:53 AM
    • Marked as answer by Arun_2144 Tuesday, September 25, 2012 9:40 AM
    • Unmarked as answer by Arun_2144 Tuesday, September 25, 2012 11:59 PM
    • Marked as answer by Arun_2144 Wednesday, September 26, 2012 2:19 AM
    Tuesday, September 25, 2012 8:52 AM

All replies

  • Hi,
    No you can not run Exchange and IPHTTPS on the same external IP address and on port 443.

    Regarding your question about using a different port.
    Doing that would most likely work BUT one of the reasons that 443 is used is because it is often allowed out from internal networks.
    And another thing is that your setup would most likely be in an unsupported state if you would ever need to start a supportcase for some reason.

    If you would like to try it though, my suggestion would be to do a portforward from 8433 on the external IP to 443 on your DA server.
    Then you need to manually modify the client GPO to change the portnumber for the IPHTTPS interface
    That way you could revert the GPO settings back to the standard port if you need to involve microsoft support for something.

    Best wishes,
    Jonas Blom

     


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Proposed as answer by Jonas Blom Tuesday, September 25, 2012 8:52 AM
    • Marked as answer by Arun_2144 Tuesday, September 25, 2012 9:40 AM
    Tuesday, September 25, 2012 5:50 AM
  • Thank you Jonas. I want to try your suggestion. Where would I find the setting to change the port number for IP-HTTPS in the client GPO? I looked under Computer Configuration > Policies > Administrative Templates > Network > DirectAccess Client Experience Settings.

    Thanks,
    Arun


    Arun

    Tuesday, September 25, 2012 8:04 AM
  • Hi again,

    You need to open up the client GPO on a machine that has the admx files that comes with Windows Server 2012.
    Then you will be able to modify the setting below and specify alternative URL.
    (The below screenshot is from the DA server that has the admx files in the local store, no global store is configured)

    But like I tried to point out in the previous post, I would recommend against setting alternative ports for a permanent solution!

     


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Proposed as answer by Jonas Blom Tuesday, September 25, 2012 8:53 AM
    • Marked as answer by Arun_2144 Tuesday, September 25, 2012 9:40 AM
    • Unmarked as answer by Arun_2144 Tuesday, September 25, 2012 11:59 PM
    • Marked as answer by Arun_2144 Wednesday, September 26, 2012 2:19 AM
    Tuesday, September 25, 2012 8:52 AM
  • Thanks again Jonas! I agree it's not a permanent solution, but it works as described with the alternate port.

    I really appreciate your help!


    Arun

    Tuesday, September 25, 2012 9:40 AM
  • After trying the GPO settings that you mentioned, I reported that this had solved my problem. However, after a short while the problem resurfaced.

    It seems that both ports 443 and 8443 need to be forwarded in order for DA to work. When I forward port 8443 alone to the DA server, the connection fails and I get the message "Attempting to reach network resources. Contact your admin for help if this message persists."

    I noticed if there is an active DA session, it can reconnect only if port 8443 is forwarded. I assume that this is why it initially seemed to work (the sessions were already established).  Therefore, it cannot create a new DA session when only 8443 is forwarded.  Forwarding port 443 alone to the DA server also does not create a connection. It fails on the step "Your PC is attempting to contact the DirectAccess server. Contact your admin for help if this message persists." 

    I assume that there is some setting (possibly on the client side after the initial connection has been made and before the session is created) that is still dependent on port 443. It appears that it can make a connection to the DA server, but after that something fails. Could you please assist me with this issue?

    Arun

    • Proposed as answer by Eyal Malach Wednesday, April 03, 2013 10:13 AM
    Wednesday, September 26, 2012 12:03 AM
  • Hi again,

    Sorry to hear that it only worked partially.
    My guess is that the webserver does some kind of redirect and in that redirection it uses the FQDN along with 443, which is understandable since the serverside thinks it uses 443.

    Based on your findings I would say that the answer is "No, you cannot run it on another port than 443".

    If you really wanted to do the change from 433 to 8433 on the serverside also, you would need to alter a lot of components (IIS, GPO).
    And most likely, all these settings would be reset when you perform some change and need to reapply the config (like adding new entries to the NRPT)

    If you do some more digging into it I would be interested to hear of your results, otherwise I'll add this setup to the list of various setups to test and understand myself :)

    Best wishes,
    Jonas Blom


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    Wednesday, September 26, 2012 5:35 AM
  • Hi Jonas,

    Thanks for your reply. I will also keep trying and post anything I find. I initially suspected it could be a firewall issue (on the client side); however, since the setup does work correctly if a session is disconnected and reconnected (even if port 443 is closed), it is probably some issue on the server side. I'm not sure if this would help, but I ran the DA logs on the client and got the following DA statuses:

    when connected properly: Connected Remotely: Connected to the network through DirectAccess.

    when unable to connect (i.e. port 8443 only is forwarded and it has been some time since the DA connection has been disconnected): Error: Corporate connectivity is not working. Windows is unable to contact some remote resources due to network authentication failures.

    It could be that a resource verifier might not be working and that may depend on the original URL (FQDN with 443). Still, it can connect, as I mentioned, if a session has been established and disconnect within a certain timeframe (~15 mins). If port 443 is closed any point after the initial connection, it will work. I am not too sure of the actual events that take place during the DA connection process.

    Thanks for your help on the issue and please let me know if you come across anything that might help.


    Arun

    Wednesday, September 26, 2012 7:24 AM
  • Hi again,
    When you get the error, can you see any information regarding what entrypoints it is that does not work?

    I would suggest that you ignore the information listed there and focus on the following tests:

    1) Can you do a dns lookup for an internal server (Start with flushing the dns cache with ipconfig /flushdns so you are sure it doesn't read from the cache)

    2) Can you browse an internal fileshare or access an internal website (not the NLS)?


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    Wednesday, September 26, 2012 8:26 AM
  • Hi,

    When verifying corporate connectivity it is looking for the URL HTTP:http://directaccess-WebProbeHost.domain.local. If I set this to some external domain e.g. microsoft.com, then the DA connection shows as connected. However, I cannot browse to any internal file shares or websites.

    It does seem to be some kind of authentication that is passed on 443, but I am unable to pinpoint where that setting is located. Incidentally, a session does appear in the Remote Access console on the DA server (Remote Client Status), but there is no username associated with the session.

    Regarding the tests you suggested:

    1. I can successfully ping any internal server. The IP addresses are resolved to IPv6 addresses for all.

    2. I cannot browse to any internal file shares (using either host names, IPv4, or IPv6). Same for internal websites.

    Thanks


    Arun

    Wednesday, September 26, 2012 8:47 AM
  • Hi

    May I ask how exactly you set up the TMG rule(s)?

    I tried publish 443 - but I get this:

    PS J:\> Get-DAConnectionStatus

    Status    : Error
    Substatus : CouldNotContactDirectAccessServer

    When connected to internal LAN I get Substatus: Connected Internally..

    Thanks.

    Wednesday, September 26, 2012 11:41 AM
  • Hi

    I actually avoided TMG altogether and forwarded the port(s) directly from my router. Trying to publish through TMG was giving all kinds of errors like the one I mentioned above.

    Hope that clarifies.


    Arun

    Wednesday, September 26, 2012 1:51 PM
  • Arun: based on the fact that you can reach the dnsserver on the DA host but not reach the internal systems I would say that something strange is happening  with the IPsec rules and that they are unable to establish.

    But how this would be connected to what port the iphttps tunnel is established over is another matter.

    Would be interesting to see a capture from when the IPHTTPS tunnel is established (while doing a MITM on the HTTPS connection)


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    Wednesday, September 26, 2012 6:35 PM
  • I also thought it might have to do with the Kerberos authentication over 443 so I thought of implementing with certificates instead.

    I would post a capture from when the tunnel is established, but I am not sure how to obtain it. Is there a specific tool used to obtain the capture while doing a MITM on the connection? Could you let me know how to go about getting the capture?

    It definitely would be interesting to determine what traffic is flowing on 443 even though the tunnel is established over 8443.

    Thanks,


    Arun

    Wednesday, September 26, 2012 9:59 PM
  • I tried it again and am now receiving the following error:

    Error: Corporate connectivity is not working. Windows is unable to resolve DNS names for probes.

    In addition, I am unable to ping any internal servers as I was able to yesterday. However, I still feel that it has to do with user authentication passed on 443. A machine session (with the correct machine name) does still appear on the DA server when a connection is attempted.

    On one occasion, I received the message: "Your LAN proxy credentials are needed" even though there are no proxy servers on the LAN (other than I suppose the NLS).


    Arun

    Thursday, September 27, 2012 5:17 AM
  • Thanks - I'm not able to avoid TMG - just have to keep trying I guess.. :)
    Thursday, September 27, 2012 8:56 AM
  • Arun:
    Can you try and switch your setup so it uses machine certificates for authentication instead of kerberos proxying?

    //Jonas


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    Thursday, September 27, 2012 11:58 AM
  • Hi Jonas,

    Using machine certificates for authentication seems to result in the same situation (works with 443/8443 both forwarded, does not with just 8443). I also noticed it could not resolve DNS names. Just to clarify, I made the setting change on this screen: "Remote Access Setup" > "Authentication". I changed it from Active Directory Credentials to Two Factor Authentication.

    Thanks,


    Arun


    • Edited by Arun_2144 Thursday, September 27, 2012 6:08 PM
    Thursday, September 27, 2012 6:03 PM
  • Hi

    I actually avoided TMG altogether and forwarded the port(s) directly from my router. Trying to publish through TMG was giving all kinds of errors like the one I mentioned above.

    Hope that clarifies.


    Arun

    Pardon me for jumping in here, and be aware that I am by no means a DirectAccess expert but I have a similar setup as your and just finished setting up 2012 DirectAccess behind a NAT device (Cisco Small Business Router). I originally had 443 forwarded to my Exchange Server for OWA as well and when I cam across this thread, I thought that I was going to run into the same problem. I decided to go ahead and change the port forwarding rule to point to my DA server, get it all working, and then deal with the 443 conflict after I had DA up and working.

    DA was a breeze to get working with a Windows 8 client (had to do a bit more work to get a Windows 7 client connected but this blog entry got me fixed up there as well). Once I had it setup and without making any changes in the port forwarding rules, I decided to try OWA to see what errors were going to be thrown, and none were. OWA opened right up, which, if you can access OWA while connected to your internal network makes sense, after all it is just another internal resource and if you've got DA configured and working for clients coming from the Internet, there's no reason to have a special port forward rule for OWA over 443, DA will take care of the redirect for you!

    So, the bottom line here is, unless I'm missing something, I think you're over thinking this. If you get DA working properly, you should no longer need the port foward for OWA.

    Hope this helps.

    Paul

    Sunday, November 04, 2012 11:54 AM
  • Surly this would break active sync on mobiles
    Sunday, November 04, 2012 9:15 PM
  • On Sun, 4 Nov 2012 21:15:33 +0000, uk_andy wrote:

    Surly this would break active sync on mobiles

    Also works with no problems.


    Paul Adare
    MVP - Forefront Identity Manager
    http://www.identit.ca
    Vacuum type: A derogatory term.  See "bubble memory."

    Sunday, November 04, 2012 9:43 PM
  • On Sun, 4 Nov 2012 21:43:11 +0000, Paul Adare wrote:

    On Sun, 4 Nov 2012 21:15:33 +0000, uk_andy wrote:

    Surly this would break active sync on mobiles

    Also works with no problems.

    Sorry, but I gapped a bit here. I'd forgotten that I'm actually doing synch
    through a UAG server I have on my network and obviously not through DA :-)


    Paul Adare
    MVP - Forefront Identity Manager
    http://www.identit.ca
    1 bull, 3 cows.

    Sunday, November 04, 2012 11:10 PM
  • I am having issues similar to this mans however I am using a single NIC setup being a UAG50 Firewall. DA worked perfectly until I added that.
    Wednesday, November 07, 2012 2:11 AM
  • Hi Pyr3x,

    Are your issues similar in the way that you can't use 443 since it is already used by something else or are your solution not working on 443 now that you added your firewall?
    If you simply have problems now that you added your firewall, start up a new thread instead and describe your problem there, that way you will get more people that see your thread (ie, easier to get help) and it will be easier for other persons looking for a solution to their problem to follow the various discussions)

    Regarding how to use an alternative port for DA, I never think Arun managed to get the alternate port setup to work and based on the problems he had that seemed to require both ports open/forwarded it looks like it is not something that will be very easy to setup either.

    Best wishes,
    Jonas Blom


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    Wednesday, November 07, 2012 10:53 AM
  • I am looking for a full (well working) step by step guide for DA on server2012 for windows8.

    I saw some videos on youtube, but these are still not full correct working.

    Who has a link for a working senario for this?

    And maybe a solution/workarround for the combination with OWA and 1 Public IP ?

    Thx

    Wednesday, April 03, 2013 11:05 AM
  • Hi there

    I realise this is an old thread, but I kept coming across it when I was trying to find an solution for the same problem.  This is how I resolved my issue, note that I was only trying to connect one permanently external server to direct access so this solution probably won't work for everyone, but may give you some ideas.

    1. Set up Direct Access on port 443 as per normal and make sure all is working.

    2. Edit Hosts file and add your external server address and point it to 127.0.0.1

    3. Add port forwarding from 127.0.0.1:443 to your External IP and whatever port you want to use (netsh int portproxy add v4tov4 listenaddress=127.0.0.1 listenport=443 connectaddress=<External IP of DA Server> connectport=<custom port>

    4. Use port translation on your router to forward your custom port back to your Direct Access server on port 443 (My router doesn't allow port translation so I just forwarded it to my internal server and used port proxy to redirect it back to 443)

    And there you have it, no need to change GPO settings.  The trade off is of course that you will not be able to connect to any other external services on your network using the same address, but if you configure a separate address solely for DA this should work a treat.



    • Edited by SOE Guru Sunday, November 10, 2013 12:58 AM Corrected Netsh Command
    Sunday, November 10, 2013 12:54 AM