Dude! Call me tomorrow...sounds like we have a lot to talk about! Also sprach Stephen Amadei
Here's the scoop... we are moving our TC's out of our main NOC to save on backhaul charges... the problem is that now that our TC's are going to live on separate networks, we have two dilemmas: Static IP addresses are unable to move freely between POPs, and we cannot offer content filtering.
A dynamic routing protocol like RIPv2 or OSPF won't work for you for the moving of static IP addresses? And then strategic positioning of the filtering box could work...
The solution, IMHO, is to make all our content filtered users use IP's from a static IP pool, and tunnel all these "portable" static IP addresses back to our main NOC, behind our filter box. So I built a linux box with lots of IP tunneling stuff, including PopTop (the PPTP server) and L2TPd.
Our clients are supposed to not notice anything strange... except that it works. Their accounts are defined in our radius (I have two sample configs, one using L2TP and another using PPTP) using Tunnel-Type="PPTP" (or "L2TP") and Tunnel-Server-Endpoint="our LNS/PNS". No other settings have been changed on the USR-TCs at all.
With PopTop, I compiled it so that it would give out addresses to specific users. Upon trying PPTP, the client dialed in, and a tunnel was created but PopTop complained that it doesn't understand Message type 9, an "Incoming-Call"... as it turns out, PopTop is not a PNS at all... but a PAC... it seems the Windows world got the PPTP implementation backwards and most vendors have it all backwards... so it looks like PopTop is a dead end. The client was unable to connect, so it dropped... yet the tunnel from the USR-TC to the PNS stayed up! Wierd.
Uhm...that's really odd...PNS should be the PPTP equivalent of LNS in L2TP...weird...you don't want to use PPTP anyway...it sucks!
So I tried our sample L2TP client. L2TPd won't allow giving out Static's based on user, but I suppose I could code that myself.
Sure it will...or more accurately, pppd will. L2TP has nothing to do with IP allocation inherently...
Anyway, the client connected, and a tunnel was built, but it looks like the PPP session dies.
Quite possible. "debug" in /etc/ppp/options is *most* useful here.
The client disconnects, yet the tunnel remains according to the Hiper ARC.
Quite possible that the tunnel is sticking around, but the individual session within the tunnel is dying.
At least the PPPd session appeared to give out a valid IP address. The server squawked about not having handlers for LCP, but PPPd gave me no real reason for dying.
Well...here's a possibility... I think, from the sounds of it that you're setting it up to tunnel based on userid in RADIUS. This means that the client is having to do LCP and PAP/CHAP/whatever at the Arc, then the Arc gets the RADIUS response back, sets up the tunnel, and then the linux box starts firing LCP over the tunnel at the client. So the end client system sees LCP, PAP/CHAP/whatever, then starts doing IPCP but instead gets a new round LCP thrown at it. *Theoretically*, this is within the PPP spec...an implementation can return to LCP at any time...but in practice, I haven't a clue how most systems would handle that.
Anyway, I am stumped. Is anyone really using tunnels from the Hiper Arc successfully? Could post me some baby steps to help straighten me out?
No, but I'm *VERY* interested in working with you on this. Check out http://www.sourceforge.net/projects/l2tpd if you haven't already. We're doing some L2TP stuff here thanks to Cincinnati Bell's oh-so-screwed-up DSL network. The only l2tp software really available and functional for Linux was the l2tpd at marko.net. You'll notice there hasn't been a release there in over 2 years. So I, and a couple of our customers have taken on development work on l2tpd. There are a *LOT* of bugs in l2tpd, but I've worked out quite a few already. Anyway, I'm *very* interested in anyone's experience with running this software with any other L2TP implementation. We've confirmed interoperability at this point with RedBack SMS AOS, Cisco 3000 VPN Concentrators, and believe (but haven't confirmed) interoperability with Cisco IOS 12.0, and 12.1, and w2k (using l2tpd as an LNS). Anyway...gimme a call tomorrow and we can work through what you're doing and what needs to be done. (502)966-3848 ext 1153. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.