I am adding a new administation/monitoring system to my network.
The new computer is connected to a Mikrotik router, that is in turn connected to another Mikrotik router via wireless, that is in turn connected to the master router of my network.
eg. Computer ---> Router A ---> Router B ---> Master RouterOS ---> to rest of my network.
I want to use a PPTP connection from Router A to my main server and from there the main server 'knows' all the applicable routes. Thus the new monitoring computer behind A can access all of my network.
Everything works fine IF I manually add the required routes on Router A.
However as I currently have 12 different subnets and more being added all the time, it is a pain to continuously add more routes to Router A. Also it is possible that I may want to add more connections like this.
All I want is for the PPTP Server running on my Master RouterOS to push/assign the applicable routes to Router A. This way any PPTP connections I want would have these routes automatically assigned.
I am aware of the /ppp secret routes parameter, however this is for use in dynamically adding routes to the PPTP Server NOT the client.
Does anyone have any suggestions?
-
-
andrewluck
Forum Veteran
- Posts: 700
- Joined:
- Location: Norfolk, UK
Windows will use a DHCP OPTION to accept routes to put into client, which is a great idea, however MT doesn't use same DHCP server for ppp... so it can't be done. I asked for this to be added back at mum but I don't think mikrotik understood what I was asking : ) I think its option 241 or something - basically you had out routes you want the client to add it their routing tables.
Otherwise, yes, use routing protocols on both sides to exchange routes, however with roaming users (not router-to-router) thats not the best idea.
Sam
Otherwise, yes, use routing protocols on both sides to exchange routes, however with roaming users (not router-to-router) thats not the best idea.
Sam
-
-
MyThoughts
Member Candidate
- Posts: 218
- Joined:
PPP doesn't use DHCP at all. It has it's own protocol to assign addresses. This protocol is not designed to give out routes.Windows will use a DHCP OPTION to accept routes to put into client, which is a great idea, however MT doesn't use same DHCP server for ppp... so it can't be done. I asked for this to be added back at mum but I don't think mikrotik understood what I was asking : ) I think its option 241 or something - basically you had out routes you want the client to add it their routing tables.
Otherwise, yes, use routing protocols on both sides to exchange routes, however with roaming users (not router-to-router) thats not the best idea.
Sam
-
-
MyThoughts
Member Candidate
- Posts: 218
- Joined:
You are correct, PPP doesn't use DHCP in Mikrotik... which if it did would open up much more possibility.PPP doesn't use DHCP at all. It has it's own protocol to assign addresses. This protocol is not designed to give out routes.
http://www.rfc-archive.org/getrfc.php?rfc=3442
RFC3442 defines this option of classless routes via dhcp options.
Handing out NTP servers, DNS servers, WINS servers, Classless routes, and anything else is only possible using DHCP, unless you duplicate a scaled down DHCP server in PPP. Why duplicate the dhcp service for ppp? Why not just let PPP connect and utilize the existing DHCP service to assign attributes to clients? I see DNS and WINS are on the PPP profiles - why not let DHCP do that function?
Microsoft RAS service does it this way... Simply point the PPP profile to a DHCP server entry and let it do the work.
Back to your original note, your right, PPP has nothing to do with DHCP, however there is no reason you can't use DHCP with PPP.
Sam
DHCP works only on ethernet like interfaces.
Windows PPTP server uses DHCP to get an IP address only.
There is no way how to send a route through the PPP itself. All those DHCP options are not being sent over the PPP itself.
See IPCP RFC1332 and show me an option which will give you a route.
This information comes from the developers so you will have to trust this one
Windows PPTP server uses DHCP to get an IP address only.
There is no way how to send a route through the PPP itself. All those DHCP options are not being sent over the PPP itself.
See IPCP RFC1332 and show me an option which will give you a route.
This information comes from the developers so you will have to trust this one
-
-
joeri91942
Frequent Visitor
- Posts: 88
- Joined:
- Location: Sundsvall, Sweden
Actually Normis if you apply the thread title (PPTP) to the question and then look at MS implementation it DOES assign routes!
We have a system running which uses MS RRAS serving WinXP clients using PPTP over Internet, the RRAS server has an internal "loopback" network adapter with a 192.1168.255.x/24 network and a DHCP server serving this network, all incoming clients get their IP from this DHCP server in the range 192.168.255.100-182.168.255.200 IN ADDITION to static routes using option.... 121 (?), can't remember the number right now but I think it is 121.
We had to use this to give the users the ability to reach several internal IP subnets while still surfing using their local connection, "use default gateway on remote network" just doesn't work well if you have high latency to the headoffice on another continent and want to be able to surf while having the VPN up!
/Jörgen
We have a system running which uses MS RRAS serving WinXP clients using PPTP over Internet, the RRAS server has an internal "loopback" network adapter with a 192.1168.255.x/24 network and a DHCP server serving this network, all incoming clients get their IP from this DHCP server in the range 192.168.255.100-182.168.255.200 IN ADDITION to static routes using option.... 121 (?), can't remember the number right now but I think it is 121.
We had to use this to give the users the ability to reach several internal IP subnets while still surfing using their local connection, "use default gateway on remote network" just doesn't work well if you have high latency to the headoffice on another continent and want to be able to surf while having the VPN up!
/Jörgen
I will find this information and post shortly. Basically PPP is the link, but you can stuff whatever data down it you want after IPCP has happened I believe. Either way - let me do my research and come back with some actual pcaps / logs / examples.DHCP works only on ethernet like interfaces.
Windows PPTP server uses DHCP to get an IP address only.
There is no way how to send a route through the PPP itself. All those DHCP options are not being sent over the PPP itself.
See IPCP RFC1332 and show me an option which will give you a route.
This information comes from the developers so you will have to trust this one :)
Sam
If I have to dig further, it's more than likely in the DHCP RFCs.. You can NOT assign static routes via DHCP.
Most linux DHCP implementations - which strictly follows the RFCs, has a option for a static-route. However, you can NOT provide a mask suppler with it. You can thus route a.b.c.d to c.d.e.f, but you can NOT route a.b.c.d/24 to c.d.e.f.
If Microsoft can do it via their DHCP servers, they they are donig something propriatary, which will not follow RFC standards, and which will more than likely work with nothing else except Windows clients...
More to this - even with Radius, PPP does NOT talk to DHCP, neither does the PPP Client requesting a IP Address. DHCP *can* allocate dynamic IP addresses to PPP clients, but this again, is handled by 3rd parties. You can for example, get a dynamic IP address from DHCP via Radius, and let Radius allocate that IP address to the PPP link via Framed-IP-Address.
PPP itself, is a Point to Point connection, its a process on one side of the link, talking to a process on the other side of the link. Further than that, they do NOT interact with anything...
Most linux DHCP implementations - which strictly follows the RFCs, has a option for a static-route. However, you can NOT provide a mask suppler with it. You can thus route a.b.c.d to c.d.e.f, but you can NOT route a.b.c.d/24 to c.d.e.f.
If Microsoft can do it via their DHCP servers, they they are donig something propriatary, which will not follow RFC standards, and which will more than likely work with nothing else except Windows clients...
More to this - even with Radius, PPP does NOT talk to DHCP, neither does the PPP Client requesting a IP Address. DHCP *can* allocate dynamic IP addresses to PPP clients, but this again, is handled by 3rd parties. You can for example, get a dynamic IP address from DHCP via Radius, and let Radius allocate that IP address to the PPP link via Framed-IP-Address.
PPP itself, is a Point to Point connection, its a process on one side of the link, talking to a process on the other side of the link. Further than that, they do NOT interact with anything...
And let's just look at this logically as well on why DHCP will *NEVER* be able to work over PPP.
PPP = Point to Point Protocol. PPTP, L2TP, PPPoE, all operates on top of PPP.
PPP: Client has a.b.c.d, Server has w.x.y.z, Netmask: 255.255.255.255
DHCP, works by a clienting sending a Broadcast, and the server seeing that broadcast.
The fact is, the Client and the Server are in two completely seperated IP networks. The netmask ENSURES (this is why PPP uses a netmask of 255.255.255.255) that NO broadcast packets are transmitted from the Server, or the Client.
When you cant transmit Broadcasts over PPP, *how* exactly are you proposing that the client will be able to send a DHCP request?
Just a thought...
Any PPP implementation that operates via DHCP, uses internal propriaty systems to get a IP out of DHCP manually, and then use that IP as the remote IP for the DHCP link... That, is something completely different, and something that can be done via Radius (again) with *allot* of effort.
You will still not be able to get routes at the client side...
PPP = Point to Point Protocol. PPTP, L2TP, PPPoE, all operates on top of PPP.
PPP: Client has a.b.c.d, Server has w.x.y.z, Netmask: 255.255.255.255
DHCP, works by a clienting sending a Broadcast, and the server seeing that broadcast.
The fact is, the Client and the Server are in two completely seperated IP networks. The netmask ENSURES (this is why PPP uses a netmask of 255.255.255.255) that NO broadcast packets are transmitted from the Server, or the Client.
When you cant transmit Broadcasts over PPP, *how* exactly are you proposing that the client will be able to send a DHCP request?
Just a thought...
Any PPP implementation that operates via DHCP, uses internal propriaty systems to get a IP out of DHCP manually, and then use that IP as the remote IP for the DHCP link... That, is something completely different, and something that can be done via Radius (again) with *allot* of effort.
You will still not be able to get routes at the client side...
I'll find it ... because I've seen it myself. I will see if I can connect MT to a Windoz ppp server and get the debug logging from MT that might show more detail. It's hard to pcap the inside of the tunnel because it's encrypted. However, I can tell you that Windows pptp server hands out DNS, WINS, classless routes (if dhcp option 121/254 are set) and other settings. Before we haggle whether or not its possible I will find an example / capture and we'll go from there.
Sam
Sam
-
-
joeri91942
Frequent Visitor
- Posts: 88
- Joined:
- Location: Sundsvall, Sweden
Hi Savage
Just to save you the trouble of googling for "classless static routes" just let me tell you that RFC3442 does define how to distribute static routes to a client.
When you are saying that "you can NOT provide a mask suppler" you are thinking about the old classfull static routes (section 3.2 in RFC791).
Almost no one (at least I havn't seen it in use since.... 1997 or 98 I think) is using that any more since it implies the subnet mask from the IP number.... that is a 83.x.x.x gets a /8 mask and a 131.x.x.x gets a /16 mask etc (class A, B and C networks)
However option 121 as described in RFC3442 gives us the possibility to hand out SEVERAL static routes in one configuration block, it does this by sending a configuration with one or several sets of bytes where the first gives the length of the significant part of the subnet, followed by the significant subnet numbers and then the route to use for that subnet... example!
To send a route for network 192.168.100.0 with mask 255.255.255.0 using gateway 10.11.1.1 you would configure a line:
- 24.192.168.100.10.11.1.1 (24 bits subnet, 192.168.100 is the subnet and using gateway 10.11.1.1)
For a class B network route you would have something like this;
- 16.10.10.10.11.1.1 (16 bits subnet, 10.10 is the subnet and using gateway 10.11.1.1)
A specific path to one server would be something like
- 32.10.9.8.7.10.11.1.255 (32 bits subnet, 10.9.8.7 is the "subnet/host" and using gateway 10.11.1.255)
And or course you can put several of these descriptors together to give the client several different routes
This is supported by MS implementation of PPTP, actually what they do is to hand out the PPP IP address first to establish the link and then the client requests a DHCP option packet from the remote side.. if the remote end supports option packets it will attempt to fetch one from the DHCP server. Easiest way to see this is by doing several ipconfig / "route print" while connecting a PPTP, you will see the link and the IP and then after a short while you will get DNS servers, routes etc
Best regards
/Jörgen
Just to save you the trouble of googling for "classless static routes" just let me tell you that RFC3442 does define how to distribute static routes to a client.
When you are saying that "you can NOT provide a mask suppler" you are thinking about the old classfull static routes (section 3.2 in RFC791).
Almost no one (at least I havn't seen it in use since.... 1997 or 98 I think) is using that any more since it implies the subnet mask from the IP number.... that is a 83.x.x.x gets a /8 mask and a 131.x.x.x gets a /16 mask etc (class A, B and C networks)
However option 121 as described in RFC3442 gives us the possibility to hand out SEVERAL static routes in one configuration block, it does this by sending a configuration with one or several sets of bytes where the first gives the length of the significant part of the subnet, followed by the significant subnet numbers and then the route to use for that subnet... example!
To send a route for network 192.168.100.0 with mask 255.255.255.0 using gateway 10.11.1.1 you would configure a line:
- 24.192.168.100.10.11.1.1 (24 bits subnet, 192.168.100 is the subnet and using gateway 10.11.1.1)
For a class B network route you would have something like this;
- 16.10.10.10.11.1.1 (16 bits subnet, 10.10 is the subnet and using gateway 10.11.1.1)
A specific path to one server would be something like
- 32.10.9.8.7.10.11.1.255 (32 bits subnet, 10.9.8.7 is the "subnet/host" and using gateway 10.11.1.255)
And or course you can put several of these descriptors together to give the client several different routes
This is supported by MS implementation of PPTP, actually what they do is to hand out the PPP IP address first to establish the link and then the client requests a DHCP option packet from the remote side.. if the remote end supports option packets it will attempt to fetch one from the DHCP server. Easiest way to see this is by doing several ipconfig / "route print" while connecting a PPTP, you will see the link and the IP and then after a short while you will get DNS servers, routes etc
Best regards
/Jörgen
Hmmm, very interesting
I still maintain that a DHCP request, or client routes (at the CPE), is not handled 'in band' inside PPP. There simply is no LCP extentions for it to allow the server and client to neogotiate and agree on it.
Now, I've asked some more people that know a bit more than me (there's always someone up the chain ), and he too confirmed, this is NOT handled in-band as part of the PPP neogotiations.
HOWEVER... OpenVPN, can also apparently do this... Exactly how it is done, will have to be seen. It *could* be that Microsoft's implementation of PPP has some sort of 'additional functionalty' (or call it non RFC compliant if you will), that allows it to neogotiate these things like client routes - but IMHO, it's definately not standard. OpenVPN could be exploiting this to allow it to have the functionality.
The chances that something like this will get into MT?? I think very slim. Last I checked, I don't think MT operates OpenVPN and to introduce it may be more trouble than good due to the IPSec-Tools operating on MT...
For reference sake, another thing I never knew... The correct term for this, is called 'Split Tunneling'... Cisco to Cisco does this VERY good as well
*EDIT*
It would seem the correct way to this with MT then, would be to Authenticate the PPTP connection via Radius, get Radius to allocate IP Addressing via DHCP, and provide the client with a Classless Static Route via DHCP (Yes, I guess I stand corrected afterall 
).
The above URL gives various ways how to achive this from within Microsoft's PPTP Client implementation... I guess the hunt is now on for the *Nix based solution.
I still maintain that a DHCP request, or client routes (at the CPE), is not handled 'in band' inside PPP. There simply is no LCP extentions for it to allow the server and client to neogotiate and agree on it.
Now, I've asked some more people that know a bit more than me (there's always someone up the chain
), and he too confirmed, this is NOT handled in-band as part of the PPP neogotiations.HOWEVER... OpenVPN, can also apparently do this... Exactly how it is done, will have to be seen. It *could* be that Microsoft's implementation of PPP has some sort of 'additional functionalty' (or call it non RFC compliant if you will), that allows it to neogotiate these things like client routes - but IMHO, it's definately not standard. OpenVPN could be exploiting this to allow it to have the functionality.
The chances that something like this will get into MT?? I think very slim. Last I checked, I don't think MT operates OpenVPN and to introduce it may be more trouble than good due to the IPSec-Tools operating on MT...
For reference sake, another thing I never knew... The correct term for this, is called 'Split Tunneling'... Cisco to Cisco does this VERY good as well
*EDIT*
Code: Select all
http://www.microsoft.com/technet/community/columns/cableguy/cg1003.mspx
The above URL gives various ways how to achive this from within Microsoft's PPTP Client implementation... I guess the hunt is now on for the *Nix based solution.
-
-
joeri91942
Frequent Visitor
- Posts: 88
- Joined:
- Location: Sundsvall, Sweden
Hi again
You are completely correct, there is no way to handle this in-band in PPP, I wasn't trying to say that you where wrong in that.. just that MS has some special trick to actually supply DHCP information on a PPTP connection.
I've been trying to find where in ***** I saw the description on how MS does the "get dhcp information packet", if I find it I will post a link
/Jörgen
You are completely correct, there is no way to handle this in-band in PPP, I wasn't trying to say that you where wrong in that.. just that MS has some special trick to actually supply DHCP information on a PPTP connection.
I've been trying to find where in ***** I saw the description on how MS does the "get dhcp information packet", if I find it I will post a link
/Jörgen
Yeah.
What I'm finding (I looked rather extensively today), is that there is no actual RFC regarding Split Tunnels.
All the devices that supports it (Nortel, Cisco, Microsoft, etc), use propriatory client software to do so. In Cisco's case, you *must* use the Cisco VPN Client, otherwise, you won't even be able to get into the VPN, nevermind the Split Tunneling.
It's becoming pretty obvious for me that these companies use their own methods for getting the routes at the client. This is not something generic that is handled by a server, it's definately a custom software solution (both client and server side) to populate the routes at the client.
What I'm finding (I looked rather extensively today), is that there is no actual RFC regarding Split Tunnels.
All the devices that supports it (Nortel, Cisco, Microsoft, etc), use propriatory client software to do so. In Cisco's case, you *must* use the Cisco VPN Client, otherwise, you won't even be able to get into the VPN, nevermind the Split Tunneling.
It's becoming pretty obvious for me that these companies use their own methods for getting the routes at the client. This is not something generic that is handled by a server, it's definately a custom software solution (both client and server side) to populate the routes at the client.
-
-
joeri91942
Frequent Visitor
- Posts: 88
- Joined:
- Location: Sundsvall, Sweden
-
-
BrianHiggins
Forum Veteran
- Posts: 702
- Joined:
- Location: Norwalk, CT
- Contact:
Re: Assigning Routes to PPTP Client?
Guys, it's 2015 now, is there a solution to this problem in MT? I'm trying to route traffic from my VPN clients to other networks over SSTP with no success.... anyone with a solution?
Re: Assigning Routes to PPTP Client?
in windows i disable the default gateway on pptp client
then
i use a .bat to configure static and persistent route to networks on pptp
then
i use a .bat to configure static and persistent route to networks on pptp
Re: Assigning Routes to PPTP Client?
we are in 2020 and even for vpn server there is no road to push.
i have 70 user and i have to add the manual route to the ovpn file
The backup vrrp replication is not there.
Router rb3011 bizarre connection.
Where is routerOS going?
Yet it is the basis.
Please get up ....
i have 70 user and i have to add the manual route to the ovpn file
The backup vrrp replication is not there.
Router rb3011 bizarre connection.
Where is routerOS going?
Yet it is the basis.
Please get up ....
Who is online
Users browsing this forum: Bing [Bot], consoletotherescue and 110 guests