Software Drivers
1x1pixel.gif (43 bytes)

Perle 833IS Remote Access Server Release 6.06

Audience
This document is intended for technical personnel that are involved in the installation and support of Perle 833IS Remote Access Servers.

The following problems were fixed in this 833IS maintenance Release:

  • 833IS would no longer authenticate using NT domain after 16 successful authentication's
  • Radius Stop messages would occasionally not be sent to the configured Radius server when users disconnected from the 833IS
  • Data transfer rate to and from Dial-In clients was improved when using STAC (software compression)
  • 833IS would randomly stop accepting calls on system and expansion S/T cards
  • 833IS would occasionally reboot if clients dialed into the 833IS before it's IPL was complete

The information below is to be used with the information provided in the manual

Additional Information and Clarification on some Existing Features

Perle 833IS Manager

The Manager is not supported under Windows NT Server. It is fully supported however under Windows NT Workstation.

IP Connection Through Routers:

The Manager can communicate to an 833IS through one or more routers. The Manager can discover the Servers using IP broadcasts. However, if the routers do not pass IP broadcasts, you will need to explicitly define the 833IS in the Manager. See the manual section "IP Connection Through Routers" for details on this process.

You will have to explicitly define the 833IS in the Manager if the 833IS appears on a subnet network as the format of the broadcast messages used for discovery will not be recognized across the subnet. Previous releases attempted to discover an 833IS across a subnet, but this would not always succeed as results were dependent on the network topology.

Overview - IP Configuration

For IP, the 833IS looks like a router between two networks. The first network is comprised of the devices on the LAN. The second network, referred to as the "Internal WAN network", is comprised of all IP clients and routers that are dialed into the WAN ports. Setting up a basic 833IS IP configuration requires the following:

  • Defining the network on the LAN side, and defining the address of the LAN router port.
  • Defining the network on the WAN side, and defining the address of the WAN router port. Note: All clients dialed into the WAN see the same address for this WAN router port.
  • Each client dialing in requires a unique IP address. The 833IS supports multiple methods for defining and supplying IP addresses to clients.

For the 833IS router to be able to route IP packets, it has to know how to reach the destination.

The 833IS supports the following methods:

  • RIPV1
  • RIPV2
  • Default gateway.
  • Static routes.
  • Proxy ARPs.

It may be desirable to restrict certain IP traffic. The 833IS has the following features that can be used to do this:

  • Static routes.
  • IP Packet filters.

The 833IS has the ability to forward the address of a DNS or WINS server to a dial in client.

In general, it is recommended to define the Internal WAN network distinct from the LAN network. It is possible to define the Internal WAN network as a subnet of the LAN network, but there are limitations:

  • Routers on the LAN using RIP V1 cannot discover the Internal WAN network, and will not be able to route to the dial in clients on the Internal WAN network.
  • DHCP is not supported for dial in clients in this mode.

Defining the Internal WAN network as a subnet can still be useful if:

  • Routers on the LAN use RIP V2. RIP V2 sends subnet information and any routers on the LAN network using RIP2 will be learned.
  • All WAN traffic uses the configured default gateway.
  • Static routes are defined.
  • The "Enable Proxy ARP" setting is used.

Directed IP traffic from a dial in client will reach another dial in client in the same 833IS. However, IP broadcasts from a dial in client will not reach another dial in client. Most applications will work, but IP applications that rely on broadcast or multicast messages (such as NetBEUI over IP) are not supported.

If a router dials in to the WAN, the 833IS can route traffic from the dial in router to the LAN. This feature is referred to as "LAN-to-LAN". Note that it is not possible to route from this dial in router to a client or router on the Internal WAN network.

WAN Network Address:

All dial in IP devices that are dialed into the WAN appear as if they are on their own IP network. This network is referred to as the "Internal WAN Network". The 833IS also requires one address on this network for the router port. This section defines the Internal WAN Network used by the 833IS and should be completed after consulting with your IP Network Administrator.

In general, it is recommended to define the Internal WAN network distinct from the LAN network. It is possible to define the Internal WAN network as a subnet of the LAN network, but there are limitations:

  • Routers on the LAN using RIP V1 cannot discover the Internal WAN network, and will not be able to route to the dial in clients on the Internal WAN network.
  • DHCP is not supported for dial in clients in this mode.

Defining the Internal WAN network as a subnet can still be useful if:

  • Routers on the LAN use RIP V2. RIP V2 sends subnet information and any routers on the LAN network using RIP2 will learn about the Internal WAN network.
  • Static routes are defined.
  • The "Enable Proxy ARP" setting is used.

To set the WAN Network Address, the following fields are used on the IP configuration screen:

