Share via

Why are IPv6 addresses shown incorrectly in the RRAS console and logs?

Anonymous
2024-05-23T11:34:40+00:00

Hello,

We are using Routing and Remote Access on Windows Server 2022 to provide access to off-campus staff. Our servers are accessible over IPv4 and IPv6, and the vast majority of our connections from clients are via IPv6.

I noticed that the representation of IPv6 addresses appears to be broken in RRAS, both in the console and in log files:

  • Client IPv6 addresses are always cut down to their first 64 bits, and in the last 64 bits the real host address information is removed and :1700:1bb:: is appended.
    • For example, a client connecting from IPv6 address 2001:db8:1234:5678**:1967:c0ff:eeee:1337** is shown in the RRAS console and logs as 2001:db8:1234:5678**:1700:1bb::**
  • Server IPv6 addresses are cut down to their first 64 bits, and the last 64 bits are simply lost and replaced with ::
    • For example, a connection to a server with the IPv6 address 2001:db8:8765:4321:face:cafe:1812:1000 is just shown as 2001:db8:8765:4321::

This issue happens on clean installs of multiple servers running Windows Server 2022, and I also noticed it on a previous server running Windows Server 2016.

This is problematic for two reasons:

  1. It prevents us from having an accurate log of the original client's IPv6 address.
  2. It prevents us from using IPv6 at all in our NPS policies, as server IPv6 information is lost:
    1. For example, if we have two VPN servers in the same /64 IPv6 subnet, they both show up as being the same (cut-off) address in the connection logs, meaning that we cannot use IPv6 and must use IPv4 addresses for this.

Does anyone know of a reason for this, or if this is simply a broken functionality? To whom should this be reported, if it is a broken function? Given the US Government mandate for IPv6 use, I don't think it's something that can be ignored long-term...

I've included a screenshot showing four connections, from clients on different internet providers and networks, to one server. Notice how all client IPv6 addresses end with the incorrect :1700:1bb:: and how all server addresses are incorrectly cut down to the first 64 bits of the address.

Kind regards,

Samuel

Windows for business | Windows Server | Networking | Other

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

8 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2024-06-17T09:50:37+00:00

    Hi Gary,

    I simply want to have every reference to IP addresses set up to use IPv6 instead of IPv4, to prepare for having some servers single-stack, without having to actively wonder whether referencing NPS RADIUS Clients using IPv6 addresses is broken due to NPS perhaps handling IPv6 addresses the same broken wasy as SstpSvc.dll does. I.E. does defining RADIUS clients with IPv6 address work correctly if the clients are in the same subnet, knowing that if NPS has the same bug as SstpSvc.dll, it will see them as coming from a different address that will be identical for both serviers?

    So, this isn't blocking my from working, assuming I am OK using IPv4, but it's something that Microsoft should fix, from a functional perspective (I should be able to use only IPv6 without wondering which parts of the RRAS and NPS systems are broken) and also from a legal perspective (I am unable to see the "true" client IP addresses in logs).

    Perhaps the solution is to do what I've wanted to do for a while... just stop using RRAS and accept that Microsoft will probably never fix this.

    Best,

    Samuel

    Was this answer helpful?

    0 comments
  2. Anonymous
    2024-05-28T09:23:29+00:00

    Hello Samuel,

    For fun, I tested whether the problem can be "fixed" with debugger intervention - that seems to work:

    I think that this problem has always existed. The documentation history for SSTP ([MS-SSTP]) dates back to 2007. I don't know how to "effectively" report problems like this to Microsoft.

    Can you be (very) explicit about how you would like to use the Called/Calling Station ID in your NPS policies?

    The first 64 bits of each address are accurate; the lower (missing) 64 bits may be random (even for the same client: netsh interface ipv6 show privacy).

    Gary

    Was this answer helpful?

    0 comments
  3. Anonymous
    2024-05-28T08:28:54+00:00

    Hi Gary,

    Thanks so much for your detailed reply explaining why this bug occurs.

    The address information is only "informational", so everything apart from some incorrectly reported address information works (as you have noticed).

    Although the server still functions over IPv6 when we use IPv4 in our NPS policies, the issue is that the addresses being incorrectly reported prevent us from using IPv6 in NPS policies. This results in another system that we have to keep on IPv4 despite it being an up-to-date server, whereas all other systems we're standing up use IPv6 internally (with IPv4 still provided for older client access).

    Hopefully I can find a place to report this to Microsoft. Considering the US government mandate that 80% of their systems be running IPv6-only by the end of 2025, it's interesting to find this kind of problem that would render Microsoft's latest Server OS noncompliant.

    Best,

    Samuel

    Was this answer helpful?

    0 comments