Any working PPTP VPN Server setup instructions out there?

I have been trying for some time to get a VPN server set up on my openwrt router. I tried OpenVPN, Wireguard and none of those work. I have recently had some success with PPTP using the instructions here:
but the instructions are bogus. I have followed the instructions to the letter, cutting and pasting, and the best I could get is a VPN that works locally - that is, if the client is on the same LAN as the server, it works, but External connections are refused.

So I am just asking if anybody knows of a working tutorial on setting up a PPTP VPN server on openwrt. This may be asking a lot, but if a VPN isn't an option, I will have to resort to a clear text channel to get the job done.

Why did these not work? Did you ask for help?

Are you certain that you have a public IP address on the WAN of your OpenWrt router? If you don't, you won't be able to setup a VPN at all.

PPTP should never be used anymore -- it is deprecated on most OS's already because it is not secure and it is considered unsuitable for use on the internet.

This seems like a really bad idea. What are you trying to achieve?

Hi, thanks for the reply. Yes, I tried OpenVPN and wireguard and neither of those would even run. PPTP is the only one that half worked at all.

Yes the WAN IP is very public. I have several port forwards to internal devices that work fine. It is a DDNS IP, but it works for everything else just fine.

There seems to be a lot of tutorials out there for making openwrt into a vpn client, but that isn't what I want. My phone is android 9 and it only supports pptp, ipsec and L2tp, so it would have to be one of those anyway.

The openwrt instructions for SSH were also bogus, but I was finally able to get them to work by modifying the config files. As such, it might be possible to tunnel with that, but I doubt it would be robust enough to do the job.. Again, the default SSH only works locally. I wanted to be able to use it from anywhere so that I could try to make the VPN work remotely.

It tricked me because it worked locally using the external WAN IP. So I end up on the other side of town before I realized it wasn't really working.

I saw some code the other day where a guy was able to tunnel over port 80 using his own clear text protocol. I will probably look into that.

Wireguard is supported on Android 5 and up. I'd highly recommend this path.

You didn't mention what your goal is -- what you are trying to achieve with this VPN. But remember that you need to also get your android device to support whatever you setup on your router, so aside from security implications, there is also a practicality element here. Wireguard works really well.

Maybe you could tell us what specific steps you followed with WG and where you had trouble.

Sorry, I forgot to mention my goal. I have two locations. One has a wired connection and mostly all open ports going in both directions.. The other is getting converted to a wireless 4G modem. The problem is that while the 4G carrier blocks zero ports going out, they block ALL ports coming back in due to their carrier grade NAT. Connecting natively, the best possible connection would be double NATted. So the goal is to use some sort of tunnel or VPN that would bypass the carrier's NAT and incoming port blocks by essentially sharing the wired site's IP address and connection.

Eventually, the goal would be to split tunnel at the 4G site because not everything needs to go over the VPN, but that will have to wait until the server is working.

I also explored using a commercial service, but surprisingly few actually support inbound ports any more. I used one years ago with windows XP and people were able to come into windows backwards through the vpn and bypass its firewall - definitely not cool. The few that still allow incoming ports do so in a tightly restricted and expensive manner. Many limit you to a single port which is not adequate,

Actually, I forget the exact steps with wireguard and openvpn. That was last week. I have been working on this problem for two weeks now so its time to give on those two. The closest I have come is with PPTP and it seems like there should be a way to get it to go the extra mile and allow connections from outside. I got an error message regarding GRE which is a subprocess it uses. It did not survive the last reboot so I will try to send that in a little bit when I can attempt a new connection.

I think I now understand the constraints, but I still don't quite know what you are trying to achieve on the 4G side. Are you trying to access devices/services on that network from a remote location? Is that access required just for you, or are you trying to open it to the world (i.e. a game server or other server/service that needs to be publicly accessible)?

I run an asterisk server and have IP cameras at the 4G site. I need to access them from the public internet.

Here is a copy of the logs when I try remote access:

