Subject: (usr-tc) Tunneling... PPTP or L2TP, I don't care!

From: Stephen Amadei <[email-masked]>
Date: Wed, 18 Apr 2001 23:29:39 +0000

Hey guys.

I have finally been able to put a nice little LNS/PNS on our server.

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.

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.

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.  Anyway, the client
connected, and a tunnel was built, but it looks like the PPP session
dies.  The client disconnects, yet the tunnel remains according to the
Hiper ARC.  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.

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?

Thanx.

					----Steve
Stephen Amadei
Dandy.net CTO
Atlantic City, NJ

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 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.

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 19 Apr 2001 04:44:46 +0000

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

>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-