PPTP classless route vs. class routing

RouterOS General
1

@Chupaka

  1. PPTP classless routing fix for Windows clients
    ??

The issue is when you’re using PPTP on, say, a 10.x.x.x/24 network, and connecting to a different class C 10.x.x.y/24 network.

In crazy MikroTik land, the route the PPTP client gets is a /8 route - which borks all traffic on either the local or remote end, depending on if you have “use as default gateway” checked on the client end.

Instead of getting a route on the client of say. 10.1.1.1/24 you’ll get a 10.1.1.1/8 - which means if your local network is 10.1.2.0/24 and the remote end is 10.1.1.0/24 you’ll either have to give up accessing the local network, or the VPN tunnel. [Essentially there’s no way for both networks to co-exist since the /8 class network designation blows it all away.]

(On a 192.168.x.x network, you’ll get a /16 route.)

This is all based on the very dated and rejected idea of class routing - 10.x networks were a class 8, 192.168 networks are a class /16.

I come from a SnapGear environment, and they had a way to propogate a real class-less route which wouldn’t do this.

Some people have asked for a way to pass DHCP info to the clients - and the claim always seems to be that DHCP isn’t supported under PPTP - which may all be true. But frankly, I don’t give a damn if DHCP can’t pass stuff to a PPTP client - what I do care about is that it doesn’t have to be this way. There is a way to fix it.

But it’s indisputably true that it IS POSSIBLE to give a route to the PPTP client that isn’t a class based route, but is based on the classless network config of the remote end. (i.e you can pass a route of 10.x.x.x/24 to the PPTP client, instead of 10.x.x.x/8.)

How it’s done, I’m not sure - but that’s Mikrotik’s job, not mine. I just know there are a host of Linux based devices that have done this for, literally, like 10 years or more.

Why MikroTik refuses to figure it out and implement it, I’m not sure. I’d guess that it’s simply not that hard, it just requires some determination to actually do it.

-Greg

PPTP MS client wrong remote subnet mask
2

what client are you talking about?.. PPTP cannot receive any routes from the server. I know only two PPP tunnels doing it: OpenVPN and Cisco VPN

on my Windows XP, no routes is being added when ‘Use Default Gateway’ is checked

p.s. anyway, when you have 10.0.0.0/8 route via VPN and 10.1.2.0/24 is local network, your computer must use /24 route - with longer mask!

3

@Chupaka

WinXP, WinVista, Win7 all exhibit this behavior.

  1. I don’t want the VPN to be the default gateway.
  2. There are lots of PPTP devices that handle this properly. I believe native Linux will do it fine. I know that Snapgear handled it fine too.

Again, if your remote network/station is 10.1.2.0/24, and the LAN on the VPN side is 10.1.1.0/24, you’ll get a route for
10.0.0.0/8 on the client when you connect via PPTP.

So, that means that anything in the 10.1.2.0/24 network will get routed over the PPTP vpn back to the home network, which means it will break all local connectivity at the remote site.

As I said before, snapgear, and others had a way to recognize that the REMOTE LAN was a /whatever, [usually /24] and would add routes appropriate for the VPN PPTP client. I’m quite sure that OpenWRT handles it fine too.

