none
Can somebody explain why initial dcpromo of a new DC in a new Site fails if VPN tunnel between Sites has "too low" MTU?

    Question

  • Hi there,

    during the last few days I had a problem I never saw before and I would like to understand why this happened.
    So I would be very happy if somebody could explain to me.

    Here is what happened.
    I installed a Windows Server 2016 with all Windows Updates available.
    Then I ran dcpromo and created a new forest and new domain with this DC.
    - so far so good ... no problems -
    I set up two sites in AD, the first containing this new DC and the second one with the purpose to set up a second dDCn there.
    The two sites did have different subnets ( 192.168.44.0/24 & 192.168.88.0/24 ).
    The two sites were connected with a IPSec VPN tunnel.
    So I installed the second Windows Server 2016 in the second site with all Windows Updates available.
    I checked that the two Servers could ping each other and that SMB was working and it did. I also checked that DNS on the first one was working as I did it in the past whenever I promoted a Server to DC.
    The initial tests on the second DC were passed, the Server was promoted to DC and I could see it in AD BUT the sysvol never syncronized!
    dcdiag always got me one error I never saw before ... failing the dsgetdcname advertising telling me that it returned information for the first DC when trying the second one ...

    What I did to find the reason for that behaviour is too long to write here but nothing seemed to work.
    Fact: I installed and promoted a second DC in the first site ( so no VPN between the DCS ) and it worked without any problem.
    I installed the fourth Server in the second site ( with VPN in between ) and guess what it did NOT work.
    Same messages from dsgetdcname and no sysvol.

    After lots of googling I found something saying that initial sync would be done with udp packages and that there could be a problem with MTU so I tried to modify the registry to switch from UDP to TCP for Kerberos because TCP runs better with smaller MTU?
    Guess what ... nothing changed. I deleted the two DCs in the second site installed and promoted again and nothing happened.
    Same errors.
    I did check the MTU size available over the IPSec tunnel with PING -l -f and found out that the MTU was pretty low ... only 1394 was going through so I was wondering if this really could be the problem.
    I changed the VPN tunnel between the two sites to an SSL vpn and checked and got 1472 max MTU and with this VPN between the two sites I was able to promote a DC in the second site and everything went fine ... no errors, sysvol is replicated ...

    So please can somebody explain why this happened?
    I thought that Windows OS tests the MTU on the path and negotiate and then everything runs smooth?
    But why is that not working for initial sync of the sysvol?

    Thanks a lot for explaining it to me ...

    Thomas
    Monday, February 6, 2017 4:20 PM

All replies

  • Hi

     So please can somebody explain why this happened? >>>> It could have been for a number of reasons

    - Using the wrong DNS servers such as an external DNS, such as your ISP’s DNS server
    - Using your router as a DNS address – Note: your router is not a DNS server
    - Firewall blocks between the DCs, whether a perimeter firewall, firewall rules on the VPN tunnels
    - Antivirus software – many new antivirus sport a “network traffic protect” feature that act like a firewall that may block replication and other communication traffic.
    - Security software blocking necessary traffic
    - Windows Firewall not properly configured.
    - Duplicate DNS zones
    - MTU settings altered below 1500 on the VPN tunnel endpoints

    I guess you need to check all these possibilities...

    Also check these article for AD vpn mtu size(maybe already checked);

    https://blogs.technet.microsoft.com/askpfeplat/2014/12/01/psa-incorrect-mtu-size-causes-connectivity-issues-with-windows-server-2012-and-windows-server-2012-r2/

    and this similar case; https://social.technet.microsoft.com/Forums/windowsserver/en-US/c32ee1fa-9417-464a-9149-663d349159ae/activedirectory-replication-failing-after-a-day?forum=winserverDS


    This posting is provided AS IS with no warranties or guarantees,and confers no rights. Best regards Burak Uğur

    Monday, February 6, 2017 5:26 PM
  • Hi Burak,

    thanks for the reply ... but as I already stated all the mentioned things like wrong DNS, Firewall, Antivirus and so on was NOT the reason.

    As I wrote it was due to the MTU size of the VPN tunnel ... working with MTU 1472 and NOT working with MTU 1392 ... and I wanted to know why this difference in MTU prevents the initial sync th happen.

    Thanks

    Thomas
    Friday, February 10, 2017 11:00 AM
  • Hi Thomas,
    I would suggest you take a look at the following thread regarding some discussion MTU over VPN, you could refer to some details: https://www.experts-exchange.com/questions/22496206/MTU-Packet-size-VPN-with-Active-Directory.html
    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
    In addition, it seems to relate to details of network traffic, I would suggest you have a try in the network forum:
    https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserverNIS
    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. Thank you for your understanding.
    Best Regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, February 13, 2017 3:19 AM
    Moderator
  • Hi,

    Was your issue resolved? If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.

    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.

    If no, please reply and tell us the current situation in order to provide further help.

    Best Regards,

    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, February 17, 2017 9:32 AM
    Moderator