connect to pptp VPN from pppoe ISP

Hello

I have a mikrotik router with PPPoE-client connection to ISP.

I want this router to connect to my company VPN server (which is another Mikrotik router). Company Mikrotik VPN server works fine, because all other clients (Mikrotik routers) can connect to it, access lan resources and everything works.

But when I connect to company VPN server from the PPPoE-client Mikrotik router it can connect to VPN server Mikrotik but can not access lan resources. When I check PPP → Interfaces: Status is connected, but in IP → Routes: pptp-out Gateway is unreachable.

Can you help me please.

Thank you a lot.

Of course we can. We need just one small thing, see my automatic signature below.

Is this the help that “forum guru” can provide? It sounds a little bit sarcastic and it does not help.

Thank you a lot, I can see you are very frendly here.

This is the maximum help anyone can provide given the information you have provided so far - to tell you what you have to do to get some real help, i.e to post your configuration.

In most cases things don’t work because there is a mistake in configuration, so this is always the first thing to check. Only then it makes sense to analyse the eventual surprises provided by ISPs blocking some protocols etc.

Yes, I understand that I should post some of my configuration. I know that no one can help it I do not provide configuration details, but which part, doubt that I have to /export and post everything.

ISP is not blocking anything. There might be something with the Routing or NAT, I don’t know I am just guessing. I have masquarade rule and route to pptp-out. What I see is that pptp-out Gateway is unreachable.

I am ready to provide configuration details. Just tell me what you need and I will post it right away.

Thank you a lot for your previous answer.

That’s the problem - since we don’t know in which part of the configuration the mistake is, it is impossible to say which part to post. So you actually do have to post the full export, that’s why my automatic signature contains a suggestion how to anonymize it. The hide-sensitive parameter of /export prevents the passwords from being exported, but it doesn’t obfuscate public IP addresses. So IP addresses have to be obfuscated manually but it has to be done in such a way that it doesn’t corrupt consistency of the information (individual addresses vs. subnets or address-lists).

I would love to place this explanation into the signature but it has a limited size.

Now I understand what you mean.

Here is the configuration with /export hide-sensitive

...

I think it’s all just a matter of routes.

The default route added by /interface pppoe-client has distance=0 (which is incorrect as such and newer ROS releases wouldn’t accept that, but that’s not the main point here), so it beats the other, manually added, default route via pptp-out1 which has distance=1 even when pptp-out1 is up.

So if you really want all traffic to go through pptp-out1 whenever it is up, you have to change default-route-distance in /interface pppoe-client to 2 or more. But that’s not enough, you also have to manually add another route, dst-address=VPN.Server.IP.Address/32 gateway=pppoe-out1, as otherwise the transport and control packets of pptp-out1 would be routed through it so they would get nowhere and pptp-out1 would keep flapping.

If it is enough for you to access only some remote LAN subnets via pptp-out1, add just routes with these subnets as dst-address and remove the default route via pptp-out1.

A separate issue is the question of src-nat’ing of traffic sent via pptp-out1; if you don’t add routes to this client’s local LAN subnets via this client tunnel at the server when this client connects, the server routes the responses to requests coming from this tunnel somewhere else. So again, not enough information to suggest what may be missing. For a site2site tunnel, the routes at server are necessary; for client2server tunnel, the src-nat at client is enough.

One separate point, when posting configuration, use the [code] and [/code] tags. You can edit your previous post this way.

Thank you very much for your answer.

I already have routes with subnet I need to access via gateway pptp-out1, but in routes Gateway pptp-out1 is unreachable and I don’t understand why pptp-out1 is unreachable because in PPP->Interfaces status is connected.

Which gateway should I choose for subnets that I want to access if I remove the route via pptp-out1 (which is not default route, because I added it manually and made comment for it ;;; vpn added by Stoyko Stoykov. is this that you mean to remove?). I have tried to change it to pppoe-out1, but it does not works.

I need client2server tunnel. I only need to access lan subnets via pptp-out1 on server side from client side.

