I had my tungsten C authenticating to redwall's pptpd, but then I had trouble getting packets from PPP to Eth0, and the mailing list/forum wasn't that helpful And redwall seems moribund, so I'm tentatively switching to "devil linux". Devil linux appears actively maintained, and people appear eager to help. It's also based on "linux from scratch", which probably bodes well for it being maintained into the future. Unfortunately, pptpd authentication isn't working for me, despite trying vanilla DL configs, as well as configs that borrowed from my redwall setup. The poptop howto indicates that the production release is 1.0.1, and the development release is 1.1.2. The author further indicates that the dev release works better. DL is using 1.2.1. Redwall was using 1.2.0b3. I need to also compare modules.conf pptpd entries. Too much trouble. Is DL's options.pptp really supposed to be options.pptpd? how can I syslog ppp/pptpd debugging info? Make sure /etc/ppp/options is blank some things don't work unless compiled as kernel modules ppp_generic module is required to get ppp_mppe working also need pppd module for encrytion to work pppstats sounds useful
2004-10-29 I've had devil linux authenticating my PPTP for a while now, off my Tungsten C, bringing me back to the point where I was before on redwall. I just don't seem to be able to find time for this project, unfortunately. The next step, is to set up my ssh tunnels via an rc script, and test if I can connect to them or not (I couldn't on redwall - it required some iptables magic, and I switched to DL before the search for the magic incantation terminated).
/etc/ppp/ip-up is apparently run whenever a new ppp interface is created. This might be a really got spot to fire up my ssh tunnels from, since the ssh command I'm using wants to bind to a ppp address.
devil linux' initial root password is empty
run "setup"
subsequent changes are made with vi. :) Run save-config afterward, much like on redwall.
Configure services by editing /etc/sysconfig/config (approved method? Seems to work though)
It's working :)
This route command was needed on dcs.nac to get things working: route add -net 192.168.0.0 netmask 255.255.255.0 gw 128.200.34.80 ...however, I suspect that if I change my firewall rules to masquerade, I won't need this anymore.
I eventually changed my iptables setup to use masquerading, so that I wouldn't need strange routes anymore.
I'm likely going to ditch some or all of my ssh tunnels, because they have a poor interaction with services that use IP-based authentication. I'm hoping OpenVPN will work out better. However, to my dismay, dcs.nac doesn't appear to have the "tun" kernel module anymore, which is apparently required by OpenVPN. Francisco indicates tun was removed by Redhat because it was not yet well tested on x86_64 systems.
2004-11-15 My devil linux config floppy committed suicide :(. Fortunately I have at least a partial backup. :)