> I'll see what I can find out about L2TP, but from what I understand of
> it we'd have to build L2TP into the application server.
Correct
> The frustrating part is that the PM 3/4 is so close to meeting our
> needs, and this shortcoming is so *arbitrary*. There's no fundamental
> reason why you can't look up caller ID from the tcp stream information,
> the capability just isn't in there.
Actually there us a fundamental reason to not put it in the TCP stream. If
we do it is no longer a TCP Clear connection. We are now modifying the data
flow. TCP clear is intended to pass the data unmodified to the
application.
Have you tried putting the users in the local passwd file and not using
call-check but just using default entries. You can then assign the users to
groups based on what application they are authorized to use. For example:
DEFAULT Auth-Type=System, Called-Statation-ID="5551111",Group="App1"
Service-Type = Login-User,
Login-Service = TCP-CLear,
Login-IP-Host = 192.168.1.4
Login-TCP-Port = 23
DEFAULT Auth-Type=System, Called-Statation-ID="5551112",Group="App2"
Service-Type = Login-User,
Login-Service = TCP-CLear,
Login-IP-Host = 192.168.1.5
Login-TCP-Port = 23
DEFAULT Auth-Type=System, Called-Statation-ID="5551113",Group="App3"
Service-Type = Login-User,
Login-Service = TCP-CLear,
Login-IP-Host = 192.168.1.5
Login-TCP-Port = 23
This would route them to the correct host based on the called-Station-Id but
would also requide them to be a member of the group specified to be
authenticated for that server. You could then assign the users to groups
and places them in the system file.
-- Thomas C Kinnen - <tkinnen@ra.lucent.com> <tkinnen@sobhrach.com> [RADIUS Test Engineer] - LUCENT Technologies RABU "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer" - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message. Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>