IP Address

Enter the IP address that will be used by the 833AS on the Internal WAN Network for its router port. Be careful to ensure that this address does not conflict with any dial-in client IP addresses.

Subnet Mask

Enter the subnet mask for the internal WAN network

All dial-in client IP addresses, regardless of how they are acquired, must belong to the network defined by this IP Address and Subnet Mask.

Enable Proxy ARP:

Device that are connected on the same IP network discover each other by sending a message on the local network known as an ARP (Address Resolution Protocol). On the 833IS, the Internal WAN network is usually defined as a different network from the LAN network, and ARPs are not used. If the Internal WAN network is defined as a subnet of the same LAN network (as described in "WAN Network Address" in the manual ), Proxy ARPs can be enabled so that a device on the LAN can discover a dial in client. There are some limitations associated with Proxy ARP:

  • IP broadcasts will not be forwarded in this mode. Most applications will work, but IP applications that rely on broadcasts or multicasts (such as NetBEUI over IP) are not supported.
  • There is a small performance penalty if Proxy ARPs are enabled.

The "Enable Proxy ARP" fields has been added to the IP configuration screen. When checked, Proxy ARP will be enabled.

Apple clients

ARA

The native protocol for the Apple Macintosh is AppleTalk. AppleTalk is a transport layer protocol, providing similar functionality to IP. This protocol is used for connecting to native Apple file servers (known as AppleShare), other Macintoshes, and to printers. A remote Macintosh user connects using Apple Remote Access Protocol (ARAP), which provides similar functionality to PPP. Unlike PPP, ARAP can transport only one protocol, namely AppleTalk.

Until recently, a Macintosh user that wished to use ARA would have to purchase Apple Remote Access client. This is now bundled with PPP in a single client called "Remote Access Client", included with the Mac OS. This client supports version 2.1 of ARA.

ARAP cannot be transported "as is" across a digital (ISDN) dial up connection but is supported using V.120 rate adaption.

PPP

PPP was originally available on the Mac using freeware PPP stacks. The two most popular were FreePPP and MacPPP. In Mac OS 7.6, Apple introduced a PPP client which has evolved to the current Remote Access Client.

Recent versions of this client also supports PPP transport of AppleTalk protocol , known as MacIP. MacIP is not supported by the 833IS.

On connect, the 833IS will check with a dial in client to see if it wants to use Multilink PPP. MacPPP does not support this negotiation and will fail. To resolve this, disable Multilink PPP on the PPP configuration screen.

LAN to LAN

Overview:

The LAN to LAN features allows a router to dial in to the 833IS. The network on the router's LAN can then communicate with the network on the 833IS LAN using IP or IPX.

Note that the communication is strictly between the router's LAN and the 833IS LAN for this connection. If a second router dials into the same 833IS, it cannot communicate with the first router.

The 833IS provides flexibility in the connection:

The dial in router can originate the connection

  • The 833IS can originate the connection on power up or if it loses contact with the dial in router
  • A "virtual connection" can be established between the dial in router and 833IS. To save toll charges, it may be desirable to keep the link established between the dial in router and the 833IS only if there is data traffic. You can configure a "virtual connection" in the 833IS, which will keep the dial in session alive but drop the physical link if there is no data traffic. When there is data to be sent to the dial in router, it is dialed automatically and the data is then sent. This automatic reconnect is sometimes referred to as "dial on demand". Similarly, the dial in router can drop the connection, and reconnect to the same session when it has data to send.

Routing Information:

The dial in router and the 833IS need to learn about each other's network. This can be done by:

  • Using dynamic routing. The routers exchange routing information (using RIPs for IP, or RIPs and SAPs for IPX) when they connect, and periodically refresh their routing information when they are connected.
  • Using static routing. Static routes can be defined in the 833IS. Note that routing information can still be sent to the dial up router if static routes are defined.

If a virtual connection ( spoofing ) has been established, but the physical link has been dropped, the link is reestablished if the 833IS receives data that it knows that it has to send to the dial in router. It makes this decision based on the routing information that it has for the dial in router. With dynamic routing, the learned routes are stored for 12 hours. If there is a possibility that the dial in router and the 833IS will be physically disconnected for greater than 12 hours, you should:

  • Use static routes, or
  • Enable auto reconnect. This feature will force the 833IS to reconnect to the dial in router based on the time set in the "Reconnect Every" field.

For IP, by default the 833IS will send RIP V2 with no multicasts so as to be RIP V1 compatible, and receive RIP V1 or RIP V2. This can be changed in the LAN to LAN RIP Setup submenu. For IPX, routing information is always sent for a LAN to LAN connection if IPX is enabled. IPX (as well as other protocols) can be disabled for the LAN to LAN connection in the User Profile.

