PPTP Client - Routing Issue?

RouterOS General
1

I am having an issue with the PPTP Client when the PPTP Server’s public IP is the same as the Remote IP of the PPTP Tunnel.

The VPN Server’s Public IP is 11.11.11.1 (This is the Internet IP the PPTP Client connects to - IPs changed for simplicity)
Once the PPTP Tunnel is established, the Remote Address is also 11.11.11.1
The clients local tunnel IP is 11.11.11.2 (The client is being placed directly on the Internet at the remote location)

The tunnel establishes just fine, but keepalives and data are not properly routed, so the tunnel dies after ~1 minute and 30 seconds.

The problem with the routing seems to lie with the automatically created dynamic route for the tunnel’s IP Address. This dynamic route has a distance of 0, and forces all traffic to 11.11.11.1 to go out over the tunnel (which is itself connected to 11.11.11.1). As such, all traffic to 11.11.11.1 gets stuck in the router trying to go over a dead tunnel.

Windows, MacOS and Linux PPTP Clients seem to have no trouble with this kind of tunnel setup, is there any reasonable way to route the PPTP connection and tunnel data appropriately in RouterOS?

PPTP client tunnel: default host route chokes tunnel conn.
2

Route rule should have effect only for remote-address, it should be like,
dst-address=11.11.11.2 gateway=11.11.11.1 (that traffic to the second end should be forwarded over VPN).

Enable PPTP debug logs and post the output, which is displayed after disconnect.

3

Route rule should have effect only for remote-address, it should be like,
dst-address=11.11.11.2 gateway=11.11.11.1 (that traffic to the second end should be forwarded over VPN).

Enable PPTP debug logs and post the output, which is displayed after disconnect.

4

It is true that the route only applies to the remote-address IP, but the remote-address is the same address as the PPTP Server’s IP address.

RouterOS v4.9 on both an RB450G and an RB750

The PPTP Client is configured as follows:
Name = BadVPN
Connect To = 11.11.11.1
Dial on Demand = No
Add Default Route = No

Once connected, the client is automatically assigned the following address:
Address = 11.11.11.2
Network = 11.11.11.1
Interface = BadVPN

The addition of the above address creates an automatic dynamic route as follows:
Dst. Address = 11.11.11.1
Gateway = BadVPN
Distance = 0
Pref Source = 11.11.11.2


Once this dynamic route is created, the PPTP traffic to 11.11.11.1 stops flowing out the default gateway and the tunnel eventually times out.



Here are the log entries you requested, not sure if I got what you need though:

May/13/2010 14:45:22 pptp,ppp,debug,packet  BadVPN: rcvd LCP EchoReq id=0x2
May/13/2010 14:45:22 pptp,ppp,debug,packet     <magic 0xd7d29880>
May/13/2010 14:45:22 pptp,ppp,debug,packet  BadVPN: sent LCP EchoRep id=0x2
May/13/2010 14:45:22 pptp,ppp,debug,packet     <magic 0x656a7277>
May/13/2010 14:45:23 pptp,debug,packet rcvd Echo-Request from 11.11.11.1
May/13/2010 14:45:23 pptp,debug,packet     identifier=16777216
May/13/2010 14:45:23 pptp,debug,packet sent Echo-Reply to 11.11.11.1
May/13/2010 14:45:23 pptp,debug,packet     identifier=16777216
May/13/2010 14:45:23 pptp,debug,packet     result-code=1
May/13/2010 14:45:23 pptp,debug,packet     error-code=0
May/13/2010 14:45:51 pptp,ppp,debug BadVPN: LCP lowerdown
May/13/2010 14:45:51 pptp,ppp,debug BadVPN: LCP closed
May/13/2010 14:45:51 pptp,ppp,debug BadVPN: CCP lowerdown
May/13/2010 14:45:51 pptp,ppp,debug BadVPN: CCP closed
May/13/2010 14:45:51 pptp,ppp,debug BadVPN: BCP lowerdown
May/13/2010 14:45:51 pptp,ppp,debug BadVPN: BCP down event in starting state
May/13/2010 14:45:51 pptp,ppp,debug BadVPN: IPCP lowerdown
May/13/2010 14:45:51 pptp,ppp,debug BadVPN: IPCP closed
May/13/2010 14:45:51 pptp,ppp,info BadVPN: terminating... - keepalives timed out
May/13/2010 14:45:51 route,debug,event Interface change
May/13/2010 14:45:51 route,debug,event     interface=BadVPN
May/13/2010 14:45:51 route,debug,event     status=DOWN
May/13/2010 14:45:51 route,debug,event     mtu=1460
May/13/2010 14:45:51 route,debug,event Interface change
May/13/2010 14:45:51 route,debug,event     interface=BadVPN
May/13/2010 14:45:51 route,debug,event     status=DOWN
May/13/2010 14:45:51 route,debug,event     mtu=1460
May/13/2010 14:45:51 route,debug,event Remove interface BadVPN
May/13/2010 14:45:51 route,debug,calc Begin calculation
May/13/2010 14:45:51 route,debug,event Removed route
May/13/2010 14:45:51 route,debug,event     state=ACTIVE
May/13/2010 14:45:51 route,debug,event     dst-prefix=11.11.11.1/32
May/13/2010 14:45:51 route,debug,event     attributes
May/13/2010 14:45:51 route,debug,event         protocol=CONNECT
May/13/2010 14:45:51 route,debug,event         scope=10
May/13/2010 14:45:51 route,debug,event         target-scope=0
May/13/2010 14:45:51 route,debug,event         connected-net= address=11.11.11.2/32 interface=BadVPN
May/13/2010 14:45:51 route,debug,event         routing-mark=main
May/13/2010 14:45:51 route,debug,event         table=main
May/13/2010 14:45:51 route,debug,event         origin-type=CONNECTED
May/13/2010 14:45:51 route,debug,calc End calculation
May/13/2010 14:45:51 route,debug Begin redistribution
May/13/2010 14:45:51 route,debug Accept withdraw 11.11.11.1/32
May/13/2010 14:45:51 route,debug Commit prefix 11.11.11.1/32
May/13/2010 14:45:51 route,debug End redistribution
May/13/2010 14:45:51 route,debug,calc Begin calculation
May/13/2010 14:45:51 route,debug,event Address removed
May/13/2010 14:45:51 route,debug,event     network=11.11.11.1/32
May/13/2010 14:45:51 route,debug,calc End calculation
May/13/2010 14:45:52 pptp,ppp,debug BadVPN: LCP lowerdown
May/13/2010 14:45:52 pptp,ppp,debug BadVPN: LCP down event in starting state
May/13/2010 14:45:52 pptp,ppp,info BadVPN: disconnected
5

