Greetings.
I’m trying to mount a PPTP tunnel. One of my routers has an static IP, the other one is dynamic.
Have no trouble at all when I’m testing from office with my own Mikrotik router to the company’s one (this one is static).
The problem is when I try to test the production one, that is located in a different city, as client too. Obviously a different router, same configuration, but no connection.
I only see lynk stablished at client’s interface but there’s no connection. Normally I see the running “R” when connection’s done.
As an aditional data, I can see 47(gre) at both router’s Firewall/Connections.
I’m not so experienced. I can see there are many post views but no comments at all. Any help should be appreciated.
Thanks in advance.
As the topic title is so brief, people may view the post because they expect you need a simple advice on how to configure PPTP, and after reading the body of the post they find out that it’s not that simple, as the problem is apparently not configuration since it works at one client router and doesn’t on another.
PPTP has some drawbacks - it has been considered insecure already since years ago, and it uses GRE, which is treated miserably by many ISPs.
Yet another drawback is a consequence of those two - people with enough experience in networking rarely use it, which means they don’t gather any experience with it.
You state that you can see GRE connections in the /ip firewall connections list; however, this doesn’t necessarily mean that the connection is bi-directional. Plus treatment of GRE in Mikrotik firewall is also a bit specific.
So as the first step, check whether pptp is permitted in the /ip firewall service-port list on the problematic client, and whether no port is specified on that row.
If pptp is enabled there, it is very likely that GRE is not treated well by the ISP.
Configuring L2TP/IPsec is just a few clicks more complex than configuring PPTP (different firewall rules and a pre-shared IPsec secret), but it is more secure and uses UDP as transport, so GRE-related problems also don’t exist.
If you insist on GRE and disabled pptp under /ip firewall service-port is not the explanation, show me the /ip firewall connection print where protocol~“gre” from both the company router and the problematic client. Substitute the public IP addresses meaningfully (all occurrences of the same address at both ends to be substituted by the same string, see my automatic signature right below).
Thanks a lot for your comments and help.
I’ll send you the /ip firewall service-port scree late this day.
Actually the server and client show gre is working (linked), I suppose could be pptp port 1723, that one is not present at listing, but I have tryed filtering that (for some tutorials), allowing access, with no results I mean, I allow it and have no connection, even though.
Does l2pt works with only one of the sides as static (IP), or any other alternative? Actually I’m working with pptp 'cause I read somewhere that was the only way if I don’t have two static IPs (even when everywhere it says that’s insecure).
What is so curious is that second
No need to show it to me, just check what I’ve suggested to check, whether that row is not disabled and whether no port is specified on it.
In general, don’t post screenshots, post the text output of the export command as suggested in my automatic signature (and of print command where requested).
And only quote those parts of previous posts to which you react, not complete posts.
What I am actually interested in are the results of the print command I gave above (unless you decide to move away from PPTP).
The GRE connection only gets open after the initial negotiation on TCP port 1723 succeeds. So either there are some other GRE tunnels in use, not established using PPTP’s control connection, or the control connection has succeeded and then the PPP negotiation within the GRE broke, and the GRE connection remained in the firewall (it has a timeout of 10 seconds by default).
All tunneling protocols with authentication can handle client side NAT, not because authentication would be necessary for NAT traversal, but because both authentication and NAT traversal are part of the design to make them practically useful. So bare IPsec, L2TP with or without IPsec, SSTP, OpenVPN, Wireguard all can handle NAT at least at client side.