Windows server 2019 не работает интернет

Всем привет. В организации инет приходит на сервер и раздаётся им по локальной сети. Всего в сети около 50 компьютеров. Подключены через коммутаторы. Раньше всё работало нормально, но у сервера накрылся жёсткий диск. Переустановил ос (Windows Server 2019), настроил подключение сервера к инету. Расшарил его через свойства подключения -> доступ -> разрешить другим использовать подключение к интернету. Создал общую папку на сервере для обмена файлами. DNS, DHCP не настраивал. ip на всех компах прописал вручную. В целом всё работает, но периодически на некоторых компьютерах пропадает инет и теряется доступ к общей папке. Лечится перезагрузкой сервера. Подскажите в чём может быть причина и как исправить?

• 
  Вопрос задан
  
  более трёх лет назад
  

• 592 просмотра

We had a really weird issue on a clients domain server recently that wasted a lot of time trying to get to the bottom of, so I thought I’d document that here to save you the same fate.

We had logged onto the clients domain server and opened Google Chrome to browse to a local network device to administer it via a HTTP UI. We typed in the IP of the device into the address bar and received the dreaded «This site can’t be reached» error message.

Initially we thought the device might be switched off or removed from the network, so to test, we pinged the device to see whether it was in fact accessible. Yes, the device replied without issue. Hmmm, that’s weird. So I opened up a new tab to see whether I could surf the internet, once again I received the «This site can’t be reached» message.

I pinged other devices on the network and they were all responding without issue. I pinged Google via the command line and it responded and resolved correctly, so this wasn’t a DNS issue. I cleared the cache of the browser, flushed the DNS and cleared the cache of the Windows DNS server and the DNS cache of the firewall, closed the browser and re-open and still the same result. What’s going on here?

The server was a domain server as outlined earlier, and it was still serving the local network without issue and clients could connect to file shares hosted on the server, resolve DNS requests for both local and internet locales and nothing was impacted from what I could see.

Time to execute some more advanced remedial action like resetting the network settings. Please be aware that this needs to be done outside of business hours because the server will require a reboot. These are the commands I executed via an admin command line instance:

netsh winsock reset
netsh winhttp reset proxy
netsh winhttp reset tracing
netsh winsock reset catalog
netsh int ipv4 reset catalog
netsh int ipv6 reset catalog

After I rebooted the server, the same issue was still evident. Wow! Because this was a VM running under ESXi I thought that maybe the NIC had some type of issue, so I shut down the server and removed the NIC and re-added to ensure this wasn’t the problem. Still no joy!

So how was this rectified I hear you ask? The issue ended up being resolved by resetting Internet Explorers settings. This can be done by following the screenshots below:

Open Control Panel then:

Картинка с сайта: www.matrix7.com.au

Картинка с сайта: www.matrix7.com.au

Картинка с сайта: www.matrix7.com.au

Once you’ve completed the steps above, close all browsers. Now re-open your browser and you should be able to access the everything normally through the browser. This was a very easy fix in the end, but took a long time to come to the eventual remedy. I hope this saves you some time.

If you’ve found this useful, you may want to sign up to our newsletter where you’ll receive notices on when we post new articles and helpful «how tos». Just fill out your details below and we’ll do the rest…

POCO, ACE, Loki и другие продвинутые C++ библиотеки

NullReferenced 13.05.2025

В C++ разработки существует такое обилие библиотек, что порой кажется, будто ты заблудился в дремучем лесу. И среди этого многообразия POCO (Portable Components) – как маяк для тех, кто ищет. . .

Паттерны проектирования GoF на C#

UnmanagedCoder 13.05.2025

Вы наверняка сталкивались с ситуациями, когда код разрастается до неприличных размеров, а его поддержка становится настоящим испытанием. Именно в такие моменты на помощь приходят паттерны Gang of. . .

Создаем CLI приложение на Python с Prompt Toolkit

py-thonny 13.05.2025

Современные командные интерфейсы давно перестали быть черно-белыми текстовыми программами, которые многие помнят по старым операционным системам. CLI сегодня – это мощные, интуитивные и даже. . .

