none
ESP not encapsulating in UDP for public address hosts

    Question

  • I have a couple of IPSEC server-to-server (transport) policies configured between Windows Server 2016 hosts and authenticated by Kerberos in our AD environment. They work as I would expect them to work, except for one thing: the ESP packets are not encapsulated in udp/4500 if none of the hosts is behind a NAT device. The presence of NAT is presumably determined in IKE Phase 1 via the mechanism described in RFC 3947 section 3.2, the result is IP-ESP (Protocol 50) packets being sent out:ESP

    The NAT detection mechanism is apparently not fit to determine if the network in between is filtering ESP, so if it does, IPSEC ESP tunnels fail to establish although they would be establishing just fine over UDP-ESP encapsulation.

    I have tried searching the internets, but most contributions on this topic deal with the L2TP VPN tunnel configuration where the server is behind a NAT device, which does not fit my scenario well. Nonetheless, I tried setting AssumeUDPEncapsulationContextOnSendRule in HKLM\CurrentControlSet\Services\PolicyAgent to 2 as suggested by most of the sources - but this does not seem to change anything, ESP packets still get sent out unencapsulated.

    How could I force or favor UDP-ESP encapsulation for my server-to-server IPSEC connections?

    Wednesday, June 13, 2018 8:08 AM

All replies


  • Hi,

    Thanks for your question.

    Based on the complexity and the specific situation, we need do more researches. If we have any updates or any thoughts about this issue, we will keep you posted as soon as possible. Your kind understanding is appreciated. If you have further information during this period, you could post it on the forum, which help us understand and analyze this issue comprehensively.

    Sorry for the inconvenience and thank you for your understanding and patience.

    Best regards,

    Michael


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



    Thursday, June 14, 2018 9:00 AM
  • Hello Michael,

    thanks for following up on my question. Have there been any updates since the last post? Do you need further information I could provide here?

    Kind regards

    Wednesday, June 20, 2018 9:27 AM