strange PPTP crashes

[nickolasm5]

AC 86U 386_12_2

Jul 10 02:44:27 kernel: pptpctrl[15095]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Jul 10 02:44:27 kernel: pgd = ffffffc01311c000
Jul 10 02:44:27 kernel: [00000000] *pgd=00000000124d3003, *pud=00000000124d3003, *pmd=00000000116e1003, *pte=0000000000000000
Jul 10 02:44:27 kernel: CPU: 0 PID: 15095 Comm: pptpctrl Tainted: P O 4.1.27 #2
Jul 10 02:44:27 kernel: Hardware name: Broadcom-v8A (DT)
Jul 10 02:44:27 kernel: task: ffffffc01402b4c0 ti: ffffffc012b74000 task.ti: ffffffc012b74000
Jul 10 02:44:27 kernel: PC is at 0xf741a4a8
Jul 10 02:44:27 kernel: LR is at 0xffcf7e03
Jul 10 02:44:27 kernel: pc : [<00000000f741a4a8>] lr : [<00000000ffcf7e03>] pstate: 20070010
Jul 10 02:44:27 kernel: sp : 00000000ffcf7dc0
Jul 10 02:44:27 kernel: x12: 00000000000238fc
Jul 10 02:44:27 kernel: x11: 00000000ffcf7df8 x10: 0000000000000008
Jul 10 02:44:27 kernel: x9 : 0000000000000008 x8 : 0000000000000007
Jul 10 02:44:27 kernel: x7 : 0000000000023ab4 x6 : 0000000000023ab8
Jul 10 02:44:27 kernel: x5 : 00000000ffcf7df8 x4 : 00000000ffcf7df8
Jul 10 02:44:27 kernel: x3 : 0000000000000004 x2 : 000000000000000f
Jul 10 02:44:27 kernel: x1 : 0000000000000000 x0 : 00000000ffcf7df7



It doesn't affect the WIFI / LAN /WAN (no disconnects during these crashes) but still. Is there a way to resolve this other than not using PPTP server?

 

[eibgrad]

Let me state the obvious. The use of PPTP is *strongly* discouraged since it has long been known to be insecure, w/ no one having the interest to continue supporting it beyond its current state. Even when issues are found, I find developers (given their limited resources) are unlikely to address it. As such, I don't even understand why it's still in the firmware. Some operating systems have literally removed it (e.g., iOS). What I'd really like to see is Wireguard, Tailscale, ZeroTier, etc., take its place. Anything but this old relic of PPTP.