Yes, I see. My suggestion to use other local remote addresses, as they are only used for tunnel management (you can use any private IP address for them).

6

To actually create and maintain a tunnel you need connection that goes from 11.11.11.1 to 11.11.11.2 over Ethernet.
But as soon as you connect you force that connection to go over tunnel interface instead, so this way eliminating possibility to maintain the tunnel over Ethertnet.

So only solution is to use different addresses, as Sergejs already mentioned.

7

That’s very unfortunate, I don’t control the server; it’s on the other side of the world. I’m really kind of stuck… I need to get this working somehow, but all I have available is Mikrotik Equipment. (great stuff by the way, I really love it :smiley:)

This tunnel works perfectly on every other PPTP client I have tried, they manage to make the routing just work somehow.

If there was a way to, for example, assign the PPTP Client to use a specific interface (much like how you can set ping to use a certain interface) it would probably fix this issue and add a nice layer of control. When pinging with a set interface the ping traffic ignores routing to a certain extent. It would be an awesome feature for the PPTP client to have in v5, not sure how easy it would be though.

8

Perhaps there is possibility to change public IP address on the computer.

9

I’m not able to assign IP addresses to the tunnel, and the company that operates the PPTP server is not willing to change it in any way. From their point of view, since it works fine with Windows and MacOS, it must be RouterOS that is broken.

10

hmmm… do you have NAT rule that masquerades all traffic leaving through that pptp connection? try to disable it… just for test

11

No, pretty much the only configuration is the PPTP Client and a DHCP client for the gateway interface. For testing purposes, firewall allows all traffic through, and connection tracking is on. PPTP Client connections to other servers work fine.

I have tried setting up mangle rules to routing mark the PPTP transport traffic and force it over a static route through the normal gateway, but the distance of 0 on the dynamic route seems to prevent this from working properly. If I could modify that dynamically created route to only route traffic marked for the tunnel this PPTP client would work, but modifying automatically created entries is not possible.

It’s too bad it’s not possible to prevent RouterOS from creating automatic routes for certain things.

12

maybe try routing filter with chain=dynamic-in?..

13

I was not aware of the capabilities of routing filters, I knew there had to be some way to do it.

Using ‘connected-in’ I was able to totally disable the offending route. For some reason, the only actions that actually apply correctly to the specified route(s) are ‘Set Disabled’ and ‘Set Route Comment’… The rest, such as ‘Set Distance’ seem to be ignored. ‘Set Disabled’ is all I really needed though.

It’s a great feeling to finally have the tunnel working, thanks.

14

glad to hear you got it working =)

yep, there’s no limitations mentioned in the manual about ‘connected-in’ chain… MikroTik staff, any improvements of the docs? =) thx