PTravel

I have a PPTP VPN server on a dd-wrt flashed router that I've used for years. About three weeks ago it stopped working. I've tried everything including reflashing the router, trying another working dd-wrt with PPTP VPN server enabled, and various VPN clients on various computers and phones on other networks which I know don't block any ports. I have Cox internet. Cox claims they haven't blocked PPTP ports (1701, 1723 and 47) and, as best as I can tell from Google research, this is correct.

I can ping the router and also access it via VNC which it passes to a VNC client on my network. When I try to connect via VPN, the VPN client reports trying to connect and then failure. The Microsoft Win10 built-in client gets to "Verifying user name and password," and then cycles back to trying to connect. Needless to say, the username and password are correctly configured on both server and the various clients I have tried.

Any ideas about what is happening?

Please note: I am not looking for alternative methods of doing what I want to do, and I will try OpenVPN only as an absolute last resort. Please don't suggest alternatives, commercial services, etc. I just want to get the VPN server on my dd-wrt router working again.

Thanks!

nomad1972

Here are a few things I would look at:

1. Confirm the Cox modem didn't switch from bridge to routed mode. This can happen due to a remote pushed update or reset. Easiest way to do this is to login to the DD-WRT router and check the WAN IP. If it's in a non-routable subnet (10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, 192.168.0.0-192.168.255.255) then your modem is in routed mode. Contact Cox for instructions on how to put the modem back in bridge mode.

1a. If the router's WAN shows a non-routable IP and the modem doesn't have a routing or gateway mode or is already in bridge mode, there's a slight possibility Cox is testing CGN addressing on the local CMTS or node.

2. Create a test network where you connect the router's WAN port and the test client to the same physical network. Unless you have another router to act as a DHCP server you will have to set static IPs for both devices. Once this is done and the computer can ping the router's IP, attempt to establish a PPTP connection.

Good luck!

nomad1972

On second thought the "Verifying user name and password" status message would only appear once a connection has in fact been made to port 1723/TCP. You can use the Open Port Check Tool at https://www.yougetsignal.com/tools/open-ports/

If it comes back as "Open" the first two suggestions in my previous post can be ignored.

Ditto

Well I would go and have a look, in the following order:
1. Windows event logs
2. Your DD-WRT even logs and/or any extended logging it might have for the VPN server
3. If both fails to show anything, you may want to collect a packet capture from both your client and your DD-WRT router, this will show you if all traffic from your machine gets to the router or not, on your windows machine you could us wireshark, on the DD-WRT side you might need to use 'tcpdump' CLI command.

Loren Pechtel

Disagree--I've been on a 10.x.x.x IP with Cox for some time now, when I've tried to use a VPN it works as expected. Admittedly I'm doing it from a device (testing the VPN connection before traveling), not the router but that shouldn't matter.

Ditto

Actually, while it is indeed possible, it wouldn't usually work 'out of the box' and you will need to do 1 or 2 things to make it work:
1. Configure port forwarding/DMZ host to your router
2. Disable the provider router builtin PPTP/VPN termination, where applicable

PTravel

Thanks, Nomad.

It's not a Cox modem, it's my own. In any event, it's in bridged mode -- I checked. I checked the ports and the site reports 1723 closed. Just to be sure I checked 5900 (VNC) and it reports open. Is this Cox' problem?

Dodge DeBoulet

If you can ssh into the router, what do you get when you type:

# netstat -an | grep 1723

?

nomad1972

Before we point fingers at Cox, would you be able to run test #2 (put the router's WAN and the test client on the same physical network and subnet and try to connect)? We should really rule out the PPTP daemon and the firewall rules on the DD-WRT router as the culprit.

Dodge DeBoulet's suggestion is great, but we'll also need an iptables dump (iptables -L).

PTravel

Couldn't SSH, but could telnet. Nothing happened -- no error message, just nothing.

I can do this, but haven't had a chance to yet. I'll try it tonight.

The list was extensive, so I've posted it here:

http://www.paultauger.com/IPTables%20List.txt

Ditto

This generally means no service is listening on port 1723, if PPTP service was running you should have seen something like:
tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN
Edit: Actually can you remove the extra # at the beginning of the command?

If you can extend that to 'iptables -L -vn', we could at the very least see if there are matches to the ones pertaining to port 1723, which would help to some extent to rule out an issue with the provider

Also you could try and look at the syslog file, it might be at /tmp/syslog.log, so you can run:
tail -f /tmp/syslog.log

Then try to connect, and see if anything relevant is being logged.

Dodge DeBoulet

LOL. Ditto

So yeah, no service running == no VPN. It's not Cox, it's your router ... now to figure out why.

EDIT: Oops, assumed he knew to type only the bolded portion and not the hash, although the results would be identical if he didn't include the hash but has IPv6 enabled (or is running a very, very old dd-wrt)

PTravel

I did. I'm not a big Linux guy, but I knew that much.

I'll try both.

Thank you all very much for your help! I really appreciate it!

Dodge DeBoulet

Hey Paul, just double checking. The terminal capture that you had posted actually showed an attempt to run netstat after the iptables dump, but included an extra # at the beginning. I'm assuming you ran it again without the hash ... ?

nomad1972

This is GOOD. Nothing means an open TCP connection has been established and you can access 1723/TCP from the outside world. You can close the connection it by typing ^]

I have a strong feeling your PPTP daemon is up and running, as it does add a few entries to IPTABLES:

ACCEPT tcp -- anywhere anywhere tcp dpt:1723
logaccept tcp -- anywhere anywhere tcp dpt:1723
logaccept gre -- anywhere anywhere
logaccept gre -- 192.168.10.0/24 anywhere
logaccept tcp -- 192.168.10.0/24 anywhere tcp dpt:1723

A netstat dump as requested by Dodge DeBoulet will help further diagnose this.

Can you access the router logs? Are there any errors during the start of the PPTP daemon?