Конвейеры ETL с Apache Airflow и Python

AI_Generated 13.05.2025

ETL-конвейеры – это набор процессов, отвечающих за извлечение данных из различных источников (Extract), их преобразование в нужный формат (Transform) и загрузку в целевое хранилище (Load). . . .

Выполнение асинхронных задач в Python с asyncio

py-thonny 12.05.2025

Современный мир программирования похож на оживлённый мегаполис – тысячи процессов одновременно требуют внимания, ресурсов и времени. В этих джунглях операций возникают ситуации, когда программа. . .

Работа с gRPC сервисами на C#

UnmanagedCoder 12.05.2025

gRPC (Google Remote Procedure Call) — открытый высокопроизводительный RPC-фреймворк, изначально разработанный компанией Google. Он отличается от традиционых REST-сервисов как минимум тем, что. . .

CQRS (Command Query Responsibility Segregation) на Java

Javaican 12.05.2025

CQRS — Command Query Responsibility Segregation, или разделение ответственности команд и запросов. Суть этого архитектурного паттерна проста: операции чтения данных (запросы) отделяются от операций. . .

Шаблоны и приёмы реализации DDD на C#

stackOverflow 12.05.2025

Когда я впервые погрузился в мир Domain-Driven Design, мне показалось, что это очередная модная методология, которая скоро канет в лету. Однако годы практики убедили меня в обратном. DDD — не просто. . .

Исследование рантаймов контейнеров Docker, containerd и rkt

Mr. Docker 11.05.2025

Когда мы говорим о контейнерных рантаймах, мы обсуждаем программные компоненты, отвечающие за исполнение контейнеризованных приложений. Это тот слой, который берет образ контейнера и превращает его в. . .

Micronaut и GraalVM — будущее микросервисов на Java?

Javaican 11.05.2025

Облачные вычисления безжалостно обнажили ахиллесову пяту Java — прожорливость к ресурсам и медлительный старт приложений. Традиционные фреймворки, годами радовавшие корпоративных разработчиков своей. . .

If your Windows Server 2019 is both a domain controller and a Remote Access (VPN) server, you might find that users can connect to the VPN but cannot reach mapped drives, databases, or the internet. This article covers why these issues occur and how to fix them.

TOC

Why Understanding Your VPN Configuration Matters

When configuring a Windows Server 2019 environment to serve both domain controller and VPN roles, networking complexity skyrockets. Multiple services—Routing and Remote Access, DNS, NAT, and more—all need to work together seamlessly. If any one of these services is misconfigured, VPN clients will encounter limited or no connectivity to internal or external resources.

The Typical Symptoms

• Users successfully connect to the VPN, but mapped network drives are inaccessible.
• Applications relying on SQL or Sage databases fail to connect.
• External websites and services are unreachable once the VPN is active.

These problems often trace back to issues with DNS resolution, firewall policies, or improper routing settings such as missing NAT rules or incorrect gateway assignments.

Core Services Involved

Before diving into solutions, it’s important to identify which components can cause problems:

1. Routing and Remote Access Service (RRAS)
2. DNS configuration on the domain controller
3. Windows Firewall (both inbound and outbound rules)
4. NAT and internet gateway settings on the server
5. Client VPN configuration (split tunneling vs. full tunneling)

Delving into Key Problem Areas

Below are the most common culprits behind limited or no connectivity once a VPN tunnel is established.

1. RRAS Configuration Mistakes

Routing and Remote Access Service is the backbone of VPN functionality in Windows Server. It handles both inbound and outbound traffic for VPN users.

Split Tunneling vs. Full Tunneling

Split tunneling allows VPN clients to access internal resources through the VPN while still sending regular internet traffic through their local network. Full tunneling, on the other hand, forces all traffic—including internet requests—through the VPN server.

If you configure RRAS for split tunneling but do not adjust policies or routes correctly, some traffic might unintentionally be dropped. Conversely, if full tunneling is in place, you need NAT or routing rules to provide internet access.

VPN Subnet Configuration

