There are two ways to configure your network architecture to allow the NetServer to route iPass access requests. These configurations vary depending upon where the NetServer is installed in relation to your NAS and AAA servers.
The following details are available:
The most common configuration, and the one iPass recommends, places the NetServer behind the provider's entire authentication system. In this scenario, all incoming authentication requests are received by the NAS and forwarded to the RADIUS AAA server. The RADIUS server performs the primary sorting and routing functions, separating iPass users from the provider’s other users.
When iPass requests are received, the RADIUS server will forward the packets to the NetServer, which will then forward them to one of the iPass Transaction Centers. The RADIUS server will recognize all other packets as provider requests and authenticate the users accordingly.
This solution can only be implemented if the existing RADIUS server supports proxy.
In this scenario, the NetServer will perform the primary sorting and routing functions, separating local users from iPass customers. The NetServer will scan the realm of each packet, and route all requests with the IPASS/ prefix to an iPass Transaction Center. All other packets will be routed to the local AAA server for authentication.
To support this type of network architecture, you must reconfigure the NAS to proxy all access requests to the NetServer rather than the AAA server. To do so, you will need to use the NAS configuration utility to allow the NAS to forward all authentication and accounting requests to the NetServer's IP address, port numbers, and the shared secret listed for the NAS in the ipassNS.properties file.
For additional information about configuring your NAS, please refer to the documentation included with the software or contact the manufacturer for assistance.
ipassNS.properties File
The main NetServer configuration file is called ipassNS.properties. By setting properties in the file, you can enable or disable NetServer functions. (Enabling some features might involve setting more than one property.)
NetServer will periodically upload its encrypted ipassNS.properties to an upload server, including at startup. This information will be used for diagnostic and troubleshooting purposes across the iPass network.
An example of the ipassNS.properties file is shown in Appendix 1.
Property names are case-sensitive, but property values are not. Valid values for Boolean properties are: true, false, yes, no, y, n.
For information on particular properties, see the Property Glossary.
Before first running NetServer, you must perform some initial setup tasks and receive a digital certificate from iPass. This section explains how to complete these tasks.
You will be running the <NS_Home>/bin,run ipassconfig.csh -conf script.
NetServer configuration consists of the tasks in this checklist. Page indicates the page of this document where the procedure is described in more detail.
Task | Page |
---|---|
1. Set initial configuration by running ipassconfig.csh -conf | 16 |
2. Enroll an iPass Transaction (ns) Certificate for the NetServer. | 17 |
3. If necessary, configure your RADIUS server for iPass traffic. | 36 |
4. Test the installation. | 18 |
Initial configuration is done by running the ipassconfig.csh script, which sets many of the properties in your ipassNS.properties file.
To initially configure NetServer:
In <NS_Home>/bin,run ipassconfig.csh -conf. Supply the requested information as outlined here. For each script entry, the value shown in square brackets [] is the default. Where applicable, you can press enter to use default values.
1. Time, Date and Timezone Verification: (Default Value=Yes)the date/time stamp must be correct and correspond with the information in the iPass database in order to validate the certificate.
2. Customer ID: (Default Value=1) Enter your customer ID, supplied by iPass. This is the same ID number used on your iPass Web site login.
3. Debug Level: (Default Value=0): Debug level determines how debugging and error messages are logged to a trace file. Debug level can be any value from 0 to 5, with 0 generating only critical error messages and 5 generating the most detailed and extensive amount of information. Production servers should normally be run with a debug level of 0. See Trace Log Fileon page 30 for more information.
4. Authorization Port: (Default Value=11812) Enter the NetServer authorization port. iPass recommends you use port 11812.
5. Proxy Listening Port: (Default Value=11817) Enter the NetServer proxy listening port. iPass recommends you use port 11817.
6. NetServer requires a keystore for the SSL encryption (either for NS to TS communication or for EAP mode). The different types of keystores for NetServer include:
KeyStore1=KeyStoreType=eap,KeyStorePath=$ipass.server.home/certs/eapserver.keystore,KeyPassword=UfGjld0YWEUjEIZUnNvIsA==,KeyStorePassword=UfGjld0YWEUjEIZUnNvIsA== Would you like to: (E)dit or (K)eep the keystore settings: [K] K
KeyStore2 does not exists. Plesae Edit the keystore settings: KeyStoreType=ns Please enter the KeyStorePath:[/usr/ipass/netserver/current_version/certs/ns1.keystore] /usr/ipass/netserver/current_version/certs/ns1.keystore Please enter the KeyAlias:[ns] ns Please enter the CertAlias:[ipassca] ipassca Please enter the Salt:[iPassNS] iPassNS Please enter the KeyPassword:[changeme] changeme Please enter the KeyStorePassword:[changeme] changeme New Server 2 settings: KeyStoreType=ns,KeyStorePath=/usr/ipass/netserver/current_version/certs/ns1.keystore,KeyAlias=ns,CertAlias=ipassca,Salt=iPassNS,KeyPassword=<HASHED PASSWORD>,KeyStorePassword=<HASHED PASSWORD> Attempting to set Property (KeyStore2) with value KeyStoreType=ns,KeyStorePath=/usr/ipass/netserver/current_version/certs/ns1.keystore,KeyAlias=ns,CertAlias=ipassca,Salt=iPassNS,KeyPassword=<HASHED PASSWORD>,KeyStorePassword=<HASHED PASSWORD>
7. To complete installation you will need to obtain a signed certificate from iPass. For more details, please visit our iPass Certificate Enrollment help page.
Upon completing the steps, tool will prompt for the CSR generation process. It is necessary to enter the appropriate values that are associated with the CSR property, otherwise make use of the default value,Verify the similar console output as given below : Would you like to generate the Private key and Certificate Signing Request for KeyStore2:[yes/no]yes Key Size[2048]2048 Country code [US]US State or Province Name [Some-State]Some-State City or town [Some-City]Some-City Company Organization name [Some-Organization] Enter the public IP address by which this system is known to the outside world. If this system has multiple IP addresses, please specify the address which will appear as the source address for connections to the iPass authentication servers. This address will be used for authenticationand authorization purposes by the iPass software.:[192.168.232.154] Enter the fully qualified domain name by which this system is known to the outside world. If this system has multiple domain names, please specify the name which is to be used for iPass purposes. This domain name will be used for authentication and authorization purposes by the iPass software.:[bld-qa-net12] Enter your e-mail address:[user@domain.com] On pressing Enter it generates keystore for SSL connections as : Will be generating keystore for SSL Connections Press enter to continue... Generated Certificate request successfully, and saved it to: /usr/ipass/netserver/current_version/certs/mail_cert_req2.data
7a. Import the contents of the certificate to KeyStore [/usr/ipass/netserver/current_version/certs/ns1.keystore] using the following command:
/usr/ipass/netserver/current_version/bin/ipassconfig.csh -import_cert <KeyStoreProperty> "<Signed_Certificate_File_Path>"
8. Transaction Servers: (Default Value=no). If you wish to configure your NetServer to communicate with the iPass transaction servers, enter yes. You will need to enter each server's IP address and other relevant configuration parameters.
9. RADIUS Clients: (Default Value=yes). If you wish to configure your NetServer to communicate with your RADIUS clients, enter yes. You will need to enter each server's IP address and other relevant configuration parameters.
List your NS keystore certificate
To list your certificate, in <NS_Home>/bin, run the script list_NS_keystore.csh.Usage is :
For example : ./list_NS_keystore.csh ../certs/ns1.keystore changeme
It will list the certificate chain entries, valid from and valid to dates, Issuer, Owner and imported ipassCA details. KeyStore certificate entries in ipassNS.properties should be valid/non-expired in order to start NetServer.
You can rerun the script after initial configuration to add, edit or delete properties, as needed. If you rerun it, the script will read the default values from the existing ipassNS.properties, so you won't have to re-enter those values.
For example, two months after you install NetServer, you decide to add a secondary authorization server. You would run ipassconfig.csh -conf, skip all the questions not having to do with authorization servers by entering default values (press Enter each time), and only enter the configuration information for the new authorization server when the script requests this information.
The Netserver comes equipped with EAP-TTLS authentication using its on-board eap.keystore and 2048-bit RSA Server Certificate issued by Thawte to netserver.ipass.com on behalf of iPass Inc. This authentication mode runs in parallel with standard RADIUS authentication at the listening port.
Using a single iPass configuration profile for TTLS/X globally, the Netserver assists in tunneling the iPass EAP-ID's second-phase authentication (GTC, PAP, CHAP, MSCHAPv2, EAP-TLS, EAP-SIM) over the iPass Federated AAA fabric so that it emerges from the iPass Roamserver located at the Home AAA. The tunneled authentication must contain an @domain in the credential's User-Name so that it can be routed correctly. If the Home AAA Accepts the phase two authentication, then the session is granted by the Netserver.
This TTLS Authentication Method not only simplifies global provisioning and provides additional security all-around by allowing for advanced authentication at the Home AAA, but it also provide a highly secure “wrapper” around Legacy-based standard RADIUS authentication methods for customers that do not support advanced authentication at their AAA.
EAP-RADIUS can be configured to pass-through the Netserver to iPass by protocol number. By default only TTLS tunneled auth is enabled.
Note that in order to pass EAP-enabled RADIUS traffic over iPass without using the Netserver's native EAP-TTLS tunneling mode will require additional provisioning and policy by iPass.
To use Anonymous identities and automatic Chargeable-User-Identity reversal when transacting over EAP-enabled networks, a set of pre-configured authorized ID Tokens are provided, e.g. anonymous@ipass.com. Otherwise - to prevent Tunnel Fraud - the User-Name of the tunneled phase two authentication must be reflected somewhere within the EAP-Identity during the initial Access-Request, e.g IPASS/user@home.com@ipass.
Please consult with your iPass representative about advanced network implementations using both standard RADIUS and EAP Authentication Methods facilitated by an iPass Netserver.
Once you have finished configuring your NAS or RADIUS to route iPass access requests to your NetServer, you must test your network to ensure proper functioning. Before configuration testing, ensure that you have set up the NetServer as a client of your RADIUS.
There are two configuration tests you need to perform:
The checkipass test verifies that the NetServer can communicate with the iPass Transaction Server. When ran in SSL Mode, the request passes through the corporate firewall to the iPass Transaction Server.
[options]
Your options are:
-p <password> | Specifies the user password. Otherwise, you will be prompted for it. |
-host <hostname or IP> | Host Name or IP address to send request to. |
-port <port number> | Port number of the destination host. for RADIUS, this would be the authentication port. |
-type <request type> | Request type. Default is normal. Choices are auth, acct, start, stop, all, normal. |
-keystore <KeyStoreProperty> | KeyStore name to be used to ssl connection. |
-timeout <timeout> | Timeout, in milliseconds, to wait for a reply. Default is 60000 milliseconds. |
-aaa_auth_server <number> | Specify which AAA Authentication Server should handle the request from the RoamServer. |
-aaa_acct_server <number> | Specify which AAA Accounting Server should handle the request from the RoamServer. |
-secret <secret> | The RADIUS shared secret. |
-proto <proto> | Protocol of request. Choices are SSLPost or RADIUS. |
-attr<name=value> | Name=Value consists of pairs of attributes to add to the packet. |
Example: -attr namel=value1 -attr name2=value2. rs_ip_address=<ip address> -attr rs_port=<port> | |
Use this to specify which RS should handle the request. record_stats=y | |
Use this to get back statistics on connection times. vendor_specific <vendorID:vendorTYPE:value> | |
Use this to test Vendor-Specific functionality, where vendorID is a positive number and vendorTYPE is a number between 0 and 255. nas_ip=<x.x.x.x> | |
Use this to test NAS-IP-Address related poilcy. framed_ip_address=<x.x.x.x> | |
Use this to test Framed_IP-Address related policy. location_id=<location id> | |
Use this to test location_id related policy. called_number=<called station id> | |
Use this to test Called-Station_Id related policy. called_number=<phone number> | |
Use this to test Called-Station_id related policy. | |
-show_radius_attrs | Shows the supported list of RADIUS attributes. |
-interactive | Run the tool in interactive mode. |
-help | Show the help/usage of the tool. |
The test output will show the status of the checkipass test = Accept or Reject. If status = Accept then the NetServer is properly installed, configured and working, and you may proceed to the next test.
Due to the simplicity of this test, a Reject test result should isolate the problem to your local server and reduce troubleshooting efforts. Possible causes for a failure here include:
Run the checkipass test once for each iPass Transaction Server, using the -host option and changing the IP address each time to reflect each Transaction Center IP.
This test will verify that iPass users are able to connect to the iPass network through your access points.
Shortly after your installation and configuration is complete, your iPass NetServer Installation Engineer will send you a customized version of the iPassConnect / OpenMobile client software for testing purposes, along with your test username and password.
To run the connectivity test:
This optional test verifies NetServer connectivity across your network. When run in RADIUS Mode, the checkipass request passes from the NetServer, through the corporate firewall, to the iPass Transaction Server, as well as to the AAA server and proxy server.
To run checkipass in RADIUS mode, in <NS_Home>/test, type: ./checkipass.csh –proto RADIUS [options] -u <userid>, where [options] are described on page 19.
After testing, the NetServer installation and configuration process is complete. Your network should now be configured to allow iPass traffic to be routed to the iPass Transaction Centers. Once your initial Dial-up testing is complete, the iPass Network Quality department will verify the quality of your network before pushing your access points to the iPass roaming users around the world. This final testing may take up to one month, after which you will enjoy the many benefits of being an iPass provider.