Although it is well-known that pptp is not secure and is subject to many forms of attacks, the reality is that a lot of legacy and embedded devices use pptp. I argue that if it is being used for routing or remote access or over an already secure connection (eg. another VPN like ikev2) then this is still acceptable. Or in a LAN or in a public environment where no private data is exchanged. However, if the nature of the data is extremely sensitive, you should do whatever it takes to have the second layer of encryption by using a secure VPN protocol.
In iptables you can find many threads and discussions about how to make pptp work with iptables, with crazy forwarding rules and blindly and manually allowing all GRE etc... However it's much more simple in my experience. You just need to enable the netfilter conntracking to be able to connect your pptp client.
This solution also applies to a node running Kubernetes and Docker containers (eg. an embedded device that is for some odd reason using pptp). If you can, switch to ikev2 or OpenVPN.
sysctl -w net.netfilter.nf_conntrack_helper=1
net.netfilter.nf_conntrack_helper=1
nf_nat_pptp 20480 0
nf_conntrack_pptp 24576 1 nf_nat_pptp
nf_nat 45056 3 nf_nat_pptp,iptable_nat,xt_MASQUERADE
nf_conntrack 139264 6 xt_conntrack,nf_nat,nf_conntrack_pptp,nf_nat_pptp,nf_conntrack_netlink,xt_MASQUERADE
pptp, pptpd, dd, wrt, iptables, router, attacks, legacy, embedded, devices, routing, eg, vpn, ikev, acceptable, lan, exchanged, layer, encryption, protocol, threads, discussions, forwarding, blindly, manually, allowing, gre, etc, enable, netfilter, conntracking, applies, node, kubernetes, docker, containers, openvpn, sysctl, nf_conntrack_helper, conf, modules, kernel, nf_nat_pptp, nf_conntrack_pptp, nf_nat, iptable_nat, xt_masquerade, nf_conntrack, xt_conntrack, nf_conntrack_netlink,