Allow CGNat IP to Establish PPTP Connection

LunaticRv · Thu Nov 26, 2020 11:48 am

Hello, I am using Carrier-Grade NAT for my PPPoE customers. Some of them are complaining about failure of connecting their VPNs (they are using Mikrotiks aswell).

Sample NAT rule for customer;

/ip firewall nat
add action=jump chain=srcnat jump-target=CGN64_9 out-interface=VL_46-CORE src-address=100.64.3.2-100.64.3.63

add action=src-nat chain=CGN64_9-4 out-interface=VL_46-CORE protocol=tcp src-address=100.64.3.35 to-addresses=X.X.X.X to-ports=35792-36815
add action=src-nat chain=CGN64_9-4 out-interface=VL_46-CORE protocol=udp src-address=100.64.3.35 to-addresses=X.X.X.X to-ports=35792-36815

add action=src-nat chain=srcnat out-interface=VL_46-CORE protocol=gre src-address=100.64.3.2-100.64.3.63 to-addresses=X.X.X.X

But still, user cannot establish PPTP connection. Is there anything else I should add? My temporary solution is to give them a public IP.

Thanks in advance!

sindy · Thu Nov 26, 2020 3:58 pm

PPTP uses GRE as a transport protocol. If several of your clients connect to the same VPN server, your Mikrotik cannot determine to which of the clients to forward the GRE packet coming from that server to your Mikrotik's public WAN address, because GRE has no notion of ports and both the source and destination address are the same for any client connecting to the same server.

L2TP/IPsec suffers from a similar issue, so they need to migrate to bare L2TP (not recommended for security reasons, but it's no worse than PPTP in this aspect), or to bare IKEv2 IPsec (much better security and some extra features like pushing of a route table to the clients, but in the current RouterOS releases, it requires use of machine certificates on Windows), or to SSTP (which is supported on Mikrotik and Windows but not on MacOS, and is not rocket fast for some reason).

If the clients are unable to change the VPN protocol, assigning them individual public IPs is the only way. But you may want to src-nat their 100.64.0.0/10 addresses to individual public ones at your end rather than giving the public ones directly to them, as it will allow you to reuse the same public address for several clients who connect to different PPTP servers. E.g. if clients 1, 2 and 3 connect to server A and clients 4, 5 and 6 connect to server B, you can use the same public IP for clients 1 and 4, 2 and 5, and 3 and 6.

LunaticRv · Fri Nov 27, 2020 8:35 am

PPTP uses GRE as a transport protocol. If several of your clients connect to the same VPN server, your Mikrotik cannot determine to which of the clients to forward the GRE packet coming from that server to your Mikrotik's public WAN address, because GRE has no notion of ports and both the source and destination address are the same for any client connecting to the same server.

L2TP/IPsec suffers from a similar issue, so they need to migrate to bare L2TP (not recommended for security reasons, but it's no worse than PPTP in this aspect), or to bare IKEv2 IPsec (much better security and some extra features like pushing of a route table to the clients, but in the current RouterOS releases, it requires use of machine certificates on Windows), or to SSTP (which is supported on Mikrotik and Windows but not on MacOS, and is not rocket fast for some reason).

If the clients are unable to change the VPN protocol, assigning them individual public IPs is the only way. But you may want to src-nat their 100.64.0.0/10 addresses to individual public ones at your end rather than giving the public ones directly to them, as it will allow you to reuse the same public address for several clients who connect to different PPTP servers. E.g. if clients 1, 2 and 3 connect to server A and clients 4, 5 and 6 connect to server B, you can use the same public IP for clients 1 and 4, 2 and 5, and 3 and 6.

Thank you very much Sindy, now I see why I failed. I tried to src-nat their IPs on only TCP,UDP and GRE wise. I though it should have worked but it didn't. I'll try to src-nat the IP itself directly. But it will probably be impossible to track each users session logs with appropriate way within this method.

DarkNate · Fri Nov 27, 2020 10:06 am

If you're behind a CGNAT. The only way would be to use NAT punching with TCP/UDP (unreliable on some ISPs due to short timeout of UDP streams) from the end-customer's side. Example ngrok, OpenVPN etc.

Any protocol that needs a real public IP address port forwarding will never work: https://en.wikipedia.org/wiki/Carrier-g ... advantages

https://tools.ietf.org/html/rfc7021

I pay for static public IP in my case. CGNAT is a disease.

Or do the right thing and deploy PCP: https://tools.ietf.org/html/rfc6887

Allow CGNat IP to Establish PPTP Connection

Allow CGNat IP to Establish PPTP Connection

Re: Allow CGNat IP to Establish PPTP Connection

Re: Allow CGNat IP to Establish PPTP Connection

Re: Allow CGNat IP to Establish PPTP Connection

Who is online