Windows Server 2019 Inaccessible after subnet mask growth

Question

We have a network that's running low on space, so we expanded our subnet in place from a 10.0.1.0/24 to a 10.0.0.0/20 subnet. This change worked on all of our networking equipment and Windows servers except for one particular Windows Server 2019 instance that runs MS SQL Server 2018. All of our Windows servers are virtualized under ESXi 7.0.1. The server in question has a static address. If the subnet mask is changed, then it can no longer be accessed over RDP or SQL. I can revert the subnet mask and it works fine again. Ping works perfectly fine over the IP address and DNS. The server can access the internet and other network resources from its own GUI.

We've left the firewall completely disabled for testing and opened the necessary ports for the SQL instances and RDP on all profiles. We've cleared the ARP cache, flushed dns, registered dns, and swapped the virtual NICs in ESXi.

We've had other phantom issues with this server as well which is why we're forced to keep the windows firewall down. Turning the firewall on completely breaks access as well despite all the necessary ports being open on the right profiles. We have taken into account that we're using non-standard SQL ports since we have 2 instances running for different SQL aware programs, and those additional ports were opened in the firewall as well.

Does anyone know what else could be the problem here? I have to admit that I'm at my wits end here. I would install a new server and port the data over, but an MSP whom I shan't name didn't give us access to product keys when the server was purchased. I have to fix things in place if it's possible. What's really confusing me here is the same change worked without issue on 3 other Windows servers, 2 of which are also Server 2019.

Answer 1

Hello Jared,

It sounds like you're facing a tricky network issue with your Windows Server 2019 instance after expanding your subnet mask. Given that other servers are functioning correctly with the new subnet mask, and considering the specific symptoms and troubleshooting steps you've already taken, here are some potential solutions and additional troubleshooting steps:

Potential Solutions:

1. Check Static IP Configuration:
   • Ensure that the static IP configuration on the problematic server correctly reflects the new subnet mask (255.255.240.0 for a /20 network).
   • Verify that the default gateway is correctly set and falls within the new subnet range.
2. Network Binding Order:
   • Ensure that the network adapter binding order prioritizes the correct NIC. Sometimes, incorrect binding order can cause connectivity issues.
   • Go to Control Panel > Network and Sharing Center > Change adapter settings > Advanced > Advanced Settings and adjust the binding order if needed.
3. Check Routing Table:
   • Check the server's routing table to ensure there are no conflicting routes. Use the command route print to view the current routing table.
   • Look for any old or incorrect routes that might conflict with the new subnet configuration.
4. **Update Network Adapter Drivers**:
   • Ensure that the network adapter drivers are up to date. Sometimes outdated drivers can cause issues with new network configurations.
5. DNS Configuration:
   • Verify that DNS settings are correctly configured. Ensure that the DNS server IP addresses are within the correct subnet and are reachable.
   • Try flushing the DNS cache again (ipconfig /flushdns) and re-registering the DNS (ipconfig /registerdns).
6. Check ESXi Network Configuration:
   • Verify that the virtual switch and port group settings in ESXi are correctly configured to handle the new subnet.
   • Ensure that there are no VLAN or network segmentation issues within the ESXi configuration that might be affecting the server.
7. Firewall Rules and Network Profiles:
   • Even though the firewall is disabled, re-check the network profiles and ensure that there are no hidden rules or policies applied.
   • Consider enabling the firewall and explicitly setting rules for RDP and SQL ports. Sometimes, disabling the firewall completely can cause unexpected behaviors.
8. Event Viewer Logs:
   • Check the Event Viewer logs for any network-related errors or warnings that might provide more insight into what’s happening when the subnet mask is changed.

Additional Troubleshooting Steps:

1. Network Monitor Tools:
   • Use network monitoring tools like Wireshark to capture and analyze the network traffic. This can help identify if packets are being dropped or if there are any unusual network behaviors when the subnet mask is changed.

2.Test Connectivity with Different Protocols:

• Test connectivity using different protocols (e.g., ICMP, TCP, UDP) to see if the issue is specific to certain types of traffic.

3. Reconfigure Network Interface:
   • Consider temporarily assigning a different static IP within the new subnet range to see if the issue persists.
   • Recreate the network interface configuration from scratch if possible.
4. Server Health Check:
   • Perform a comprehensive health check on the server, including checking for any pending Windows updates, ensuring that the server has no hardware issues, and that all services are running correctly.

Consider Migration:

Since the server in question has been showing other phantom issues and given that you've had to disable the firewall completely, it might be worth considering a migration despite the challenges with the product keys. You can use tools like Microsoft’s Assessment and Deployment Kit (ADK) or other third-party tools to assist with migration and data portability.

Conclusion:

If these steps do not resolve the issue, it may be worth engaging with Microsoft support or a specialized network consultant to further diagnose and resolve the issue. Sometimes, deeply embedded configuration issues can be challenging to diagnose without hands-on investigation.

Best regards

Rosy