none
DirectAccess - Lost Access to one server across IPHTTP RRS feed

  • Question

  • DirectAccess is working fine for months. I have tons of internal resources mapped- intranet sites, NAS units, and many servers. All of a sudden, my main file server is inaccessible. I am connected to DA fine, green checkmarks everywhere. I can access intranet sites, and other servers. But my main file server I cannot RDP into it, nor access shares, nor browse it. Its like it dropped out of DA.

    How do I troubleshoot this?


    "Sadly most places want the Porche fastness and reliablity, but only pay for a used 74 pinto, then they are "Shocked" that it wont run, and blame the IT guy"

    Friday, December 29, 2017 6:03 PM

All replies

  • Is it possible that the main file server has stopped responding to pings? That ICMP replies are now being blocked where before they were allowed?

    This would only affect Teredo-connected users, because Teredo relies on ICMP echoes to connect to resources. So for example, if you had UserA connected via Teredo and UserB connected via IP-HTTPS and they were both trying to hit a server that didn't respond to pings, UserA would fail but UserB would be successful. The fix here would be to re-enable ICMP replies on the file server.

    Otherwise if that doesn't seem to be the cause - what happens when you ping that file server from your DA-connected laptop? Does it still resolve to an IPv6 address like what is normal behavior over DA?

    Tuesday, January 2, 2018 6:43 PM
  • It actually looks like I can only ping my DA server, not any other Windows network servers. I can ping network Linux servers though.

    TDD-DC3 is my Domain Controller

    TDD-DA is my DirectAccess

    VM-2012R2 is my Exchange Member Server

    POOL2 is a Lunix server running FreeNAS

    C:\WINDOWS\system32>ping tdd-dc3.localdomain.local

    Pinging tdd-dc3.localdomain.local [mask::254] with 32 bytes of data:
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.

    Ping statistics for mask::254:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

    C:\WINDOWS\system32>ping tdd-da.localdomain.local

    Pinging tdd-da.localdomain.local [mask::252] with 32 bytes of data:
    Reply from mask::252: time=32ms
    Reply from mask::252: time=30ms
    Reply from mask::252: time=26ms
    Reply from mask::252: time=37ms

    Ping statistics for mask::252:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 26ms, Maximum = 37ms, Average = 31ms

    C:\WINDOWS\system32>ping vm-2012r2.localdomain.local

    Pinging vm-2012r2.localdomain.local [mask::248] with 32 bytes of data:
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.

    Ping statistics for mask::248:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

    C:\WINDOWS\system32>ping pool2.localdomain.local

    Pinging pool2.localdomain.local [mask:296] with 32 bytes of data:
    Reply from mask:296: time=22ms
    Reply from mask:296: time=25ms
    Reply from mask:296: time=29ms
    Reply from mask:296: time=33ms

    Ping statistics for mask:296:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 22ms, Maximum = 33ms, Average = 27ms


    "Sadly most places want the Porche fastness and reliablity, but only pay for a used 74 pinto, then they are "Shocked" that it wont run, and blame the IT guy"

    Wednesday, January 3, 2018 4:15 PM
  • One thing I did notice is that my CA is not showing up in netsh show effective or netsh show policy

    C:\WINDOWS\system32>netsh namespace show effective

    DNS Effective Name Resolution Policy Table Settings


    Settings for .localdomain.local
    ----------------------------------------------------------------------
    DirectAccess (Certification Authority)  :
    DirectAccess (IPsec)                    : disabled
    DirectAccess (DNS Servers)              : mask:252
    DirectAccess (Proxy Settings)           : Bypass proxy


    Settings for DirectAccess-NLS.localdomain.local
    ----------------------------------------------------------------------
    DirectAccess (Certification Authority)  :
    DirectAccess (IPsec)                    : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (Proxy Settings)           : Use default browser settings

    Locally from the DA server I can ping all IPv4 and IPv6 addresses as well as NSLOOKUP both for all servers. If I check ipconfig/all it shows mne as connected.

    http://prntscr.com/hvp00m

    On the DA server my client status shows connected.

    "Sadly most places want the Porche fastness and reliablity, but only pay for a used 74 pinto, then they are "Shocked" that it wont run, and blame the IT guy"




    Wednesday, January 3, 2018 8:03 PM
  • Anyone want to take a stab at this? I have resetup, and everything looks good. I can access a lot of resources via DA and local domain names, but not shares on Windows server.

    "Sadly most places want the Porche fastness and reliablity, but only pay for a used 74 pinto, then they are "Shocked" that it wont run, and blame the IT guy"

    Friday, January 12, 2018 3:18 AM
  • Hey Christopher, sorry for the delay. I swear sometimes the forums only email me responses about 10% of the time they happen.

    I assume where you showed your ping results that your "mask::248" are things you did in order to mask the actual address, right? Are you resolving to a full IPv6 address during these pings? Have you tried calculating the hex on those IPv6 addresses to make sure they match the proper internal IPv4 addresses? If you take the last two sections of the IPv6 and convert that hex into decimal, it should equate to the internal IPv4 address of the server you are trying to contact. Might be good to spot check a couple and make sure the traffic is headed the right direction.

    Is the DA server a dual-NIC setup? I would also double-check your routing table on that guy and make sure everything looks good. It's pretty common for people to forget to put the "-p" into their route add statements, and then everything works great until the DA server reboots, at which point the routes that were not created to be persistent fall away and then things get weird. If you are able to ping the internal IPv4 addresses of those servers from the DA server itself, then it is most likely that the routes are still in place, but it never hurts to double-check.

    Any changes to your client-side antivirus recently? Perhaps adding of a component that does its own network protection mechanism? I have seen these interfere with a DA connection before. I recommend removing any kind of network/firewall capability that an antivirus does, as DirectAccess relies on the Windows Firewall. For example, Symantec's Network Threat Protection commonly causes problems with DirectAccess connections. Also check inside Add/Remove Programs and make sure that a program called "Intel Online Connect" is not installed. This guy also causes trouble in the DA world and I've seen a few cases in the past month where this software mysteriously self-installed on some clients computers.

    Friday, January 12, 2018 1:53 PM
  • I assume where you showed your ping results that your "mask::248" are things you did in order to mask the actual address, right? Are you resolving to a full IPv6 address during these pings?  - Yes, I modified this after the fact when I pasted. The addresses resolved are the actual addresses which the devices have.

    Is the DA server a dual-NIC setup? - Single NIC. I know all the warnings etc, but single NIC is what I got, this is a home-lab setup though it is production for me.

    I would also double-check your routing table on that guy and make sure everything looks good. Looks like it always does: http://prntscr.com/i1c2o8

    AV was updated, but I uninstalled it with no change.

    I actually bumped into the Intel Online Connect issue a few months back. After figuring it out, I restored back to a previous install and blocked that patch from being installed.

    Just to reiterate... I can access ALL LAN resources provided they are not on my domain controller or other windows servers as shares. I can access all websites, NAS drives, linux shares- all of that works, except my windows shares. Also, I cannot RDP into windows servers anymore, but I can continue to connect to any other resources, such as SSH into a linux host over the DA tunnel. The one sxclusion is the DA server, I can reach this over the tunnel with no problems.

    Also, this problem is affecting all of the two clients, so it is something with the server in my opinion.


    "Sadly most places want the Porche fastness and reliablity, but only pay for a used 74 pinto, then they are "Shocked" that it wont run, and blame the IT guy"



    Tuesday, January 16, 2018 6:45 PM
  • I completely redeployed DA both server and client side, same behavior.

    Resources:

    Domain Controller File Server Shares: Not available

    Exchange Server Shares: Not available

    Direct Access Server Shares: Available via local address

    Windows 7 Client Shares: Available via local address

    Windows 10 Client Shares: Available via local address

    FreeNAS HTTP, HTTPS, and SMB Shares: Available via local address

    Ubuntu HTTP, HTTPS: Available via local address


    "Sadly most places want the Porche fastness and reliablity, but only pay for a used 74 pinto, then they are "Shocked" that it wont run, and blame the IT guy"

    Wednesday, January 17, 2018 4:07 PM
  • You said that from the DA server you are able to successfully ping the other Windows servers, right? Can you also do RDP/file shares from the DA server to the other servers successfully?

    When you are connected via DA, if you open up "wf.msc" on the client computer and look inside Monitoring | Security Associations | Main Mode - what do you see listed in this folder? Specifically do you see items (tunnels) listed here with both NTLM and UserKerb listed for 2nd Authentication Method?

    Wednesday, January 17, 2018 4:31 PM
  • Ok.

    From the DA server:

    Ping DC IPv4 and IPv6 work.

    I can RDP and access all shares of the DC.

    While client is connected via DA:

    http://prntscr.com/i8fqdm

    I have Computer Kerb V5 and User Kerb V5.

    I am not sure if this is how it was... I recently lost my DA connectivity entirely and restored my machine back to Oct 16 to get it back. After the restore, DA was dead due to the missing GPO, so I recreated it. It works, so it is  active, same problem as before though.

    Description                      : DA Client Settings
    CorporateResources               : {HTTP:http://directaccess-WebProbeHost.lcldmn.local,
                                       HTTP:http://plex.lcldmn.local:32400/web/index.html}
    IPsecTunnelEndpoints             : {PING:xxxx:fc65:f09:1000::1, PING:xxxx:fc65:f09:1000::2}
    CustomCommands                   :
    PreferLocalNamesAllowed          : True
    UserInterface                    : True
    PassiveMode                      : False
    SupportEmail                     : chris@thelcldmn.com
    FriendlyName                     : DA
    ManualEntryPointSelectionAllowed : True
    GslbFqdn                         :
    ForceTunneling                   : Default

    LastErrorCode   : 0x0
    InterfaceStatus : IPHTTPS interface active

    PolicyStore       : ActiveStore
    ConfigurationType : GroupPolicy
    Profile           :
    ProfileActivated  :
    State             : Default
    ServerURL         : https://somesub.pubdmn.com:443/IPHTTPS
    Type              : Client
    AuthMode          :
    StrongCRLRequired : False

    And here is DNS resolution working, while connected to the DA tunnel... I can resolve resources, just not touch em:

    PS C:\WINDOWS\system32> Resolve-DnsName tdd-da

    Name                                           Type   TTL   Section    IPAddress
    ----                                           ----   ---   -------    ---------
    TDD-DA.lcldmn.local                        AAAA   227   Answer     xxxx:fc65:f09:d188::252


    PS C:\WINDOWS\system32> Resolve-DnsName tdd-dc3

    Name                                           Type   TTL   Section    IPAddress
    ----                                           ----   ---   -------    ---------
    TDD-DC3.lcldmn.local                       AAAA   2438  Answer     xxxx:fc65:f09:d188::254

    PS C:\WINDOWS\system32> Get-DnsClientNrptPolicy


    Namespace                        : .lcldmn.local
    QueryPolicy                      :
    SecureNameQueryFallback          :
    DirectAccessIPsecCARestriction   :
    DirectAccessProxyName            :
    DirectAccessDnsServers           : xxxx:fc65:f09:d188::252
    DirectAccessEnabled              :
    DirectAccessProxyType            : NoProxy
    DirectAccessQueryIPsecEncryption :
    DirectAccessQueryIPsecRequired   : False
    NameServers                      :
    DnsSecIPsecCARestriction         :
    DnsSecQueryIPsecEncryption       :
    DnsSecQueryIPsecRequired         : False
    DnsSecValidationRequired         : False
    NameEncoding                     : Utf8WithoutMapping

    Namespace                        : DirectAccess-NLS.lcldmn.local
    QueryPolicy                      :
    SecureNameQueryFallback          :
    DirectAccessIPsecCARestriction   :
    DirectAccessProxyName            :
    DirectAccessDnsServers           :
    DirectAccessEnabled              :
    DirectAccessProxyType            : UseDefault
    DirectAccessQueryIPsecEncryption :
    DirectAccessQueryIPsecRequired   : False
    NameServers                      :
    DnsSecIPsecCARestriction         :
    DnsSecQueryIPsecEncryption       :
    DnsSecQueryIPsecRequired         : False
    DnsSecValidationRequired         : False
    NameEncoding                     : Utf8WithoutMapping



    "Sadly most places want the Porche fastness and reliablity, but only pay for a used 74 pinto, then they are "Shocked" that it wont run, and blame the IT guy"

    Thursday, February 1, 2018 1:13 AM
  • And again, this is wierd. While connected to DA tunnel:

    Ping from client to DA internal DNS name works.

    Ping from client to linux internal dns name works.

    Ping from client to a random Windows 10 machine internal dns name works.

    Ping from client to DC internal dns does NOT work.

    Ping from client to Exchange internal dns does NOT work.

    Ping from client to other windows machines do not work.

    Not sure if this matters, but most of those unreachable machines have IPV6 DNS entries in my local dns server. The Windows 10 machine which is pingable does not have a statically assigned ipv6 address nor an ipv6 ptr.

    Ah Ha!!

    Any resource which has an IPv6 address defined in my ADDNS zone cannot resolve over DA. As soon as I remove the entries, it becomes pingable. I have had static IPv6 deployed for ages though.... not sure why this would be the case? The IPv6 address returned on the ping is not a listed address on the machine itself.


    "Sadly most places want the Porche fastness and reliablity, but only pay for a used 74 pinto, then they are "Shocked" that it wont run, and blame the IT guy"



    Thursday, February 1, 2018 1:47 AM
  • Aha! Good find. If you are using IPv6 internally and want DA clients to be able to tap those resources, the DA server also needs to be part of that IPv6 network and have proper routing in place for it.

    If you ping these machines and they are coming back with a different IPv6 address than the address that is actually on those internal servers, it sounds like the DA server is only on the IPv4 internal network (or at least only knows about IPv4 DNS servers), so it's only able to get those internal servers internal IPv4 addresses from DNS, and is using DNS64 to translate out an address to hand to the clients.

    So you should be able to resolve this by getting your DA server communicating properly with your native IPv6 environment inside the office. Or, go back to all IPv4 inside and let it work that way.

    Thursday, February 1, 2018 1:39 PM