[Clearly this won’t fix cases where the LAN and WAN networks are on the same base/subnet [i.e. 10.1.1.0/24 on both ends] but that’s obviously a problem that’s not fixable.

What IS fixable is that a REMOTE network/station of 10.1.2.0/24 and a LAN of 10.1.1.0/24 shouldn’t get a class route of 10.0.0.0/8.

DHCP option 121 would fix it, though there’s vigorous claims that DHCP 121 can’t be passed over a PPP/PPTP connection. Which again is fine. I don’t care if it’s handled via a DHCP option 121 or some other way - it just needs to get sorted.

Here’s the routing I get…

===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.11.1   192.168.11.202    276
         10.0.0.0        255.0.0.0        10.8.23.1       10.8.23.12     21
       10.8.23.12  255.255.255.255         On-link        10.8.23.12    276

So, any local resources in the 10.0.0.0/8 will get borked.

-Greg

4

Here’s my WinXP, I connect to RouterOS PPTP server. Local IP is 93.125.112.253, remote ip is 172.30.0.1.

Network address         Net mask       Gateway           Interface  Metric 
          0.0.0.0          0.0.0.0      10.25.3.126       10.25.3.3       21
          0.0.0.0          0.0.0.0   93.125.112.253  93.125.112.253       1
         10.0.0.0        255.0.0.0      10.25.3.126       10.25.3.3       1
        10.25.3.0  255.255.255.128        10.25.3.3       10.25.3.3       20
        10.25.3.3  255.255.255.255        127.0.0.1       127.0.0.1       20
   10.255.255.255  255.255.255.255        10.25.3.3       10.25.3.3       20
   93.125.112.253  255.255.255.255        127.0.0.1       127.0.0.1       50
   93.255.255.255  255.255.255.255   93.125.112.253  93.125.112.253       50
  117.198.243.206  255.255.255.255      10.25.3.126       10.25.3.3       20
  117.201.207.173  255.255.255.255      10.25.3.126       10.25.3.3       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.0.0      255.255.0.0      10.25.3.126       10.25.3.3       1
    192.168.0.200  255.255.255.255      10.25.3.126       10.25.3.3       1
        224.0.0.0        240.0.0.0        10.25.3.3       10.25.3.3       20
        224.0.0.0        240.0.0.0   93.125.112.253  93.125.112.253       1
  255.255.255.255  255.255.255.255        10.25.3.3       10.25.3.3       1
  255.255.255.255  255.255.255.255   93.125.112.253  93.125.112.253       1
Default gateway:    93.125.112.253

What am I doing wrong?..

5

@Chupaka

Line three of your routing table shows a /8 on the 10.0.0.0 network.

Looks just like what I’m describing.

Let me re-iterate my situation

Local network 10.1.1.0/24
Remote Network 10.1.2.0/24

Once I connect to the remote network at 10.1.2.0/24, I get a route in my windows routing table like I showed above, and that is present in yours.

If I try to connect to my, say print server web interface at 10.1.1.10 on the “local network” as above, it will try to route that traffic to the 10.1.2.0/24 network. So, I can’t get there.

If the ROS handled PPTP like most other PPTP servers it would [somehow, I don’t know exactly how] would present the PPTP network as a /24 instead of a /8, and then since the “remote network” is 10.1.2.0/24 I could still get to local resources on the local network - since it wouldn’t route anything other than 10.1.2.0/24 addresses over the PPTP connection.

Make sense!?

-Greg

6

but this route is received via DHCP, and has nothing to to with VPN:
on VPN, my IP is 93.125.112.253, server’s ip inside the VPN is 172.30.0.1, and server’s LAN ip is 192.168.0.200 - there’s no 10.*

7

this is not a mikrotik thing, its a windows things. Windows connects pptp clients with classful routes. . . so if you get assigned a 10.x.x.x anything, windows will stick a 10.0.0.0/8 in its routing table and bork things up. I always use a 172.16.x.x address on pptp to get around that. Again, not mikrotik problem but windows doing that to you.

8

If you connect to a Windows server via PPTP it doesn’t get a /8.
If you use Snapgear you don’t get a /8.
If you use OpenWRT you don’t get a /8.

So, it’s a Mikrotik thing, in that, it’s very possible to do something different and Mikrotik hasn’t done it.

I’m really tired with the “we can’t do anything about it” shtick.
It’s not true, and arguing about all the “it’s not possible to give a DHCP option 121” or “it’s Windows” misses the point.

The point is:
It is possible to connect to a PPTP vpn on a Windows client and get something other than a /8.
Mikrotik has chosen to ignore this need and it’s a real PITA.
Just call a spade a spade.

*MikroTik has simply decided they’re not going to really support PPTP like most of the rest of the world does and that screws over users.
It’s their choice, but don’t make Mikrotik seem like the victim here. They aren’t.
*
-Greg

9

you are right in the end, im just saying without dhcp on ppp it defaults to a /8.

mikrotik needs to make it so dhcp server can run on a ppp interface to make it work. right now the ppp service hands out the ips, not the dhcp service.

10

okay, my WinXP really sends DHCP request into pptp tunnel - that’s good :slight_smile:

to setup dhcp server for pptp I even tried creating a bridge with DHCP server and setting ‘bridge’ in sercret’s profile - but pptp interface wasn’t added as a slave to that bridge…

by the way, the story is a bit ancient: http://forum.mikrotik.com/t/assigning-routes-to-pptp-client/8519/1

Normis, let’s start from the beginning? :slight_smile:

11

-Bump-

Normis et al…

Could someone please respond, I would really appreciate it.
This is quite an issue plaguing my clients who I have on RB gear.

-Greg

12

Bump.
Normis? Someone?

13

Your computer get this route because Windows will assume the size of the network at the other end based on the ip address received. Checking “Disable class based route addition” means that classful route isn’t added to your computer when the VPN starts up, and you’ll need to add the appropriate routes for networks that should be routed through the tunnel.

In the advanced TCP/IP settings of a VPN connection, you will find a checkbox labeled with “Disable class based route addition”. The checkbox is only enabled as long as “Use default gateway on remote network” is switched off.

  • Open Properties of VPN connection
  • Go to Networking tab
  • Open Properties of "Internet Protocol Version 4 (TCP/IPv4)
  • Click “Advanced…” Button
  • In “IP Settings” tab, you will find the checkboxes “Disable class based route addition”
14

@THG I appreciate that information, but then I have to have some way to “automagically” add the proper route to the client PC - which isn’t really possible.
Again, while this is a work-around, it’s as bad as simply adding the remote PPTP tunnel as the default gateway - perhaps worse.

So, I’ll note again…

MANY, MANY, MANY non-MikroTik PPTP implementations allow you to send a route to an attached PPTP client and DO NOT reply on class based routing assumptions on Windows.
Snapgear, Microsoft RRAS, OpenWRT etc all do this “properly.”

Mikrotik has simply chosen not to handle this “properly” and has caused a huge PITA for clients and people who want to sell/support Mikrotik.

They can choose to ignore the issue - it is their company after all. But it’s not a “windows” problem, or a dumb-user configuration problem etc.
It’s truly a MikroTik implementation problem. They’ve chosen to implement PPTP in such a way that this is the result.

No amount of “hackery” is going to make this any less of a MikroTik problem.

So, no offense intended, I really do appreciate knowing of another “hack” that could, in some cases, help alleviate the pain caused by a really lousy implementation of PPTP by MikroTik.

So thanks - I think… :slight_smile:

Also, I find it interesting that MikroTik has failed to respond in any way to this thread.
Do they care?

It seems like a lot of other issues at MikroTik. [e.g. UDP over OpenVPN, the “disk” size on the 1100AHx2 etc.]
Ignore, ignore, ignore.
Then when you can’t ignore it any longer, be really offensive and abrasive in answering the poster. Make it their stupid problem, and attack the questioner as a fool. [e.g. “Well, sure the disk on the 1100AHx2 is only 47M when it used to be 512M, but only a pinko homo-fag would ever need a disk as big as it was before. Go home sissy boy!” Yes, I know, I’m exaggerating some, though not by much.]

In some respects, it works. The questioners often go away.
But those are customers, and people who would love to sell MORE of your product, that you’re pissing off [or ON, as the case may be.]

We’re not the enemy. We’re people who want to buy your product and sell more of it to our customers.
MikroTik…Help us sell more of your $hit, please - by fixing problems like the PPTP implementation.

Cheers.
-Greg

15

I think I am seeing the same problem..

I want to set up a VPN so clients can access some services behind it. I’ve just tried connecting and see a /8 route for 80.0.0.0 going in the routing table unless I disable the above! How can I make routeros just set the route for the relevant subnet at that end rather than wiping out whole swathes of the Internet?! I don’t particularly want to have to route all their Internet traffic when they are connected to work around this.

Thanks,

John

16

@john…

There just isn’t any, IMO, reasonable way to solve this in ROS. There’s several “hacks” that could be strung together with say, a powershell script that might make it manageable - but it’s fragile and really a horrid hack.

BUT - several things have happened in the time since I posted this that make it a moot discussion.

  1. PPTP was effectively hacked in a huge way a few months ago. Essentially, MS made huge design errors when doing the design for PPTP, and the result is that the PPTP encryption key is effectively only a DES key. Such a short key is horribly easy to defeat.

Thus I think anyone, who continues to use PPTP knowing this, and is using PPTP for a protected VPN is nuts. [Sorry to be blunt, but the security of PPTP is completely and totally gone.] For more information, see a google search of cloud-cracker.

So, that leaves us with only a few options for road-warrior VPN’s.

IMO, L2TP is a very poor choice - related to lack of IPSec firewall IPSec Policy match.
Straight IPSec suffers the same problem for road-warrior connects.

The only remaining VPNs available are SSTP [Which is Vista/Win7 only.] or OpenVPN.

SSTP may well now be stable. Up until 5.20 or something it wasn’t. [Prior to very recent versions [and newer than 5.08 or something] there were multiple reports of very bad SSTP problems.]

While I hate OpenVPN on ROS - since their implementation is so poor - it does work pretty well and unless you have to have LZO compression or UDP support, it works reasonably well. [High levels of bandwidth/throughput is probably another show-stopper.]

And with OpenVPN you can set routes quite nicely. [Unfortunately you can’t push routes from the ROS OpenVPN Server like all standard OpenVPN implementations do - but on a small scale that’s something you can probably live with. It’s certainly better than PPTP. The downside is that OpenVPN with certificates is a LOT more setup and complication, especially for a single connect.]

Good luck.

-Greg

17

Thanks for the info. Is it possible to set a route to the subnet using L2TP/IPSEC in routeros in that case? That might be an option for me although not sure if it will work with for everyone.

Cheers,

John

18

I’ve not tinkered with L2TP too much, but I think it handles this much better than PPTP. [It’s been a while and I don’t recall the exact details. But it’s quick to setup and test if you’d like to try it.]

-Greg

19

I am struggling with similar issues since I first used pptp years ago. However, my problem is that I have local network subnetted and after I connect pptp to remote MT, i loose connections to all other subnets as fancy /8 route overrides them all.

I also have issues with sharing network resources (like printers) over pptp connections.

Until now, I thought it is Microsoft, but now I learned that it actually does not happen on other vnp servers but Mikrotik.

20

UP actual problem send routes to pptp client