Differences

This shows you the differences between two versions of the page.

Link to this comparison view

netserver_configuration_6.0.0 [2014/06/16 17:29]
ybarajas
netserver_configuration_6.0.0 [2014/06/16 17:30] (current)
ybarajas
Line 1: Line 1:
 +====== Configuration ======
  
 +
 +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:
 +
 +
 +  * **[[netserver_configuration_6.0.0&#netserver_behind_the_aaa_server|NetServer Behind the AAA Server]]**
 +  * **[[netserver_configuration_6.0.0&#netserver_in_front_of_the_aaa_server|NetServer In Front of the AAA Server]]**
 +  * **[[netserver_configuration_6.0.0&#nas_configuration|NAS Configuration]]**
 +  * **[[netserver_configuration_6.0.0&#configuration_procedure|Configuration Procedure]]**
 +  * **[[netserver_configuration_6.0.0&#configuration_testing|Configuration Testing]]**
 +  * **[[netserver_configuration_6.0.0&#connectivity_test_using_ipass_client|Connectivity Test Using iPass Client]]**
 +  * **[[netserver_configuration_6.0.0&#next_steps|Next Steps]]**
 +===== Configuration Types =====
 +
 +
 +==== NetServer Behind the AAA Server ====
 +
 +
 +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.
 +
 +
 +<note important>With NetServer behind the AAA, in the rare event of NetServer failure, normal AAA authentication procedures are not impacted. Also, if there is a problem with accounting records received by the iPass Transaction Center, the provider can submit copies from the AAA server to resolve discrepancies.</note>
 +
 +
 +This solution can only be implemented if the existing RADIUS server supports proxy.
 +
 +
 +==== NetServer In Front of the AAA Server ====
 +
 +
 +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.
 +
 +{{:netserver_configuration_types_in_front_of_aaa_server.png}}
 +
 +
 +==== NAS Configuration ====
 +
 +
 +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 [[netserver_appendix_1_6.0.0|Appendix 1]].
 +
 +
 +  * **Viewing Properties**
 +     * //To view any property value//, run: ipassconfig.csh -get <property name>
 +     * //To view all property values//, run: ipassconfig.csh -listall
 +
 +
 +  *  **Editing Properties**- You can edit the file and add, change, or delete properties in several ways:
 +     * Run **ipassconfig.csh -conf** in your <NS_Home>/bin directory. This is the recommended method.
 +     * To set a specific property value, run: **ipassconfig.csh -set <property name> <value>**
 +     * You can also use a text editor. However, we strongly recommend use of the ipassconfig.csh script, when possible, to ensure correct naming and formatting of property names and values.
 +     * To set a new property value in a text editor, open the file and type in the name and value of a new property. If a text editor is used, properties should be set by entering: **<property name>=<value>**
 +
 +
 +<note tip> You will need to reload the properties file, or restart the NetServer, in order for your edits to go into effect.
 +
 +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 [[netserver_ipassns._properties_6.0.0|Property Glossary]].</note>
 +
 +===== Configuration Procedure =====
 +
 +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. 
 +
 +===Important Note===
 +You will be running the **<NS_Home>/bin,run ipassconfig.csh -conf** script.
 +
 +
 +=== Configuration Checklist ===
 +
 +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 ===
 +
 +
 +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 File//on 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:
 +
 +  * **EAP Keystore**: Production Grade Keystore (<NETSERVER_HOME>/certs/eapserver.keystore) signed by Thwate, bundled as part of NetServer installation for EAP-TTLS authentication over WPA. This keystore is required only when EAPMode is enabled on the Netserver. It is not required to generate a new KeyStore for this type. When the tool prompts the following text, please press "K" to keep this configuration. Verify the similar console output as given below:
 +
 +<code>
 +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
 +</code>
 + 
 +
 +    * **NS Keystore**: iPass transaction system certificates (ns#.keystore).  This Keystore contains a trusted CA and certificate keypair signed by iPass used for NS to TS SSL encryption. The tool will prompt with following information required to generate the NS type keystore. Verify the similar console output as given below:
 +
 +<code>
 +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>
 +
 +</code>
 +
 +
 +**7.** To complete installation you will need to obtain a signed certificate from iPass. For more details, please visit our **[[netserver_configuration_certification_6.0.0| iPass Certificate Enrollment]]** help page.
 +
 +
 +<code>
 +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
 +
 +</code>
 + 
 +**7a.** Import the contents of the certificate to KeyStore [/usr/ipass/netserver/current_version/certs/ns1.keystore] using the following command: 
 +
 +<code>
 +/usr/ipass/netserver/current_version/bin/ipassconfig.csh -import_cert <KeyStoreProperty> "<Signed_Certificate_File_Path>"
 +</code>
 +
 +**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 :
 + 
 +  * ./list_NS_keystore.csh
 +  * ./list_NS_keystore.csh <KeyStoreFilePath>
 +  * ./list_NS_keystore.csh <KeyStoreFilePath> <Password>
 +
 +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.
 +
 +=== Adding, Editing, or Deleting Properties ===
 +
 +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.
 +
 +=== EAP-TTLS Authentication Mode ===
 +
 +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.
 +===== Configuration Testing =====
 +
 +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:
 +
 +    * checkipass.csh
 +    * a connectivity test using iPassConnect/OpenMobile
 +
 +===checkipass in SSL Mode===
 +
 +
 +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.
 +  * You will need to use a valid user name and password for the host on which the NetServer is installed.
 +  * Optimally, in order to run the checkipass test with no realm from the NetServer to the AAA, the AAA server should be configured with the NOREALM option in the routing realm. For example, RoutingRealm1=realm=NOREALM, AuthServer=ProxyAuthServer1, AcctServer=ProxyAcctServer1
 +  * ProxyAuthServer1 should be configured for AAA server.
 +  * To run checkipass in SSL mode, in <NS_Home>/test, type: ./checkipass.csh –proto SSLPost [options] -u <userid>
 +
 +
 +**//[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:
 +
 +    * Invalid user name or password. The user in this test must have local login privileges to that system.
 +    * Invalid certificate. If the certificate is corrupt, then it will need to be replaced. You can verify the certificate, dates and readability of your certificate by running the tool list_NS_keystore.csh in your <NS_Home>/bin directory. Generally, if the certificate is readable, then it is not corrupt.
 +    * Improper configuration. Verify that you have correctly entered all of the information in the setup program and that your NetServer is running on port 9101.
 +    * Invalid shared secret. Verify that your RADIUS shared secret is entered properly.
 +
 +===Test Cycle===
 +
 +
 +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.
 +
 +
 +===== Connectivity Test Using iPass Client =====
 +
 +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**:
 +
 +
 +  - Using the iPassConnect/OpenMobile client, and your test username and password, connect to each of your access points.
 +  - Repeat this test at least 10 times for each access point.
 +
 +
 +===checkipass in RADIUS Mode===
 +
 +
 +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.
 +
 +
 +===== Next Steps =====
 +
 +
 +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.
 +
 +
 +\\
 +
 +
 +Go to: **[[dokuwiki_other|Other Product Documents]] > [[netserver_help_6.0.0|NetServer Admin Guide]]** 
 +{{tag>netserver}}
 

©2015 iPass Inc. All rights reserved. Terms of Use