Sat Jan 29 17:28:39 2022 pptpd[18434]: CTRL: Client control connection started
Sat Jan 29 17:28:39 2022 pptpd[18434]: CTRL: Starting call (launching pppd, opening GRE)
Sat Jan 29 17:28:39 2022 daemon.notice pppd[18435]: pppd 2.4.8 started by root, uid 0
Sat Jan 29 17:28:39 2022 pppd[18435]: Using interface ppp0
Sat Jan 29 17:28:39 2022 daemon.notice pppd[18435]: Connect: ppp0 <--> /dev/pts/0
Sat Jan 29 17:29:09 2022 daemon.warn pppd[18435]: LCP: timeout sending Config-Requests
Sat Jan 29 17:29:09 2022 daemon.notice pppd[18435]: Connection terminated.
Sat Jan 29 17:29:09 2022 daemon.notice pppd[18435]: Modem hangup
Sat Jan 29 17:29:09 2022 pppd[18435]: Exit.
Sat Jan 29 17:29:09 2022 daemon.err pptpd[18434]: GRE: read(fd=6,buffer=41f48c,len=8196) from PTY failed: status = -1 error = I/O error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Sat Jan 29 17:29:09 2022 daemon.err pptpd[18434]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Sat Jan 29 17:29:09 2022 daemon.debug pptpd[18434]: CTRL: Reaping child PPP[18435]
Sat Jan 29 17:29:09 2022 pptpd[18434]: CTRL: Client control connection finished

But you are the only one who needs access (or a limited number of people, not world accessible, right)?

How do you envision the connection flow happening. Obviously you cannot connect directly to the 4G site, so will you be connecting from some remote location to the wired connection and then having the wired location's router redirect to the 4G via the VPN?

Yes, worldwide access, but only for a small select group. For example, voip calling from a hotel room. Checking cameras remotely, etc.

Basically, I want the world to think I moved the voip server and cameras to the wired address. I can use a DDNS to make sure they get to the right spot. If done right, the voip clients need not reconfigure their equipment.

If push comes to shove, I suppose it would be possible to simply physically relocate the asterisk server to the wired location. It might be possible to force upload camera video to an FTP site, but that would be expensive in terms of data bandwidth. Another option for both would be to have a script poll a web server and ping any addresses found in order to open them up. This makes it excessively manual.

That said, I'm not sure what the cost of keep-alive packets with a VPN would cost in terms of bandwidth.

This would, by far, be the more optimal solution. Routing for VOIP servers can be tricky, and trying to relay through a VPN may not work well.

With respect to viewing the cameras, I'd suggest creating a VPN (using WG) which connects back to your wired connection. You can then use that same WG interface to connect from anywhere in the world back to your wired connection and then through to your cameras (so the traffic goes from say a mobile phone across the country > wired internet connection w/ WG > 4G internet connection w/ cameras). The router on the wired internet connection would be responsible for routing the traffic to/from the cameras when requested by the mobile device.

One guy on the other wireguard thread from last week suggested that I set up a VPS and then make that into a VPN server. If I did that, it would also be possible to move the asterisk server to the VPS. The problem is that there doesn't seem to be anybody doing that which means there might be a reason. Asterisk is very sensitive to latency issues, so if there is a problem, it might be because of that. The good news is that there is an option in the asterisk configs that causes it to make connections between two voip clients directly rather than going through the server.

That leaves the cameras. I think using wireguard on openwrt is hopeless, but I think its probably doable with a raspberry pi. Essentially, it would create a subnet and route that through the VPS/VPN. Anyhow, not the best.

I just wish Tmobile would fix the problem. There is no shortage of IPv6 addresses and no reason to NAT an IPv6 address. Right now, tmobile converts everything to IPv4 and then back again.

Why do you think that? I have multiple openwrt systems with wireguard working perfectly. And so so many others.

I never got wireguard to work after a week of trying. Maybe its a memory issue or its just not compatible with my hardware. The other router is v18-v19 I think running on a Linksys wrt1200ac. One guy on youtube said, incorrectly, that it was neccessary to upgrade to v20 before wireguard would work. During the upgrade process , the router got bricked. Fortunately that router is easy to unbrick. Eventually I got v20 on there and it simply wouldn't work as a router at all. No connection to the WAN in any capacity. So I had to reinstall the previous version which works fine as a regular router. Meanwhile, I installed wireguard with no problem, except that it doesn't work. If you go to luci->status->wireguard, nothing comes up.

