locked
Any suggestions on dealing with an IPv4 Subnet conflict for DirectAccess clients via UAG RRS feed

  • General discussion

  • Some of our DirectAccess users are working on a client's site and don't seem to be able to connect to our internal resources at the head office.

    I think the issue may be down to the IPv4 subnet configuration at the client clashing with ours. Naturally I can't ask the client to reconfigure their network for us and I don't want to redo things at our end.

    The remote network is 10.0.10.0 with a subnet mask of 255.255.0.0 and our network is 10.0.0.0 with a subnet of 255.255.255.0.

    I'm guessing the issue is down to how they are subnetting. If I am wrong please let me know.

    My idea to work around it is to use a static IP addresses in the 10.0.10.0 range with a subnet mask of 255.255.255.0 when we go onsite there. Will this work (I think it should in theory as their DNS and Default Gateway are also in the 10.0.10.0 range but it would be good to have it confirmed before I ask the client to do anything)?

    If that would work my next challenge will be how to set the IP addresses on our laptops with a script without elevating the end users priviledges. The idea being that they have one script to run that does the following:

    1. Get the IP address info assigned by the client DHCP server
    2. Use that IP address as the static IP plus the Default Gateway and DNS servers but set the subnet mask to 255.255.255.0

    When they leave the site they have a 2nd script to run that resets the network settings to be DHCP. This script will also be set to run when they shut the computer down just in case they forget.

    Any suggestions on that would be appreciated but that is not really a topic for this forum I guess.

    Thanks in advance for any suggestions.

    Darren


    Darren

    Wednesday, May 2, 2012 12:49 PM

All replies

  • This is a common problem with VPNs, but DirectAccess doesn't really care about IPv4, all of its traffic is IPv6. If your DA clients are not connecting from this network it is probably the fault of something else. Are you familiar with the DirectAccess Connectivity Assistant? If you can submit a sanitized log file that was taken while connected to that network it should indicate what isn't working.

    Since this is another corporate network, one of my first guesses without any data would be that Teredo sees itself as being inside a managed network. Try running netsh interface teredo set state enterpriseclient on a DA client machine and give it another try, this command will tell Teredo to connect even if its sitting in a domain network.

    Thursday, May 3, 2012 2:31 PM