Is directaccess blocking ports??? RRS feed

  • Question

  • I have a directaccess server running on Windows Server 2012.  It is working nicely except for 1 piece of software.  This client server application will not talk to its server.  It uses TCP port 28754 for communications.  The other client server applications I have work fine but their port numbers are all lower than 1024.  Does DirectAccess firewall any ports above 1024? 
    Friday, July 26, 2013 4:38 PM

All replies

  • Hi,

    The DirectAccess server must have TCP port 443 open on its firewall.

    For related ports, please refer to the following Microsoft TechNet blog:

    DirectAccess and Firewalls and NAT


    Arthur Li

    TechNet Community Support

    Saturday, July 27, 2013 4:24 AM
  • Hi Arthur,

    I am using an edge setup so my external NIC is directly connected to the internet.  port 443 is already open on the windows firewall.  My DA clients connect, get GP updates, drive mappings, print to network printers, etc.  The problem is this one piece of client server software.  For some reason the client will not talk to its server.  Well that is not entirely true, part of the client talks to the server using port 899 and that works fine.  The problem is when the client tries to use 28754.  I always get server timed out messages.  If I plug the laptop into the local network everything works fine so I am thinking it must be some sort of DA issue.



    Sunday, July 28, 2013 12:12 AM
  • It was a really good question. I'm so sorry that it wasn't answered.

    DirectAccess grabs ports 6000-47000.  You can see this from PowerShell.

    You must use ports outside of this range :)

    • Proposed as answer by LesterClayton Saturday, July 8, 2017 6:32 PM
    • Edited by LesterClayton Thursday, July 13, 2017 2:17 PM Removed period from command
    Thursday, July 6, 2017 5:27 PM
  • The fact that Microsoft does this should also be questioned.
    Killing ports 6000-47000 messes with so many potential 3rd party services.

    This was very difficult problem to Diagnose because the application we had was binding to
    The service could listen on loopback - but not on the IP of the server.
    Never seen anything like it before. Telnet or putty test to the port - 8000 in that case would work to loopback.
    Test to that port using the IP and port failed from the server itself - and of course externally.

    netstat commands and other tools did not show a binding of port 8000 to the IP.
    Just a binding to - which normally would allow the regular IP to work.

    BTW - same problem caused an issue with WSUS running on the server at port 8530.

    Thursday, August 3, 2017 8:16 PM
  • Yeah the reason it's done though is to do NAT6to4 translation.  If you have a server on IPv4 internally, then it has to create a NAT6to4 rule to allow communciation from your DA Client to the legacy IPv4 server.  It reserves all these ports for that porpose.

    Don't get me wrong - I'm not defending what they've done, I'm just epxlaining why it's done :)  It's caused us a fair bit of grief too.  Zabbix's default port of 5080 and 5081 were failing, so we've had to change that to be a higher port.

    What would be helpful is if DirectAccess's status page would give you a warning if it detected any applications listening on the ports its assigned to its NAT pool and say "This is not going to work because I've reserved that port".

    DirectAccess should really be on its own dedicated (virtual) server, from both a security and performance perspective.  The IP over HTTPS tunnel means encryption and decrtypion, and you don't really want to share the CPU load with other services - especially if you have a lot of DA Clients

    Friday, August 4, 2017 6:25 AM
  • I'm having a similar issue. My app uses port 11000, and I've tried excluding this port from DirectAccess and changing the port the app uses to one outside DirectAccess' range. Neither actually worked for me. If I disconnect the DirectAccess connection this app works fine as we have published it through TMG 2010 on its standard port.

    I'm not sure what else to try, or to see what's going wrong. Any ideas?

    While waiting for the app to timeout, this is what netstat shows (2 runs):

    M:\>netstat -ano|findstr
      TCP        SYN_SENT        2144

    M:\>netstat -ano|findstr
      TCP        SYN_SENT        6200


    Sunday, November 5, 2017 4:58 PM
  • Hi!

    I doubt the problem is related to reserved ports range for NAT64 on DA server.
    DA server reserves ports 6001-47000 for NAT mapping on internal interface for outbound connections so these ports will be used as src ports on connections from DA server to target app server. 
    And destination port will be the same as asked on DA client.
    I've tested this with web site on iis in internal network with service on port 40080 and tried to connect to it from DA client - it works.

    Translation on NAT64 shows ( - address of webserver):

    PS C:\> Get-NetNatTransitionMonitoring | ? {$_.Outboundaddress -like '*'}

    Protocol Inbound Address           Outbound Address          NAT Outbound Address
    -------- ---------------           ----------------          --------------------
    6        [xxxx:yyyy:zzzz:7777::af4:e50]:40080

    DA client establishes session to DA server: 

    [srcIPv6]:ClientDynamicSrcPort --> [xxxx:yyyy:zzzz:7777::af4:e50]:40080,

    and then DA server's NAT64 makes new connection from DA server internal interface to target app server on behalf of DA client and uses arbitrary source port 41912 (from reserved range in Get-NetNatTransitionConfiguration)

    []:41912 --> []:40080

    Therefore the problem with ports can be only when mapping ports pool will be exhausted.

    Is your application port reachable from DA server itself?

    Tuesday, November 7, 2017 10:20 AM
  • If I telnet from DA server to target app server using 'telnet servername 11000' I get a blank screen back. Not a 'connect failed' message, which I do get if I specify any other port. So does that mean it's reachable?

    The app sits on top of a Firebird database.

    Tuesday, November 7, 2017 12:56 PM
  • Yes, it reachable And what with the same telnet from DA client ?
    Tuesday, November 7, 2017 1:14 PM
  • Haven't tried that yet. Will do when I'm at home.

    Interestingly that command (Get-NetNatTransitionMonitoring | ? {$_.Outboundaddress -like '*'}) doesn't show any connections, at all, ever, even while the app is trying to load.

    If I change the IP for our Exchange server and open Outlook, I can see loads of connections, instantly.

    Tuesday, November 7, 2017 1:17 PM
  • It means there was no NAT translation and hence there was no successfull connection to DA server (or maybe connection passed thru another DA server, if DA clustered).

    Is the app name correctly resolves on DA client? Is it reachable with icmp ?

    If no it worth to turn on logging for dropped packets on client and DA server's firewall.

    One more thing to check - isn't your app server address in DMZ on the same with DA server's external interface network ?

    Tuesday, November 7, 2017 1:45 PM
  • I cannot telnet from a DA client. I can ping the server by name and IP address just fine though. Can also browse C$ and RDP into it.

    My DA server is single NIC and behind firewall (NAT). App server is on the same subnet.

    Tuesday, November 7, 2017 8:30 PM
  • Then TCP 1100 could be blocked by firewall or antivirus on client, or on DA server.
    Are there packets to your app server in fw logs on client and DA server when you telnet it?

    > While waiting for the app to timeout, this is what netstat shows (2 runs):
    M:\>netstat -ano|findstr
      TCP        SYN_SENT        2144
    M:\>netstat -ano|findstr
      TCP        SYN_SENT        6200
    Which machine this was called on?
    Wednesday, November 8, 2017 2:05 PM
  • netstat was called on the DA client.

    We have Windows Firewall configured as such:


    Domain profile: On but allow all in and out bound connections
    Private/Public profile: On default (in: block, out: allow)


    All profiles: On default (in: block, out: allow)

    This works OK for all but DA clients (for this app).

    Wednesday, November 8, 2017 3:44 PM
  • Looks strange then.
    DA client when outside can communicate to internal network resources only over ipv6 addresses.
    And your netstat shows connection attempts to ipv4.
    Does your client application have app server's ipv4 address placed in settings instead of name?
    Or does dns on client resolve appserver name to ipv4 ?
    And by the way, when you tested your app server reachability from DA client with telnet, ping etc - did you do that for server name, ipv6 or ipv4 ?
    Wednesday, November 8, 2017 4:12 PM
  • Client app is configured with app servers DNS name, which resolves to IPv4 when inside the LAN, and IPv6 address through DA.

    I tested telnet from DA server and client using DNS name too.

    Wednesday, November 8, 2017 8:32 PM
  • So telnet can connect to appserver from DA server and can't from DA client.
    I'd enable firewall logging on both client and DA server for active profiles and tried to find events in logs related to that connection - maybe it could clarify what's happening.
    Thursday, November 9, 2017 4:25 PM
  • Is this any cause for concern?

    We use split-DNS, have all our external domains added, and have them on the 'Enter DNS suffixes and internal DNS servers' tab of DA configuration.
    Friday, November 10, 2017 8:29 AM
  • Looks like a problem

    The public address of your DA server on client must be resolved by client's system DNS, not by DA's DNS64.

    For this NRPT have to contain exemption record for public DA servfer name.

    Friday, November 10, 2017 8:44 AM
  • OK, so what should be listed here then (and on the suffix search list):

    We have many external domains that are resolvable internally and externally:

    Friday, November 10, 2017 8:51 AM
  • PS: This app is configured to use the split-DNS name, so This is a CNAME entry in our local zone which points to the actual internal app server, which is On the public internet it is an A record pointing to the external IP we have for this app, which is punched through the firewall to the same internal server.

    Don't know if that makes a difference.

    Friday, November 10, 2017 9:57 AM
  • When you add domain suffix of host fqdn to NRPT (ie on DNS tab on DA management config) with "DNS Server address"=<your DA server ipv6>, DA-client will resolve those names with DNS64 and access them by DA-tunnel.
    When you add host fqdn with same suffix to NRPT as exemption (ie "DNS Server address"=<empty>), DA client will resolve it with local provider's DNS server and access it by internet with resolved public address.
    Suffix search list - passed to DA client with GPO for its dns client service to try all these suffices when access hosts with short names.

    So DA server entrypoint (public address) must always be exempted:, DNS Server Adddress=<empty>
    Your domain suffix should be normal nrpt record:, DNS Server Adddress=fd20:64b3:etc...
    For other public hosts with this domain suffix if you want to keep DA client accessing by internet and not through DA tunnel, you shoud add names as nrpt exemptions:, DNS Server Adddress=<empty>

    If your other domains are accessible in internal network and you want DA clients access them thru DA tunnel, you should also list their suffices in NRPT and add to exemptions public hosts.
    Friday, November 10, 2017 10:09 AM
  • >This app is configured to use the split-DNS name, so

    Well if is covered by normal nrpt entry ( is present with DA DNS ipv6 address, and is not exempted) then this name will be resolved to ipv6 and accessed through DA tunnel.
    If you add exemption for it, DA client resolve it with its interface' configured DNS and will access it as usual internet user by public ipv4 address
    Friday, November 10, 2017 10:11 AM
  • That is how I understood it. My screenshot was me deleting the non-default ones to see what would happen.

    We only use for services - the other domains are just for completeness if we ever decided to use them.

    This is how it is now, but the app still doesn't work. Weird.

    Friday, November 10, 2017 11:04 AM
  • And what about firewall logs?

    Friday, November 10, 2017 11:27 AM
  • And what about firewall logs?

    Nothing. I enabled logging for both dropped and successful packets but there is nothing in them for either the split-dns name (, internal server name, IPv4 IP address, IPv6 IP address or port 11000. This is on both the DA server and client.

    I can see other entries in the logs for all the other stuff.

    Friday, November 10, 2017 7:27 PM
  • PS: If I do an NRPT exemption for the full DNS name,, the app works. Obviosuly as it is using the internet rather than intranet for connection.

    This is netstat from an internal client (not through DA):

    This is netstat on the app server:

    I've already tried excluding port 11000 from DA's range, and even changing the app port to something outside DA's standard range.
    • Edited by Lanky Doodle Saturday, November 11, 2017 11:30 AM
    Saturday, November 11, 2017 10:35 AM
  • Could this be it:

    That the app just isn't IPv6 compatible? Is there anything I can do?

    I have another app on the same server on port 6133 and that works absolutely fine.

    Saturday, November 11, 2017 11:48 AM
  • Maybe answer is the quote from Richard M. Hicks:
    "Any application will work as long as it doesn’t make calls directly to IP addresses. As long as the application uses hostnames, single label or fully-qualified, it should work fine. Also, the application should not use protocols that embed IPv4 addresses in them, such as FTP and SIP"

    I know for sure this problem is for "Terminal Services Session Broker" technology, as TS session broker returns ipv4 address of terminal server to client request, and DA-client then can't connect to proposed address.

    If your app manipulates with ipv4 like that - it is incompatible.

    Saturday, November 11, 2017 12:25 PM
  • Thanks for that.

    Would that explain why I don't see anything for the app in the Windows Firewall logs, either on the DA client, DA server or app server itself.

    Is there anyway I can find out for sure?

    Sunday, November 12, 2017 9:41 AM
  • I asked them:

    "Thank you for getting in touch with us regarding APPNAME. Unfortunately, APPNAME only supports IPv4 addressing. We are not familiar with DirectAccess, but in order to use Online Filing you would need to have an IPv4 connection between the client and all of the relevant ports on the APPNAME Server."

    So an exemption is the only way then. I'm glad it's that, and not a configuration issue with DA.

    Thanks for all your help.

    Monday, November 13, 2017 12:24 PM
  • Actually, one last thing, and this is not configuration related.

    On the Remote Client Status tab, why does it sometimes show as:

    User Name | Host Name
    domain\<computeraccount$>, domain\username | host/<computer account FQDN>

    and others as:

    User Name | Host Name
    domain\<username> | domain\<computeraccount$>

    Monday, November 13, 2017 4:46 PM
  • >APPNAME only supports IPv4 addressing
    But this doesn't explain why telnet connection to server by hostname could not be established.
    Actually it should.

    >On the Remote Client Status tab, why does it sometimes show as

    It's unknown to me, on my environment all users in RMAC look like domain\<username> and machines as <fqdn>.

    Monday, November 13, 2017 8:00 PM
  • But this doesn't explain why telnet connection to server by hostname could not be established. Actually it should.

    That is a good point, actually. But I tried telnetting to our Exchange server on port 25 last night and that too fails from a DA client, but is OK from a LAN client and the DA server.
    Tuesday, November 14, 2017 9:17 AM