Note that no routing information is sent for a dial in client that is not defined as LAN to LAN.

It is strongly recommended that the dial in router use a fixed IP address. If a dynamic IP address is supplied (for example, from the Internal IP pool) inconsistent behaviour could result after a physical disconnect/reconnect.

LAN to LAN Connection Timers:

There are timers that affect the LAN to LAN connection behavior, if virtual connection is not enabled:

Inactivity Timeout (User profile)

If there is no data transfer on the link for the duration set in this timer, the LAN to LAN session drops and the physical connection drops. Note that any routing information exchanged between the 833IS and the dial up router will not be considered activity.

Connect Time (User profile)

The dial up router will be disconnected after the time limit set in this timer, regardless of activity.

If virtual connection is enabled, the Inactivity Timeout and Connect Time apply to the virtual session. Timers that affect the LAN to LAN connection when virtual connection is enabled are:

Inactivity Timeout (User profile)

If there is no data transfer on the link for the duration set in this timer, the LAN to LAN session drops and the physical connection drops. Time in the virtual connection state is included.

Connect Time (User profile)

The dial up router will be disconnected and the session will be dropped after the time limit set in this timer, regardless of activity. Time in the virtual connection state is included.

Disconnect If Inactive (LAN to LAN, Virtual Connection)

If there is no data transfer on the link for the duration set in this timer, the physical connection is dropped, but the LAN to LAN session is maintained. This timer is in effect only after the "Connect a Minimum of" timer expires.

* Connect a Minimum of (LAN to LAN, Virtual Connection)

When the physical connection is established, this timer sets the minimum duration that the physical link stays active. A minimum duration may be required if dynamic routing is used (to allow the exchange of routing information).

* Reconnect Every (LAN to LAN, Virtual Connection)

This timer can be used to ensure that the physical link is periodically reestablished so that routing information is exchanged.

If you are using RADIUS as your authentication server, you can configure the RADIUS server to set the Inactivity Timeout and Connect Time.

Authentication:

A dial in router is authenticated in the same manner as any other dial in user. The user ID and password must be set up in the authentication database that has been defined in the Security settings of the 833IS. Authentication that relies on token security (SecureID, Axent) cannot be used with the LAN to LAN feature, as the dial in router has no mechanism for responding to the security challenge. The 833IS will send out PAP and/or CHAP requests as defined in the security settings, and the dial in router PAP/CHAP settings must match.

If the 833IS is calling the dial up router, the dial up router may need to authenticate the 833IS. The login (user) ID and password for the dial in router are entered in the Remote System Login section of the LAN to LAN screen. On connection the dial in router may request from the 833IS:

  • A login ID
  • A login ID and password
  • Neither a login ID and password

Fill in the fields as required by the dial in router. The 833IS supports both PAP and CHAP authentication requests from the dial up router in this mode.

Some routers (for example, some Cisco routers) can be configured to request a login ID even if the router is calling the 833IS. If the router calls the 833IS and requests a User ID and Password, the 833IS will send a User ID of "P833" and a Password of "PERL". This will not compromise security, as the 833IS must still authenticate the remote router against the User ID and Password in the User Record before a connection can be established.

Dialing the router:

If the 833IS is configured to call the dial up router, the phone number of the router is configured in the "Primary Phone Number" field. When the 833IS needs to dial out, it will use an available channel that is enabled for dial out. You may wish to ensure that the 833IS always has a channel to dial the router. This can be done by enabling "Reserve Channel" and selecting the reserved channel from the drop down menu.

If the call type is defined as analog, a modem enabled for call back will also be required. If no modem is available, the dial out will not occur.

If "Enable Multilink PPP" is enabled, the 833IS will use two channels to connect to the dial out router. Enter the phone number for the second channel in the "Secondary Phone Number" field.

Callback should not be used to have the 833IS call the dial in router. If callback is used, the router will be treated as a standard dialup client. Routing information will not be exchanged, and the LAN to LAN connection timers will not be used. Always use the dial out parameters reserved for the LAN to LAN function.

Client Virtual Connection

This feature is can be used by remote IP or IPX dial in clients to save on connection charges. With client virtual connect enabled, the client can drop the physical connection, but the 833IS will keep the session active. The client can then reconnect and the 833IS will reassign the same session, and client IP address.

There are timers that affect the Client behavior. If virtual connection is enabled:

Inactivity Timeout (User profile)