RRAS needs to assign a valid IP address range to VPN clients. Ensure the IP range does not overlap with any other existing network in your infrastructure. Overlapping subnets lead to routing conflicts, causing the server (and VPN clients) to get confused about how traffic should flow.

2. DNS Settings and Name Resolution Issues

DNS is pivotal to everything from domain authentication to accessing internal websites or servers by name.

Internal DNS Configuration

• Make sure VPN clients use the domain controller’s DNS address for internal name resolution.
• Configure DHCP or static IP pool options to push the correct DNS server address to VPN clients.

External DNS Forwarding

Your domain controller (or another DNS server) should forward external DNS requests to a public DNS service (e.g., 8.8.8.8) if it acts as the primary DNS for VPN clients. If external name resolution is not properly forwarded, users may be able to ping an external IP but not resolve domain names.

Ensuring Access to Internal Resources

Once VPN clients are connected, they might still face issues accessing network shares, SQL databases, Sage applications, or any internal app. The underlying reasons can be misconfigured permissions or routing blocks.

3. File Shares and Database Permissions

Mapped drives and databases require:

• Correct user permissions: Confirm that the domain user or security group for the VPN clients has appropriate NTFS/share permissions.
• Proper firewall exceptions for SMB (TCP ports 445, 139), SQL (default port 1433), or Sage (depends on version and custom ports).
• Matching server/client subnets: If the VPN clients are on a 192.168.10.x subnet and your domain environment is on 192.168.1.x, then your routing must be set to allow traffic between these networks.

4. Firewall and Advanced Security Rules

A strict firewall configuration on the VPN server can easily block necessary inbound or outbound ports. Besides the standard rules for VPN protocols (PPTP, L2TP, SSTP, or IKEv2), make sure:

• DNS (UDP/TCP 53) traffic is permitted from the VPN subnet.
• SQL server ports (e.g., 1433) are allowed for the VPN subnet or range of IPs assigned to VPN clients.
• Fileshare ports (TCP 445, TCP 139) are open specifically for VPN client IP ranges.

Always double-check that the Windows Firewall in advanced security mode has the correct scope. If you only allow local subnet traffic, you might be inadvertently blocking VPN subnets.

5. NAT Configuration (If Acting as an Internet Gateway)

When the Windows Server 2019 box provides internet to VPN clients, it must have NAT enabled. Essentially, the server “translates” the VPN client’s IP into the external interface’s IP.

Without NAT, VPN clients might only see internal resources but not external sites (or vice versa, depending on your specific routing rules).

Client-Side Configurations and Considerations

In many cases, the server side is perfect, but the client side might not be set up to route traffic appropriately.

6. Use of Remote Gateway

On a Windows client VPN, the checkbox “Use default gateway on remote network” in the TCP/IPv4 properties decides whether internet traffic is routed via the VPN tunnel. If you do want all traffic going through the VPN (full tunnel):

1. Enable “Use default gateway on remote network.”
2. Confirm NAT is properly configured on the server side.
3. Ensure DNS queries for external domains are resolvable via the VPN’s DNS server or forwarder.

If you prefer split tunneling to keep local internet usage direct, uncheck “Use default gateway on remote network” and configure a static route or specific routes to your internal subnets. This approach is more complex to maintain but can optimize performance for remote users.

7. Security Policies and Domain GPO

Group Policy Objects (GPOs) applied to domain-joined machines can sometimes override local VPN adapter settings. If you have a GPO that forces a specific DNS or gateway assignment, verify that it does not conflict with the manual settings you’ve configured for your VPN.

Testing and Troubleshooting Methods

It’s important to methodically test each possible culprit. Below are common tools and procedures that pinpoint where connectivity breaks down.

8. Ping and Traceroute

Ping internal FQDNs (e.g., servername.domain.local) to confirm:

• DNS resolution is working.
• ICMP traffic is permitted.

If ping works by IP but not by hostname, DNS is the problem.
Use tracert (or traceroute on non-Windows devices) to see each network hop. This helps identify whether traffic is routed to the correct gateway or dropping at the firewall.

9. Event Viewer & RRAS Logs

In the Windows Event Viewer:

