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
http://www.microsoft.com/technet/community/columns/cableguy/cg1003.mspx
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.