Anyway, I haven't a clue based on the information provided what's causing it to crash. Unless the issue is already known, those dumps are usually of little value except to the developer. Perhaps it has something to do w/ your configuration (granted, there isn't much to it), or some other conflict.

Any other information? Does it crash on startup of the server? When a user connects? Some time later while connected? Has it *ever* worked correctly for you, this build or prior?

If it were me, I'd reset the router to factory defaults (make a backup for recovery purposes first!) and make only the minimum necessary changes to see if stability can be achieved. Then slowly add back preferred features and addon's until it breaks again. Or start working backwards w/ older firmware to see if it helps (entirely possible this is a problem that's gone unnoticed for a long time given the small user base). Whether that's a worthwhile investment of your time is up to you.

 

[nickolasm5]

Yep, I understand all this. It never worked correctly, as I've set it up recently. It crashes randomly. (yet as I see this even doesn't break the connection)
The bakground is following - I have a lan behind double nat, and the only way to be able to connect to it from outside is to connect it via VPN to a router with a real IP.
Technically the router in that double NAT lan is a Mikrotik (client), the router with the real IP is the above asus (server).
It is possible to set up OpenVPN and connect the mikrotik, but if i try to set up any routing options and push them to mikrotik (so to be able to see the lan behind the mikrotik), mikrotik can't connect (as I understand that is caused by a poor OpenVPN implementation on mikrtoik). When connecting mikrotik via PPTP everything works like a charm. (the only thing are these errors in the logs)

 

[eibgrad]

I'm confused. If the primary router is the ASUS (i.e., the one w/ the public IP), and as a substitute for a PPTP server on that router, you could use an OpenVPN server, what has any of this to due w/ OpenVPN on the Mikrotik? The OpenVPN client is somewhere else on the internet. You connect to the OpenVPN server on the ASUS, and route from the ASUS LAN to the Mikrotik LAN. Granted, by default, the ASUS OpenVPN server, when configured as LAN only, can only see the LAN of the ASUS due to firewall rules. But those firewall rules can be adjusted to permit routing from the ASUS LAN to the Mikrotik LAN if need be.

Or else I don't fully understand your network configuration here.

 

[nickolasm5]

I'm confused. If the primary router is the ASUS (i.e., the one w/ the public IP), and as a substitute for a PPTP server on that router, you could use an OpenVPN server, what has any of this to due w/ OpenVPN on the Mikrotik? The OpenVPN client is somewhere else on the internet. You connect to the OpenVPN server on the ASUS, and route from the ASUS LAN to the Mikrotik LAN. Granted, by default, the ASUS OpenVPN server, when configured as LAN only, can only see the LAN of the ASUS due to firewall rules. But those firewall rules can be adjusted to permit routing from the ASUS LAN to the Mikrotik LAN if need be.

Or else I don't fully understand your network configuration here.

Mikrotik OpenVPN interface doesn't have any options to add OpenVPN routing rules (as for the client side) if I set up push route rules from the Asus (server) side Mikrtotik starts failing to connect. I've tried multiple settings with OpenVPN without any success, and switched to mikrotik being a PPTP client, and thats working like a charm except these errors in the ASUS logs

 

[eibgrad]

So you have Mikrotik on *both* sides of the connection, client and server?

[mikrotik - pptp/openvpn client]<- internet ->[asus - pptp/openvpn server]<->[mikrotik]

And if the Mikrotik OpenVPN client attempts to use the ASUS OpenVPN server w/ pushed routes for the remote ASUS and/or remote Mikrotik LANs, it can't handle it.

I know OEM firmware is often quite limited (esp. if it's the GUI), which is why we use third-party firmware. But NOT being able to push routes is ridiculous. So all the Mikrotik OpenVPN client can do is assume to route ALL its traffic over the VPN? There's no support for routing only to the remote LAN? Crazy.

Have you considered reversing the roles of the client and server, be it PPTP or OpenVPN (preferred)? IOW, configure the tunnel as a site-to-site so you tunnel back from the server to the client. If only to get around the current problems. Because it doesn't seem likely we're going to fix the PPTP server, and I'm no expert on the Mikrotik and why it behaves as it does. I'm just trying to find a way to avoid configurations w/ known issues rather than fix them.

 

[nickolasm5]

No. Mikrotik is the client, asus is the server. There are no problems if using Mikrotik (client) - Asusu (server) via PPTP (except for those errors in the logs), but if I try to set up Mikrotik (client) - Asusu (server) via OpenVPN, it is not possible to view lan behind the Mikrotik, as I can't manage to set up correct OpenVPN routes (seems due to OpenVPN client implementation)
technically maybe it will work vice versa, yet these 2 routers are in different remote locations, now I'm not able to chenge them

 

[eibgrad]

No. Mikrotik is the client, asus is the server. There are no problems if using Mikrotik (client) - Asusu (server) via PPTP (except for those errors in the logs), but if I try to set up Mikrotik (client) - Asusu (server) via OpenVPN, it is not possible to view lan behind the Mikrotik, as I can't manage to set up correct OpenVPN routes (seems due to OpenVPN client implementation)
technically maybe it will work vice versa, yet these 2 routers are in different remote locations, now I'm not able to chenge them

I understand all that. The point I was trying to clarify is that there appears to be TWO Mikrotik devices in this config.

Depending on what you need the remote access for, another possibility is SSH port forwarding. That's sometimes how I access the GUI of a remote router, esp. if that's the only reason for the remote access. Of course, if you need it for more general, widespread remote access needs, SSH becomes tedious, if not impossible in some cases.