If there is no data transfer on the link for the duration set in this timer, the client session drops and the physical connection drops. Time in the virtual connection state is included. If "disabled" is set for inactivity timeout, the session will be released after 10 minutes in the virtual state. This is to prevent an unused session from being tied up permanently.

Connect Time (User profile)

The client will be disconnected and the session will be dropped after the time limit set in this timer, regardless of activity. Time in the virtual connection state is included.

If you are using RADIUS as your authentication server, you can configure the RADIUS server to set the Inactivity Timeout and Connect Time.

To be effective, the dial in client should support virtual connect. It should have a mode that:

  • Drops the physical connection if inactive, but not notify the application of disconnect
  • Automatically reconnects if data is to be sent

Reconnect to the 833IS is driven solely by the client in this mode. The 833IS cannot redial the client. In practice this is not a real limitation, as servers will typically only send data in response to a request from the client. However, if you are using a client application that supports unsolicited data from a server, you can configure the LAN to LAN feature for use with a dial in client.

Configuring the ISDN BRI Line Interface

The 833IS needs to synchronize with the ISDN line. All BRI lines connected to an 833IS must be driven from the same clock. In most applications, the 833IS is connected to the telco network, and all clocks from the telco are guaranteed to be derived from the same clock. If you are connecting the 833IS to a PBX, ensure that the PBX is providing the line clock.

An S/T line can be ordered (or configured, if on a PBX) such that clocking is not supplied unless a call is active on the S/T line. It is strongly recommended that at least one S/T BRI line always provide line clock.

The 833IS will synchronize to the lowest number BRI line that provides clocking. When clocking is lost, it will switch to an internal clock while it looks for another BRI line providing clocking. Although this process is quick, calls on other BRI lines that are active while this clock is re-synchronizing could experience data errors.

A BRI line will be assigned a phone number per B channel. However, it is not safe to assume that the phone number is tied to the channel. When a call comes in, it signals on the D channel what B channel the call is on, and what phone number is used. Thus it is possible to get a call on the first B channel from the second phone number.

Unless you are guaranteed that the call from the first phone number will always use the first B channel, and the second number on the second B channel, it is recommended that the channel attributes be set the same. That is, both channels should be set the same for dial in, dial out and call back.

Some BRI subscriptions are designed to allow only one of the two B channels to make outbound analog calls. If your BRI line has this restriction, you will be able to use dialout or perform an analog (modem) callback on one channel of the BRI only. Such subscriptions do not restrict the number of inbound analog calls or ISDN digital outbound calls.

User Callbacks

You can enable both roaming and fixed call back for a single user. If both are enabled, the 833IS will call back the roaming number if it is supplied at connect. If it is not supplied, fixed call back will be done. The dial in client must support both fixed and roaming call back for this to work.

DHCP

In DHCP a "scope" is defined as "An administrative grouping of computers running the DHCP client". These computers are grouped according to a range of IP addresses. Simply put, all dial in clients on an 833IS share the same scope, namely the range of addresses defined for the Internal WAN network.

On the DHCP server, you must define a scope that matches the IP address range for the dial in clients on Internal WAN network. Ensure that the IP address of the Internal WAN network itself is excluded from the scope, so the DHCP server does not attempt to assign this address to a dial in client.

Secure ID

The 833IS support Secure ID on analog calls only. The 833is does not support Secure ID on a ISDN digital (Sync PPP) connections.

V.90 Modems

A V.90 modem obtains its high data rates by treating the analog data line as an imperfect digital line. This "digital line" appears to the modem as having a number of impairments, and the modem during negotiation attempts to determine what impairments exist, then compensate for them. Certain connections (for example, some GSM modem connections) can trick this negotiation. If this occurs, either the modems will not negotiate, or they will connect, but the data error rate will be so high as to make the connection impractical.

If these problems are encountered, it is necessary to prevent the modems from attempting to negotiate V.90. Modems have parameters that can be set to disable the V.90 modem.This can be done either in the client modem or by setting the Modem Initialization String in the 833IS modem.

ISDN BRI S/T Interface Termination

A BRI S/T interface requires line termination. The NT1 telco termination point that the telco provides usually provides the 100-ohm termination.

However, some telcos require that this 100-ohm termination be provided within the customer equipment. Check with your telco to see if it is necessary for the 833IS to provide this termination.

An improperly terminated BRI line may cause line errors on the BRI line. This would typically be seen as a dial in client abnormally losing connection.

The 833IS ships with termination disabled. Termination is enabled using jumpers on the System Card and (if installed) Expansion Card. There is one pair of jumpers for each interface:

  • JP250 - BRI 1
  • JP350 - BRI 2
  • JP450 - BRI 3
  • JP550 - BRI 4