I should not analyze others’ configurations after four hours of sleep :frowning:
I’ve missed the dst-address=192.168.1.0/24 on the manually added route. So that route is correct and is neither shadowed by the default one added by the pppoe-out1 nor it steals the transport packets. Also use of a PPP interface as gateway is OK, the IP address is not necessary.

Can you show me the output of /ip route print detail and /interface pptp-out1 print detail while the pptp is connected?


OK, in that case your masquerade rule with dst-address=192.168.1.0/24 seems to be sufficient for the job, and the inactive route is the main issue to focus on.

/ip route print detail - return this

 /ip route print detail 

Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 0 ADS  dst-address=0.0.0.0/0 gateway=pppoe-out1 gateway-status=pppoe-out1 reachable distance=0 scope=30 target-scope=10 

 1   S  ;;; vpn added by Stoyko Stoykov
        dst-address=192.168.1.0/24 gateway=pptp-out1 gateway-status=pptp-out1 unreachable distance=1 scope=30 target-scope=10 bgp-origin=igp 

 2 ADC  dst-address=192.168.88.0/24 pref-src=192.168.88.1 gateway=bridge gateway-status=bridge reachable distance=0 scope=10 

 3 ADC  dst-address=public.ip.2/32 pref-src=public.ip.0 gateway=pppoe-out1 gateway-status=pppoe-out1 reachable distance=0 scope=10

where public.ip.0 is my public ip address

/interface pptp-out1 print detail - return this

 
 /interface pptp-out1 print detail
 bad command name pptp-out1 (line 1 column 12)

What bothers me is the bgp-origin=igp attribute of your route to 192.168.1.0/24 via pptp-out1. On my 6.43.4 machine, the same type of route doesn’t show such attribute.

10 A S dst-address=192.168.229.0/28 gateway=pptp-out1 gateway-status=pptp-out1 reachable distance=1 scope=30 target-scope=10

Worse than that, your configuration export doesn’t show that attribute; if I manually add that attribute to my configuration, /export shows it even with hide-sensitive (and the route stays active even with the attribute in place).

I don’t say the attribute itself is the cause of your issue; I say that it is suspicious that it is shown by print and not shown by export.

As for the interface status, sorry, the proper command is /interface pptp-client print - please try again.

So maybe try to remove the route and add it again. If it doesn’t work anyway, I would export (not backup!) the configuration into a file on the machine, download the file elsewhere, then reset the configuration to defaults and then restore it from the external file section by section.

/interface pptp-client print detail - return

/interface pptp-client print detail 
Flags: X - disabled, R - running 
 0  R ;;; vpn added by Stoyko Stoykov
      name="pptp-out1" max-mtu=1450 max-mru=1450 mrru=disabled connect-to=xxxxxxx.sn.mynetname.net user="vpn" password="xxxxxx" 
      profile=default-encryption keepalive-timeout=60 add-default-route=no dial-on-demand=no allow=pap,chap,mschap1,mschap2

Worst thing is that I work remotely and I can not reset it, since employees there can not restore. If I reset it, I will loose connectivity and the problem will get bigger because they will lost internet as well.

This problem is very wired, because all other Mikrotiks that are not connected to ISP via PPPoE are working very well. This is the only one that does not works and it is the only one that is connected to ISP via PPPoE.

I don’t believe it is related, as if a route’s gateway is just the interface, no IP address, RouterOS has no way to check anything but the interface state. So any MTU issues and alike have no chance to affect route state.

I assume your use some other VPN type than pptp to connect to the machine remotely, so removing and re-creating the problematic route should be safe. If that doesn’t help, I’m afraid you’ll have to get on site, or send there a pre-configured and tested replacement.

Thank you for your answers. I will keep trying. I will first schedule a script that will restore from backup file every 15 minutes, so if I lost connectivity due to wrong configuration it will restore after 15 minutes hopefully.

I do not understand why in Routes pptp-out1 is unreachable, but in interfaces pptp-out1 is connected and when I check the server side it is there as well. If I disable pptp-out1 on client side it dissapears from the server then when enabled it shows on server side, so I believe it is connecting properly.

Anyway I will not take more from your time, because you may be bussy.

Thank you a lot for your answers.

Kind regards,

  • Stoyko