The router I am on here at the wired server site is using v20, but has WAN access just fine. Except when you try to use a VPN. Its a netgear r6260. It is not unbrickable. I already bricked one and took it back because it was still returnable at the time. I suppose v19 might work better, but since it would likely destroy the router, I don't want to modify the kernel for any reason. On second thought, I should probably just throw it in the trash and get a raspberry pi for a router. Problem is, you can't buy them right now.

Unlikely. Wireguard has a pretty small memory footprint and is compatible with most (if not all) targets that are supported on OpenWrt.

Completely incorrect. Bad information, for sure. I've run OpenWrt as far back as OpenWrt 18.06.

I'm guessing you mean 21.02. If you attempted to keep settings when you upgraded, that would absolutely explain the problem. Otherwise, this is likely an issue with how you configured the router, not the version of OpenWrt (there are some wifi issues on some specific Linksys models, but wired should work perfectly).

Did you configure a Wireguard interface and add at least one peer config?

What do you mean by this? When you setup a VPN, are you saying that WAN access stops working?

You should be using 21.02 on all hardware that supports it. 19.07 is going to be EOL soon and thus unsupported from a security standpoint. I'm not sure what you mean - "destroy the router" -- in what sense?

The Pi4 makes an excellent wired router. Terrible for wifi, though. But the R6260 and the WRT1200AC are both solid devices and there is likely no reason to change those out.

I honestly think the issue is that you are not configuring them properly for what you want to do. Please trust that I am not saying this in a condescending way, but rather that there is a learning curve for some of these things. The good news is that this forum is here to help.

I'd strongly recommend that you start by installing OpenWrt 21.02 on both of your routers if you want to link them together with a VPN. Then, on the wired ISP side, you can setup WireGuard and verify that it is working using WG on a mobile phone. Once that is validated, you'll know that you can setup the 4G side to connect back to the wired connection and you should be golden from there. We can help along the way. Trust me, it can (and does) work.

when I went to the latest verison on the linksys it bricked the router. I had to load ddwrt, then factory, then back to v18 with numerous debrickings along the way. I had backed up the config so it was easy to restore once I got to that point. Then I loaded wireguard and the stuff the tutorials say and then nothing.

I tried the latest openwrt again and managed to get it on there and running, but no wan access. It had a configured interface, but nothing got in or out. Clearing the settings while loading didn't help. So its back to v18.

My phone does not work with WG natively. Maybe there is an app for that. Any recommendations?

The wrt 1200ac is a decent router, but the r6260 is junk. I would never recommend or buy one again, Its been nothing but trouble. Even right now, I have a roku 30 feet away that can barely pick up the wifi. The factory firmware was literally painful to work with it was so bad.

I wish they would put more tomato firmwares out there. I had it on older routers and it was awsome. If you want a VPN, just check the box and click save and you're up.

Anyhow, it doesn't look like there will be a working VPN on this router. I do have a Raspberry Pi v2 board that I could experiment with. Then once they start shipping Pi4's again, I can just swap the SD card into the Pi4. No such thing as bricking a Pi. Just replace the SD card with a fresh one.

There could be a large number of reasons for this experience. Without details, it is impossible to say what was causing it. If you want to start over and try again, we can help you get up and running on 21.02

No phones “natively” support wireguard, but there is an official app “wireguard” that you can get from the iOS and Android App Stores.

Again, seems like you are just giving up. If you have openwrt on your router, wireguard really can work.

Well I need to close it out for tonight, but if you would be around tomorrow, I would be willing to give wireguard another try for the r6260 router. Its currently running OpenWrt 21.02.0 r16279-5cc0535800 / LuCI openwrt-21.02 branch git-21.231.26241-422c175, but because of the risk, I would not be willing to modify the kernel - only config files and gui settings. Unlike the Linksys, once this router gets bricked, it will stay that way.

BTW, I just loaded wireguard on my phone, but I am fresh out of QR codes and config scripts. The only plausible option is to config manually. So at least it looks like it might work from that end as a client.

Just to confirm, this is on the wired ISP side, right? (not the 4G connection).

I am happy to help when time permits. I won't be online in the morning (Pacific time, USA), but I should be in the afternoon.

It is really a low risk process, but WG will be fine on 21.02.0, so sure we can stick purely to the related settings and leave the version as is.

