windows 10 1803 & server 2012 r2 (vpn pptp issue)

T

troyquigley

Guest
my vpn was working just fine, and I had the stupid idea of adding
L2TP

"allow custom ipsec policy for L2tp/IKEv2 connection"
it did not work, because I will have to made some changes to the firewall.

so i unchecked the box for L2TP and tried to use PPTP again.

I can connect just fine, but as soon as the vpn connects I am unable to access or ping any remote resources.

the vpn connection says "connected"

the internet connection says "no internet, secured"

if i disconnect the vpn connection, the internet connect goes back to "connected, secured"

how do i undo the L2TP issue i created ?
 
i do an ipconfig on the laptop

i have an ipv4 address
subnet mask is: 255.255.255.255
default gateway: 0.0.0.0
and the dns servers are the correct dns servers at the remote site
 
I have all the firewalls turned off (on the laptop).

I have even tried unchecking "use default gateway on remote network"
this made it so both the internet and the vpn connection still said "connected"

BUT

i still could not ping or see any remote resource
 
routing and remote access

ports

all of the ports status is: inactive

should not some be active - if so - which one for PPTP ?
 
It's not clear if you made just server changes or just laptop changes or changes on both.

Sometimes once it's fubared you need to just kill the whole VPN config and then redo it.

You need port 1723 and the GRE service allowed on the firewall of the hosting side.
The firewall on the laptop should pass that traffic and not need anything special.

.
 
i have made zero changes to the firewall, and it was working 2 days ago. the only thing i have done was try to add L2TP. then i just unchecked the L2TP box.
 
How do I delete my current vpn and start from scratch ?
without screwing anything else on my server
 
Last edited by a moderator:
Did you setup the VPN on your server?

If you did the setup, then do it again.
If you did not do the setup then ask the person who did to fix it.

.
 
That ip setup for the VPN looks wrong. Connect the VPN and run the folling:

-ipconfig /all
-route print

Let me know the output. But it looks like your issue is the ip config on the VPN adapter, or not adding the route correctly.
 
ppp adapter VPN_Company

dhcp enabled = no
autoconfiguration enabled = yes
ipv4 address = 192.168.0.x (preferred)
subnet = 255.255.255.255
default gateway = 0.0.0.0
dns servers = 192.168.0.x
netbios over tcpip = enabled
 
i disabled "routing and remote access:" on the server
then re-enabled routing and remote access

still same issue
 
Last edited by a moderator:
Last edited by a moderator:
is there a way to check "GRE" and see if if is messed up on the server >?
 
Do you have unique subnets on either side of the VPN?

If they are both 192.168.0.x the VPN will connect but no traffic will be routed over the VPN.

ETA: It's been a while since I setup VPN on a server, I prefer to do it on the firewall/router. Anyway, there
can also be a problem with a domain policy not allowing traffic from an outside subnet. I remember
having to fix that once or twice over the years. Should not be an issue if it was working before though.

.
 
Last edited:
Fixed !!!

A Server Reboot. Everything works again.

If the original changes did not ask for a reboot, why would reversing the changes require a reboot.

Either way: I can now connect via the VPN and see the remote resources.
 
Registry changes, .dll's get loaded/unloaded, etc. with config changes.
Standard procedure to reboot a machine when the config changes even if no reboot is requested.

It's a shame to waste so much time when that's all it was.
Can't beat you up too bad though..... have done that myself.


.
 
troyquigley said:
yeah.

BUT.....

i reboot a server as a last resort...
Click to expand...


And this experience of yours is a perfect example of why that is not a very smart policy.
Sorry if that sounds brutal, but you have to learn from your mistakes to move forward.

I don't go easy on myself either when I make dumb mistakes.
That policy helps me to make far fewer dumb mistakes.


.
 
When there are only 2 people that need remote access, and neither needed it that week, there was zero reason to take the server down.

Maybe where you work, taking down a server is not a big deal. If there is no emergency, taking the server down is always a last resort.
 
I understand.

In those cases, it can usually be done after business hours or on a weekend.

Sorry if I was a bit harsh..... it just drives me nuts when people are so resistant to rebooting a machine
where the config was changed and "now it's not working".

Reboots work like magic sometimes. :)

.
 
On workstations, rebooting is one of my 1st efforts.

My servers automatically shutdown each sunday. I knew that the server would be rebooted by monday, the day I had to have it up and running. It was a very valuable lesson. Just because the server does not say it needs a reboot - it just MAY. LOL
 
troyquigley said:
On workstations, rebooting is one of my 1st efforts.

My servers automatically shutdown each sunday. I knew that the server would be rebooted by monday, the day I had to have it up and running. It was a very valuable lesson. Just because the server does not say it needs a reboot - it just MAY. LOL
Click to expand...


That's the entire reason behind the IT Crowds "Have you tried turning it off and on again".... It something is not working, you don't see any config issues/changes or errors in the logs, and no one is using the box, reboot. That way you know all configs/drivers were loaded correctly, or they should throw log error that you can use to diagnose the issue further. Plus the fact that 'only 2 users need the service, and weren't using it this week' is exactly the time you want to reboot. It's production boxes being used 24/7 that make finding a window to reboot difficult. In this situation, a reboot should have been one of the diagnostic steps taken very early in the process.
 
You must log in or register to reply here.
Back
Top