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
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.