We are testing ATM PPP authentication on the TA 600 series. So far we have been able to get the IAD to authenticate PPP for routed mode with NAT to the ethernet interface. However we have two other scenarios that I would like to get assistance with:
IAD performs PPP auth for user and bridge PPP assigned IP address to the ethernet port
User on ethernet port configures PPPOE and auth is passed upstream. Authentication is assigned directly between user behind ethernet port and the upstream radius server and user gets IP handed to him via PPP
Please let me know what is the proper way to accomplish these methods. Thanks!
For scenario 2 - that sounds like basic bridging, doing PPPoA. Your PVC will be configured for PPP and "Bridge All" (instead of Route IP). Once the PVC and PPP link are up, all ethernet traffic is bridged across the PVC.
For scenario 3 - you may be able to get that to work by configuring the PVC for IP and "Bridge All". The TA is not doing any PPP negotiation but will bridge all IP traffic once the PVC is established.
Hope this helps,
Scenario 3 is now working. For scenario 2, what would be ideal customer side config on Ethernet port? Should it be DHCP or static IP or could it be either/or? We would like for it to be static IP and have the IAD do PPP auth transparent to customer. In this situation, would there be any special config in IAD or radius server if it is usually set to hand the IP out dynamically via PPP?
I'm not really sure what you're asking here. If the TA600 is configured for Bridging, then the Ethernet IP has to be statically assigned. If you are doing IP routing, the PPP interface can be dynamically assigned, but the Ethernet IP still has to be static. If you are doing IP routing, then the TA600 can act as a DHCP server to the end equipment, but if you are bridging, then the TA will not act as a DHCP server, but DHCP can be passed over the bridged connection.
As far as PPP auth transparent to the customer, the TA does not do any PPPoE, but when in BRIDGE mode, it will pass all IP traffic over the bridged connection, so the end equipment can authenticate to the radius server.
I guess my question is: What is the purpose of having PPP authentication capability when the PVC is set to bridged? How is this setting usually used? I'm talking about setting under L2 Protocol under T1 PVC. Why have a PPP mode option with username/password when the IAD is set to bridge and expecting this from the ethernet port device?
Generally, if you are doing PPP (even without authentication on the PPP interface) the equipment on the LAN does not need to authenticate; however the only way to allow authentication from the LAN equipment (through the TA600) is to configure it in BRIDGE mode, so all IP traffic is passed. The PPP connection on the TA600 can be configured to require authentication, or not. Either way is fine with us.
Is it possible to have the IAD auth for the LAN equipment but bridge the IP connectivity for the PVC to the LAN equipment at the same time?
I don't believe we are on the same page, yet. In the TA600, under the L2 PROTOCOL, the PPP authentication is to require the two devices negotiating the PPP protocol to authenticate with each other. It is an additional security measure in order to keep the connection "trusted". Part of the PPP negotiation is whether authentication is required or not. On a point-point connection authentication is rarely used, but when PPP was introduced years ago, many PPP connections were over a dial-up connection, and the authentication was required so the PPP server could identify who was dialing in and if the connection was allowed/authorized.
The TA will not negotiate PPP and then send any type of other authentication (like to a RAS server), so any additional authentication has to be done by equipment external to the TA600.
If we use the same configuration but set the mode to routed instead of bridged, authentication passes and we obtain an IP on the IAD's T1 routed port as configured in the upstream RADIUS server. If we set the mode to bridged but do not provide PPP auth then a device behind the IAD ethernet port can do the PPP auth and acquire the IP.
Our desired functionality is to have the IAD in bridge mode but somehow perform PPP auth in the IAD and allow the device behind the IAD to obtain its IP without PPP auth configuration. The device behind the IAD would either have it's IP configured by DHCP or static IP. So basically, the need is to PPP auth in the IAD but allow the connection to be bridged. The only reason I question the possibility of such a configuration is because even in bridged mode the IAD still lets you configure PPP authentication. To me, if PPP auth was not supported in bridge mode configuration then the fields should not be configurable.
1. We DON'T want the equipment on the ethernet port of the IAD to do PPP auth.
2. We DO want the connection to be bridged.
3. We DO want the IAD to do PPP auth.
I'm going to have to say the TA600 is not going to do what you want. There are no additional configuration options in the unit.
However, when it is configured for BRIDGING, you can still do PPP authentication. This is an optional part of the PPP protocol and is available for either IP Routing or Bridging. When the IAD is configured for bridging it cannot be dynamically assigned an IP address, but once PPP is negotiated (LCP and BCP are both up - Link Control Protocol and Bridging Control Protocol) then all ethernet traffic is transmitted across the PPP link. So when the end equipment sends out a DHCP request (which is a broadcast) it is transmitted across the PPP link and the equipment at the other end of the link should receive it.
If the TA600 is configured for IP routing, then it can also act as a DHCP server and assign IP addresses to the equipment off the ethernet port. (It can only assign an IP address within the same IP range of its own ethernet port address.) (For routed PPP, LCP and IPCP will both be UP under the PPP status.)
I went ahead and flagged this post as "Assumed Answered". If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons. This will make them visible and help other members of the community find solutions more easily. If you have any additional information on this that others may benefit from, please come back to this post to provide an update. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.