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

Question

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

Answer 1

Hello Samuel,

diagnose and resolve the issue with incorrect IPv6 address display in RRAS (Routing and Remote Access Service) on Windows Server 2022, you can follow these steps:

Step 1: Check Windows Server Updates

1. Open Windows Update:
   • Go to Settings > Update & Security > Windows Update.
   • Click Check for updates and install all available updates.
2. Restart the Server:
   • After installing the updates, restart the server to ensure all patches and updates are applied correctly.

Step 2: Check RRAS Configuration

1. Open RRAS Console:
   • Go to Server Manager > Tools > Routing and Remote Access.
2. Check VPN Settings:
   • Ensure the VPN server and client configurations are correct and are using the latest authentication and encryption protocols.

Step 3: Check and Record Logs

1. View Current Log Files:
   • Go to Event Viewer > Application and Services Logs > Microsoft > Windows > RemoteAccess.
   • Check for any errors or warnings related to IPv6 addresses.
2. Enable Detailed Logging:
   • In the RRAS console, right-click the server name and select Properties.
   • In the Logging tab, enable detailed logging to capture more information.

Step 4: Use Network Monitoring Tools

1. Install and Use Wireshark:
   • Download and install Wireshark.
   • Use Wireshark to capture traffic for the VPN connection and check if the IPv6 addresses of the clients and server are displayed correctly in the network traffic.

Step 5: Verify Configuration

1. Check IPv6 Configuration with PowerShell:
   • Open PowerShell and run the following commands to check the IPv6 configuration:

       Get-NetIPConfiguration
       Get-NetIPAddress -AddressFamily IPv6
       Get-NetRoute -AddressFamily IPv6
     

2. Verify IPv6 Address Configuration:
   • Ensure the IPv6 address configuration on both the server and clients is correct, including prefix and subnet configurations.

Step 6: Test and Reproduce the Issue

1. Set Up a Test Environment:
   • Set up a similar VPN and IPv6 configuration in a lab environment and try to reproduce the issue.
2. Record Test Results:
   • Document each test step and result in detail, especially how IPv6 addresses are displayed in the RRAS console and log files.

By following these detailed steps, you can better diagnose and report the IPv6 address display issue. If you encounter difficulties at any step or need further assistance, feel free to contact me.

If you have any other questions or need more detailed information, please let me know.

Kind regards,

Rosy

Answer 2

Dear Rosy,

Thank you for your response.

Step 1: Check Windows Server Updates

1. Open Windows Update:
   • Go to Settings > Update & Security > Windows Update.
   • Click Check for updates and install all available updates.
2. Restart the Server:
   • After installing the updates, restart the server to ensure all patches and updates are applied correctly.

The two servers are completely up-to-date (including the most recent May cumulative udpates), but as I indicated in my message, the issue affects even Windows Server 2016, and seems to be a product issue that it unrelated to patches.

Step 2: Check RRAS Configuration

1. Open RRAS Console:
   • Go to Server Manager > Tools > Routing and Remote Access.
2. Check VPN Settings:
   • Ensure the VPN server and client configurations are correct and are using the latest authentication and encryption protocols.

There is no configuration option related to incorrectly displaying IPv6 addresses.

Step 3: Check and Record Logs

1. View Current Log Files:
   • Go to Event Viewer > Application and Services Logs > Microsoft > Windows > RemoteAccess.
   • Check for any errors or warnings related to IPv6 addresses.
2. Enable Detailed Logging:
   • In the RRAS console, right-click the server name and select Properties.
   • In the Logging tab, enable detailed logging to capture more information.

This does not help the issue, as logs are being created, with the same incorrect IPv6 addresses that I see in the RRAS console.

Step 4: Use Network Monitoring Tools

1. Install and Use Wireshark:
   • Download and install Wireshark.
   • Use Wireshark to capture traffic for the VPN connection and check if the IPv6 addresses of the clients and server are displayed correctly in the network traffic.

I have very clearly indicated that the IPv6 addersses are not correctly indicated. The server was even incorrectly indicating its own IPv6 address.

Step 5: Verify Configuration

1. Check IPv6 Configuration with PowerShell:
   • Open PowerShell and run the following commands to check the IPv6 configuration:

       Get-NetIPConfiguration
       Get-NetIPAddress -AddressFamily IPv6
       Get-NetRoute -AddressFamily IPv6
     

2. Verify IPv6 Address Configuration:
   • Ensure the IPv6 address configuration on both the server and clients is correct, including prefix and subnet configurations.

The IPv6 configuration is perfect. Also, as indicated, IPv6 is functioning fine, but the addresses displayed in the RRAS console and logs are correct.

Step 6: Test and Reproduce the Issue

1. Set Up a Test Environment:
   • Set up a similar VPN and IPv6 configuration in a lab environment and try to reproduce the issue.
2. Record Test Results:
   • Document each test step and result in detail, especially how IPv6 addresses are displayed in the RRAS console and log files.

By following these detailed steps, you can better diagnose and report the IPv6 address display issue. If you encounter difficulties at any step or need further assistance, feel free to contact me.

As I indicated in my message, this happened on several (all) of the servers I have set up, which are all clean Windows installations, some on Windows Server 2016 and the most recent on Windows Server 2022.

As for "Document Test Results"... I did this in my initial message, even giving a screenshot that was quite thoroughly prepared.

Could you please indicate how to escalate the issue, where to file a bug report, or any other specific information that is related to this problem?

Thanks,

Samuel

Answer 3

Hello Samuel,

This is indeed a bug in SstpSvc.dll. When SstpSvc receives a new call indication in the form of a response from the HTTP service, the HTTP service provides the full address information in SOCKADDR form, but SstpSvc assumes that the address is a sockaddr_in (rather than a sockaddr_in6) and copies just 16 bytes to the buffer that it sends to NDProxy to create the virtual circuit; SstpSvc also gets the layout of the buffer wrong, assuming that there are two embedded sockaddr_in elements rather than two sockaddr_in6 sized elements.

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

Gary

Answer 4

Hello Samuel,

Thank you for providing detailed information and step-by-step instructions. Here are some potential solutions and next steps:

Step 1: Check Windows Server Updates

Please ensure all servers have the latest updates installed. Although you have confirmed the servers are up to date, this step helps eliminate any issues caused by missing updates.

Step 2: Check RRAS Configuration

Verify that the VPN server and client configurations use the latest authentication and encryption protocols. If there are no related IPv6 address display configuration options, ensure other relevant settings are correct.

Step 3: Check and Record Logs

Even though you have enabled detailed logging and found that the IPv6 addresses displayed in the logs are incorrect, we recommend continuing to record logs. This helps further analyze and diagnose the issue.

Step 4: Use Network Monitoring Tools

You have already used Wireshark to verify the IPv6 address display issue, which is an important step. If the server is incorrectly displaying its own IPv6 address, this may indicate a more complex problem.

Step 5: Verify Configuration

Ensure that you use PowerShell commands to check the IPv6 configuration and confirm it is correct. Since you have already completed this step and verified it is correct, the issue does not appear to be with the configuration.

Thank you for your support of our forum!

Best regards,

Answer 5

Hi Rosa,

Again, your response does not make sense in light of my response I already sent to you.

@Gary Nebbett has kindly given an informative response, though it is not a solution, and has confirmed (if he is correct) the origin of the problem.

Could you please tell me how to report this as a bug to the Windows Server team?

Thanks,

Samuel