• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 695
  • Last Modified:

Cannot ping any device from the DC when a PPTP VPN connection is established.

This is interesting....I have a client where they currently cannot ping any device in the network if a VPN connection is established.

This all seemed to occur then I removed SEP from the DC as Network Threat Protection was preventing remote user from mapping drives to the file server, thou over night when I tried to connect to the file server to move files I noticed the mapped drive I had on the DC to the file server was not available, I tried to ping the file server and the default gateway but no good.

I disconnected my VPN session and I accessed the DC via logmein, ran a continuous ping test to the file server, then reconnected my VPN connection, this is where I notice the ping test stop responding, I then disconnected the VPN connection, the ping tests became successfully again..

I only found the below event in the log:
Event ID: 32009

Im thinking of reinstalling SEP but then I'll just be back to my original problem, thou the current situation is not a good one either.

If you require any logs\details attached please advise.

Please help! Thanks!!
0
neryre
Asked:
neryre
  • 8
  • 5
  • 2
1 Solution
 
eexchangetechCommented:
Goto VPN properties (control panel--Network Connections)>>>tab "Networking">>>TCP/IP properties>>>Advanced. Here, uncheck "Use default gateway on remote network"
0
 
Rob WilliamsCommented:
I assume a Windows/RRAS VPN?

Are you trying to ping by FQDN?  If so open the DNS management console and make sure the VPN adapter is not included under interfaces when you choose properties of the DNS server.

If pinging by IP fails, make sure NAT is not enabled in the RRAS console.
0
 
neryreAuthor Commented:
Hi exchangeTech - I followed your instructions on my client laptop but same problem occurred.

Hi Robwill - I ping by FQDN for the file server and ping via IP on the default gateway from the domain controller which is a Telstra modem.

I'm not sure what you mean by the "VPN adapter"?

I opened up DNS Manager and went to the "Interfaces" tab "Listen on" value is currently the ip address of the local server (Domain Controller). Does this look fine?
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
eexchangetechCommented:
1. After establishing the vpn connection, Open same properties and verify "Use default gateway on remote network" is still in UNCHECKED state. If it's so, proceed with below two points

2. Before establishing vpn, start CMD prompt>>> tracert <any IP on LAN>

3. After establishing vpn the ping, start CMD prompt>>> tracert <any IP on LAN>

Let me know the output, this way, we'll get to know how the connection is going out from the system
0
 
Rob WilliamsCommented:
>>"I opened up DNS Manager and went to the "Interfaces" tab "Listen on" value is currently the ip address of the local server (Domain Controller). Does this look fine? "
Yes it should show onlt 1 IPv4 IP and 2 IPv6 ips, which are all those of the server.  Assuming the Server is the VPN server (using RRAS) it will create a virtual adapter named PPP in an ipconfig.  You do not want this IP in the DNS interfaces list.

Can you confirm you are using RRAS and not the router as the VPN server?

I would do all testing by pinging using the IP for now.
0
 
neryreAuthor Commented:
Hi RobWill - I can confirm I am using RRAS as the VPN server. The router is just allowing pass-through to the server.
0
 
neryreAuthor Commented:
Ok, now this is strange...

I used a different account for the VPN credentials and while watching the server console via logmein and perform a continuous ping test from the server to the default gateway, the ping results come back fine and don't drop..

Looks like the account I used for vpn previous has some sort of a cause to the issue..Need to know why.
0
 
Rob WilliamsCommented:
The account needs to be granted permissions within RRAS, AD user account, and/or NPS (if used).  Might they be denied?  However if so they should not be able to connect.
0
 
neryreAuthor Commented:
Its really strange, this morning they have mail routing problems, I see mail pending in the queues, and remote users are have problems with vpn now..

Yet, last night everything looked fine, I tested with 2 remote users and they were able to log in and work. Ping testing from the DC to other devices in the office worked fine.

Question - If  I dont have SEP installed what other process could be using ipnat.sys? I was thinking Windows Firewall was causing this problem but each time i try to enable it, a message pops up saying another program is using ipnat.sys.
0
 
Rob WilliamsCommented:
If you try to enable the firewall when RRAS is enabled you will get an ipnat.sys error.  You cannot enable the firewall.

What server version is it?  Might it be SBS 2003?
What subnet does the server site use?  such as 192.168.1.x

With those other problems make sure NAT is not enabled in RRAS.
0
 
neryreAuthor Commented:
Its SBS2003, using subnet 192.168.81.x

Just rebooted the server, will check NAT in RRAS when it comes back up.
0
 
Rob WilliamsCommented:
SBS 2003 assumes 1 of two NIC configurations
1) a single NIC
2) 2 NIC's, one connected to LAN, the other connected to WAN and the server acts as the gateway/firewall for all PC's.
In configuartion 2 RRAS is enabled.  As a result when RRAS is enabled it assumes a 2 NIC configuration, the Windows firewall is not necssary, and posts an ipnat.sys error.

The subnet is fine, I had a long shot idea if it was a common subnet like 192.168.1.x or 192.168.0.x
0
 
neryreAuthor Commented:
Its only a single NIC config.

I cant see NAT config anywhere in RRAS console, so I'm assuming its not enabled when it was first setup.
0
 
neryreAuthor Commented:
I reinstalled SEP and modified the firewall settting in Network threat protection to allow access from the DC to the secondary server. All is good now, both servers are accessible via VPN.

The mail flow issue and VPN connection issue was due to the routers public IP being black listed on CBL, as the public ip is used for VPN pass thru and outbound mail.

Problem now is I cant find the infected machine CBL talks about, I've checked the firewall logs on the router, SEP logs but none of the IPs CBL mentions is identified. Will open a separate question for this, hopefully someone can help.
0
 
neryreAuthor Commented:
Fixed the issue with my own investigation.
0

Featured Post

Automating Your MSP Business

The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.

  • 8
  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now