Troubleshooting DA client connections RRS feed

  • Question

  • Hi,

    I have a customer who uses a piece of inventory software that communicates on port 17932 for clients. I've taken over managing Direct Access, which seems to be working for everything, but this inventory software. The DA clients simply do not show up in the management server.

    The network diagnostics are as follows:

    Management Server (MS) 2008 R2 - client Windows 7

    client can ping MS
    client can RDP to MS
    MS can RDP to client
    MS cannot ping client

    Nmap -6 MS (using hostname) from client reports an error message stating that it cannot determine MAC, 0 hosts up.

    Netstat -a shows port 17932 is open on both server and client. I've checked the TMG rules with my limited TMG experience, but cannot see anything that would block the traffic. I've added the MS as a custom infrastructure management server in the UAG infrastructure servers wizard.

    The connections from UAG to the clients are over Torredo and IP HTTPS.

    All other internal resources seem fine.

    If someone could advise the best way to troubleshoot this, I'd much appreciate it. Alternatively, a way of proving to my client that port 17932 isn't being blocked by DA would be much appreciated (i.e. a way of getting a port scanner to work over DA).


    IT Support/Everything

    Saturday, August 11, 2012 12:43 PM

All replies

  • Hi

    OK for port 17932 but for TCP or UDP. And most important : Are you sure how your client is configured? With an IPv4 public address or a FQDN? Sometimes, some application does not like IPv6 at all and still use IPv4. Just perform a network trace when your client is connecting to the management server (client connecter by DirectAccess and on Lan, just to compare the situations).

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Saturday, August 11, 2012 2:31 PM
  • The application uses TCP.

    I've ran a network trace from the client to the inventory set

    tracert -d servername

    1. tunnel adapter iphhtps interface of UAG box
    2. ISATAP address of inventory server

    Doing the trace the otherway around (from server)

    tracert -d client_name   (client name resolves successfully to tunnel adapter iphttps ipv6 address)

    1.tunnel adapter isatap of UAG box
    2. Request times out

    Is there a way to check whether UAG is dropping the packets?

    IT Support/Everything

    Sunday, August 12, 2012 7:41 AM
  • Hi

    So we are sure your application can use IPv6. In your first post you mention that your inventory software communicate with the client. Did you setup an incoming firewall rule on your client with Edge transversal enabled? If not, it is normal your client block a incoming network flow that it did not initiate.

    If sur inventory server cannot ping your DA client check :

    -IPv6 registred in DNS

    -Check you enable ICMPV6 incoming firewall rule on the DirectAccess client with the Edge transversal option enabled

    The only way to check if UAG id dropping packets is to check in the TMG reports for dorpped packets.

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Sunday, August 12, 2012 4:03 PM
  • BenoitS,

    The IPV6 must be registered in DNS for the Snow server to be able to RDP (the tunnel adapter gets a NAT64 address).

     I'm awaiting an answer from Snow Inventory for the answer to that - I've found nothing to say the application isn't IPV6 aware. I've enabled File and Print Sharing Echo Request ICMP v4 and v6 for domain and private network. I've done this on inbound and allowed outbound traffic, the edge traversal option has been set.

    On the Forefront UAG server, I went into Forefront TMG
    Logs & Reports
    Logging, start query.

    The client IP never shows in the logging window. The Snow server shows up, but only shows IPv6 over IPv4 Tunnel as the protocol or https with port 443. Even when I'm running an RDP session between the server and client, the RDP traffic will still not show in the logs - only information being shown is port 443.

    Am I missing a config option somewhere? I'd rather avoid tinkering with UAG TMG firewall rules as this could cause issues.


    IT Support/Everything

    Monday, August 13, 2012 3:35 PM
  • If your internal server needs to communicate as a Manage-Out Client to a DirectAccess Client; then make sure your DirectAccess Client has a inbound firewall rule which is configured to "allow edge traversal".

    Boudewijn Plomp, BPMi Infrastructure & Security

    Tuesday, August 14, 2012 12:53 PM
  • To go back to your original post, if this management server has the ability to RDP into the DirectAccess client, then your routing is fine. The fact that pings do not reply probably just means that there is not a Windows Firewall rule on the DA client allowing those to happen (you have to specifically allow ICMPv6 replies if you want them to work)

    Assuming that is still true, that the management server can RDP into the client, then this is likely one of two things, and which one is it can probably be determined by the answer to this question: Do you know if this inventory application is initiated as a "pull" from the client (the DA client machines makes first contact to the management server), or is the application a "push" from the server to the client?

    If it's a push from the server to the client, you need a Windows Firewall rule on the client machines that allows whatever port the application uses, and that rule needs to be set to Allow Edge Traversal. If you can successfully RDP to the DA client machines, that means you already have a rule like this created for RDP, but you would need another similar rule created for this app's port.

    If it's a pull that is initiated from the client, then the problem is likely that the application is not IPv6 capable. If this turns out to be the case, feel free to reach out to me directly, I have a utility that can fix this in many cases. It helps IPv4-only applications work over DirectAccess - my email is Jordan.Krause@ivonetworks.com

    Thursday, August 16, 2012 7:39 PM
  • Hi

    With a pull application and because your application rely on TCP, you could use that trick (PortProxy): http://danstoncloud.com/blogs/simplebydesign/archive/2012/02/11/tcpv4-based-applications-with-directaccess.aspx. If it works, it means that your application rely on IPv4 only. I encountred a case like that and created a port proxy on But watch out, this may not work for all applications. Some of them deeply rely on an IPv4 stack.

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Thursday, August 16, 2012 8:16 PM