To enable termination, use the supplied jumpers (attached to the jumper block) to jumper the two top jumpers together and the two lower jumpers together.

 

Enable 100 termination - Jumper block

To disable termination, remove the jumpers.

 

Disable 100 termination - Jumper block

Note that a BRI U interface has no user adjustable termination.

Non-Conformances Resolved in V6.0

The following product non-conformances in the 833IS were resolved;

A number of problems were corrected where under certain conditions;

  • the Ethernet interface could stop responding.
  • the 833IS would automatically reboot due to an 833IS error condition.
  • the 833IS would lock up.

A case where on some single board 833IS’ units,the 833IS would lock up when an expansion board was added.

BCD conversion software in the 833AS was calculating incorrect dates for the month of October. October dates are now correctly displayed.

Under certain conditions, the 833IS Manager could not reset the 833IS.

Under certain conditions, the Manager would not correctly save some parameters. An example of this was where some NT Domain authentication parameters could not be saved in the Japanese Manager.

Under certain conditions, the Manager would not correctly display some parameters. An example of this is was where IP parameters were not being displayed.

The Manager no longer waits an excessive time before resending a packet from the 833IS that was lost due to a line error. This long wait gave the appearance of the Manager being locked up.

Under certain conditions the 833IS would disconnect from the Manager, but the Manager would think that it was still connected. In this state the Manager could display information but could not change it ("read only mode").

The Manager now disallows configuring a host IP address of 0. Customers were incorrectly configuring the WAN IP address/subnet mask to an invalid host IP address of 0. If set incorrectly, the 833IS would operate but exhibit a number of unusual symptoms.

Under certain conditions, a user's dial in session would lose the ability to "surf". The modem would be connected, and the modem lights would show data being sent, but there would be no reply. When the user called in again, the connection would be fine.

STAC compression with Windows DUN 1.3 client now works reliably. If software compression was enabled on both the 833IS and the DUN 1.3 client, the user would suddenly stop "surfing" at some point during the dial-up session. This has been corrected to work with DUN 1.3 clients using software compression.

Ethernet "bytes transmitted" statistic in the 833IS Manager now reflects the correct value under all conditions.

Under certain conditions, a configuration file upload to the Manager would fail, and the error message would read "Unexpected file format".

ARA clients would not operate correctly under version 5.8. ARA clients will now connect under all supported conditions.

On power up, the 833IS would wait an excessive time ( 11 minutes ) to connect to a dial in router that was configured for autoconnect. This has been corrected to reconnect as soon as the 833IS has completed its power up cycle.

IP address filters would not work consistantly

Under certain conditions, a dial in user would be disconnected after the amount of time set in the inactivity timer even if the connection was active.

Under certain conditions, the 833IS would restrict the number of simultaneous BCP or NetBEUI sessions to one.

Under certain conditions, a dial in client would stall on connect. For example, with Win 95/98 clients, the message displayed when stalled would be "Verifying User ID and Password".

Deleting a User from the Local Database no longer requires a reboot to take effect.

Under certain conditions, the TTY window displayed during an Axent Defender connection would freeze displaying a "?".

Callback will now be correctly restricted to defined groups if "Use exclusively" is set.

MacPPP (an old Mac client) and some old Unix PPP clients could not correctly connect. This is due to a limitation in these clients, as they cannot correctly handle the PPP negotiation if multilink PPP is presented as an option from the 833IS. A feature was added to allow multilink PPP to be disabled in the 833IS and can be enabled if it is necessary to support these clients.

Under certain conditions, a channel could get into a state where it could no longer accept a digital call.

The LAN to LAN feature has been enhanced to support "two way" authentication. Some routers require the 833IS to authenticate with the dial in router even if the dial in router called the 833IS.

The 833IS will now reliably bring up a virtual LAN to LAN connection.

RIP packets are now consistently sent to a dial in router from the 833IS.

The LAN to LAN feature now supports dial in routers that do not require any authentication.

If autoconnect is configured for a LAN to LAN connection and a connection attempt fails, the 833IS will space reconnect attempts one minute apart. Previously, the 833IS would do the next attempt immediately after the previous attempt.

If a Dial on demand connection attempt fails (typically because the dial in router is busy/not answering), the 833IS will now retry 2 times (attempts spaced one minute apart) before discarding the packet that caused the dial on demand.

RADIUS accounting would occasionally display invalid results.

Support for Proxy ARPs was added in Release 5.8, but these were by default always enabled. Default in this release is to Disable Proxy ARPs, as most 833IS applications do not require them and there is a small performance penalty if they are enabled. There is now an "Enable Proxy ARPs" checkbox on the IP screen that permits these to be selected.