• Check System logs for RRAS or network-related errors.
• Check Application logs for DNS or other service-specific errors.
• Review Security logs if you suspect an authentication or permission issue.

Additionally, RRAS logs (if enabled) can show connection attempts, assigned IP addresses, and any immediate disconnections or route failures.

Step-by-Step Guide to Fix Common Issues

Below is a structured approach to resolving the most typical problems.

Step 1: Verify Server Roles and Services

1. Confirm that your Windows Server 2019 is properly configured as a domain controller and is fully functional (check Active Directory, DNS).
2. Ensure RRAS is installed with the VPN role. Check that the service is running from the Services management console.

Step 2: Examine RRAS Settings

1. Open Routing and Remote Access in Server Manager.
2. Right-click your server name, select Properties, then go to the IPv4 tab.
3. Check the IP address assignment method. If you use DHCP, ensure your DHCP server has enough IP addresses for VPN clients. If using a static address pool, confirm it’s not overlapping with any internal subnets.

Step 3: Configure NAT (If Applicable)

1. Under IPv4 in RRAS, expand NAT.
2. Right-click your external network interface, select Properties, and ensure Public interface connected to the internet and Enable NAT on this interface are checked.
3. Confirm your internal interface (or the interface dedicated to VPN) is set to Private interface connected to private network.

Step 4: Validate Firewall Rules

1. Launch Windows Defender Firewall with Advanced Security.
2. Check inbound rules for:

• File and Printer Sharing (SMB-In)
• SQL Server (if needed)
• DNS Service (TCP/UDP 53)
• PPTP/L2TP/SSTP or IKEv2 (whichever VPN type is used)

1. Check outbound rules to ensure the server itself can access external DNS or any other external services required.

Step 5: Double-Check DNS Configuration

1. On your domain controller, open DNS Manager.
2. Under Forwarders, make sure you have at least one forwarder for external DNS resolution (e.g., 8.8.8.8).
3. For internal DNS zones, confirm that the VPN IP range is configured so that queries from these addresses are resolved.

Step 6: Configure Client VPN Settings

1. On a Windows client, open Network Connections, right-click the VPN adapter, and select Properties.
2. Under Networking → IPv4 → Properties → Advanced, decide whether to Use default gateway on remote network.
3. If you disable Use default gateway on remote network, define static routes to reach internal subnets via the VPN. Alternatively, rely on DHCP-based static routes if configured on the server.

Additional Best Practices

Security Considerations

• Least Privilege Principle: Restrict VPN users to the minimum network shares or servers they need to do their jobs.
• Monitor Logs: Regularly check Event Viewer and firewall logs for suspicious activity. VPN portals are frequently targeted.
• Multi-Factor Authentication: Consider adding MFA for VPN connections if compliance or high security is required.

Performance Optimization

• Load Balancing: If the user count or data throughput is high, consider offloading some services to dedicated servers (e.g., a dedicated NAT or a separate domain controller).
• Regular Updates: Keep Windows Server patched to avoid known bugs in RRAS or DNS functionalities.

Testing with Different Scenarios

• Use Various Clients: Test with Windows 10, Windows 11, and other OS clients if supported. Different operating systems might interpret VPN settings differently.
• Check from Different Networks: Confirm that remote users connecting from coffee shops, home ISPs, or mobile hotspots get the same expected experience.
• Isolate One Variable at a Time: Turn off the firewall momentarily (in a secure test environment) to see if connectivity immediately returns, pinpointing a firewall rule as the culprit.

Common Troubleshooting Table

Here’s a quick-reference table for identifying the root cause based on the user’s symptom:

Conclusion

When your Windows Server 2019 handles both domain services and VPN connectivity, it’s crucial to ensure that RRAS, DNS, NAT, and firewall configurations all align with your intended traffic flow. Whether you prefer split tunneling or full tunneling, set up your routes, DNS, and NAT correctly to maintain seamless access to both internal and external resources. Thoroughly test each layer of your network to uncover and resolve issues swiftly. With a methodical approach—verifying RRAS, DNS, firewall rules, and NAT—you can achieve a fully functioning VPN that ensures productivity for remote users.