I'm not exactly sure what this means ("fresh out of QR codes and config scripts"). But best to setup the phone after the router, and it is possible to have the router generate QR codes for the phone's config, if you so desire. That said, "manual" configuration is pretty simple.

Fundamentally, start by installing the wireguard packages

opkg update
opkg install kmod-wireguard luci-app-wireguard luci-proto-wireguard wireguard-tools

Then you'll generate a keypair, and then a network interface for wireguard. A few quick things in the firewall -- I like to create a unique firewall zone for the WG interface, and you'll need to open a port in the firewall for WG to allow inbound connections from the WAN. Finally, create a peer config for your phone, and then setup your phone with the appropriate key exchange and you should be able to connect.

I'm in FL so that puts me about 3 hours ahead of you. I went ahead and loaded the pkg stuff you said above. Rebooted. Down to 5Mb RAM.

I followed the WG tutorial you linked above. It now generates a QR code, but I had to load the module qrencode. which none of the tutorials said to load. I used the wireguard program on the phone to capture the barcode and it allowed me to configure a connection. I did and it wanted an IP address. I put in the DDNS name and it rejected it. It wants a static IP which I don't have. I used the current IP of the server and it took it and seemingly made a connection, but it didn't work. The phone cannot connect to anything when the VPN is running on the phone. Also, the openqrt wireguard page says "Latest Handshake: Never" which tells me that it never actually connected.

So at this point, wireguard has less connectivity than pptp. At least with pptp I could connect to the VPN from the local vpn server wifi. With wireguard, I can't connect from anywhere.

Most of the RAM was chewed up by samba not wireguard. Probably about 50MB worth. I've never seen Samba take that much before, but it did here.

Because of the time difference, I may be leaving here about the time you are coming on line. However, this is why I was insisting on getting SSH working remotely. I'm new to SSH, but as long as it lets me telnet in remotely and get a command prompt, I should still be able to get something done. Hopefully not the kind of something that results in me having to drive all the way back here at 2 AM to swap out routers.

Anyhow, just to be clear, here are the things I need the VPN server router (wired) to accomplish, for now, just assume that we are just talking about my phone and the wireguard app as the client....

  1. Must not interfere with the normal operation of the wired router. So the router and its existing port forwards must operate locally just like they always did. Both LAN and WLAN devices must retain the same local static IP's they have now.

  2. VPN Clients connected into the wired VPN server router will appear to the public like they are coming from the same public IP as the wired server router.

  3. The VPN clients will also have access to the wired router's LAN as if they were physically connected. So while they are connected to the VPN, they would have access to the router's web page and printers, etc.. Most likely, but not required, this means they would get their local IP from the VPN server router.

  4. Incoming connections to the wired VPN router server will be selectively forwarded, based on port number, to the VPN client machine. This means that VPN clients must be assigned a static IP from the VPN server local LAN pool. It must be possible to run any server, such as a web server, on the client side and have it appear to the public that it is running at the wired router location. Simultaneously, the VPN router server will forward other specific ports to its local devices as required by #1. That is, it would be possible to forward port 10 to a local IOT device, and port 11 to a device at the VPN client.

  5. The VPN system must be able to effectively bypass the carrier grade NAT on the client side. This must be done in a way that doesn't run up the data bill on the client side.

  6. The VPN system must not require static public IP addresses and must work, if required, with DDNS names.

NOT required at this time, but will be later,,,,

  1. The future 4G client will be another single OpenWRT router that will connect only specific devices to the VPN. This is so that only devices that absolutely must be on the VPN will be connected to it. Some of the VPN connected devices are dumb devices that have no concept of VPNs or IPv6. If a device is connected to the VPN, it is full time and will not be switched on and off the VPN.

  2. For client router devices that are not connected to this VPN, the OpenWRT router must pass normal traffic and act as a normal router including the ability to pass other peoples VPN traffic not related to our wired VPN router.

Lastly, my security goals are not to hide my content, but rather to prevent unauthorized folks from getting in and messing with my stuff.

Did I say how much I miss Tomato's one click VPN? I hope the OpenWRT developers are reading this. It shouldn't be this hard to set up a VPN, or SSH, or Parental Controls, or guest access. If you look at the forum listings, you'll see that I'm not the only person having trouble with these things.