WEB-MON

Introduction Copied

Geneos WEB-MON Plug-In checks a WEB Server’s ability to supply pages/files by requesting a series of pre-set pages/files on a regular basis.

Page/file availability, response time, data size and any HTTP headers are displayed and rules can be set to alert when a page/file becomes unavailable or when the response times are unacceptable.

This is particularly useful when WEB Servers are managed by an Application Service Provider (ASP) or Internet Service Provider (ISP), where this could be the only facility to ensure the quality of the service. Additionally, you can use this plugin to:

• Check if a website is up and validate its content.

• Get QoS information for logging or SLA purposes.

• Check website security.

• Validate responses from different users.

• Pass content to the extractor plugin for further content processing.

All HTTP Web Server types are supported. Where servers publish their type, this information is displayed for reference.

Each WEB-MON instance monitors a single web server. Multiple instances may be configured if more than one server is to be monitored.

Note

The cURL library used by WEB-MON plug-in cannot utilise JavaScript. Refer to ITRS Synthetic Monitoring User Guide for more information.

Intended Audience Copied

This user guide is intended for experienced Geneos users who want to monitor web pages. As a user, you should be familiar with the HTTP protocol, cURL library, proxy connection, and protocols like NTLM and Kerberos if authentication will be used.

Scenarios and Stages Copied

The configuration of the WEB-MON plug-in is broken down into a number of scenarios. Each scenario allows a series of stages (web pages or files) to be requested in sequence, in the same way that a user would do. Scenarios themselves are run in parallel.

Stages have a set of success criteria associated with them, such as a response code or time to complete. If the criteria are not met then the stage and the overall scenario will fail.

If the website is simple then a number of scenarios may exist, each of which may be composed of a single stage. These could then check that a number of key pages are available.

If the website is more complex then more stages may be needed in the scenarios. An example scenario might be to log in with a username and password, and then request a page that is unavailable without a login. Another scenario may be to deliberately enter an incorrect username and password, and verify that the request for the protected page fails.

The Examples section of this document describes possible uses in more detail.

Views Copied

The WEB-MON plugin produces one view which can be displayed in Summary or Summary and Details mode.

WEB-MON plugin in Summary mode:

WEB-MON plugin in Summary and Details mode:

The samplingStatus will show OK if the sampling takes longer than the initial sample period to complete a scenario, or FAILED if the setup is incorrect.

Headline Legend

The headlines are shown above the main table and provide an overview of the state of the server.

The ipAddress, serverType and serverState columns are populated as a result of making a request for the default server webpage (/).

Table Legend

The columns in the table are broken up into two parts:

The first set of columns show status information about the stages and scenarios;

The second set of columns show more details about the requests and responses. For scenarios, the second set of columns will show the details of the last stage to run. For successful scenarios, this will be the last stage. For unsuccessful scenarios this will be the stage that failed.

Plug-In Configuration Copied

Each WEB-MON instance monitors a single web server. Multiple instances may be configured if more than one server is to be monitored.

Scenarios are configured with a number of stages in each. Stages can have additional data sent as part of the request, such as query variables and headers. They also specify a set of success criteria that, if breached, will cause a FAILED state to occur. In addition to the configurable success criteria, if the server sends a Content-Length header and the amount of data downloaded does not match this then the stage will fail.

It is possible to configure connection details at the scenario or stage level in addition to the top level. This allows connections to other servers if, for example, authentication is required from a central location. It also allows monitoring of multiple domains that are served from the same physical web server, or checking both secure and non secure versions of a site.

Although setting different connection details would also allow multiple physical servers to be monitored from the same WEB-MON instance, this is not recommended, and the headline variables will only show the status of the main server being monitored.

The configuration parameters are listed below:

host Copied

The full name of the server to monitor.

This should be entered as it is entered in a web browser, and might not be the same as the physical hostname of the server if virtual hosting is being used. For example, a server serv1 might be hosting <www.example.com> and <www.example.net>. The host should be set to <www.example.com> or <www.example.net> rather than serv1.

Mandatory: Yes

port Copied

The port of the server to monitor.

Mandatory: No

Default: 80 (http) or 443 (https)

serverURL Copied

If specified, the ipAddress, serverType and serverState headline fields are populated as a result of making a request for this URL (relative to host). Otherwise, the mentioned fields are populated as a result of making a request for “/” (which is typically the default server webpage).

For example: if host is set to <www.example.com> and serverUrl is set to sample1, the request would be made for <www.example.com/sample1>. If this field is not set, request would be sent for for <www.example.com> instead.

Mandatory: No

Default: 80 (http) or 443 (https)

protocol Copied

Whether to use http (unencrypted) or https (SSL encrypted). When using SSL connections, the server certificate can also be verified.

Mandatory: No

Default: http

protocol > https > certificate Copied

Certificate to use for the SSL authentication.

Mandatory: No

Default: No

protocol > https > certificate > verify Copied

What to check within the certificate.

When checking the certificate against a Certificate Authority then a CA Bundle in PEM format must be used. This file specifies the CAs that are to be trusted. If the operating system has not come with a CA or it is out of date then a CA Bundle should be specified.

This can either be constructed (if, for example, you wish to add your own trusted authorities when self-signing) or downloaded. If you wish to generate your own then please search online for ‘Creating a PEM CA bundle’. If you just wish to download an existing one then you can do so from the cURL page describing how to extract CA certificates from Mozilla: http://curl.haxx.se/docs/caextract.html

Mandatory: No

Default: none

protocol > https > tlsVersions > minTLSVersion Copied

Minimum TLS Protocol version to be used.

Mandatory: No

Default: none

protocol > https > tlsVersions > maxTLSVersion Copied

Maximum TLS Protocol version to be used.

Mandatory: No

Default: none

proxy Copied

Settings for making connections via proxy servers.

Note

If a proxy is specified at the top level then this changes the behaviour of some headline variables.

Mandatory: No

Default: none

proxy > none Copied

Explicitly disable proxy.

proxy > proxyServer > host Copied

Hostname of proxy server.

Mandatory: Yes

proxy > proxyServer > port Copied

Port number of proxy server.

Mandatory: Yes

proxy > proxyServer > type Copied

The type of proxy to use. Six types are currently supported.

Mandatory: Yes

proxy > proxyServer > authentication Copied

Authentication settings for proxy.

Mandatory: No

Default: None

proxy > proxyServer > authentication > password Copied

Allows username/password combinations to be sent to proxy servers.

proxy > proxyServer > authentication > password > loginCredentials Copied

Contains details of the username and optional password. The password may be encoded in the setup file so that it is not easily visible if required. Kerberos authentication (GSS-Negotiate) does not require this setting as it relies on Kerberos tickets to authenticate with the web server. See Authenticating with Kerberos for more details.

proxy > proxyServer > authentication > password > method Copied

Allows various HTTP authentication methods to be selected. These are all enabled by default but only one method should be selected by the user. Disabling other methods may speed up the request and prevent usage of incorrect methods (depending on which methods are employed) so disabling other methods is highly recommended.

For example, if the user wants to use NTLM authentication, and the host is known to have both NTLM and Kerberos (GSS-Negotiate) authentication, it is highly recommended to enable NTLM authentication, and disable both Basic and Kerberos authentication.

Kerberos authentication requires additional configuration prior to use. See Authenticating with Kerberos for more details.

Mandatory: No

Default: All methods are enabled

authentication Copied

Allows authentication information to be sent along with requests using various methods. When usernames and passwords are entered into webpage forms then query vars should be used instead. See the Checking Secured Pages example for more details.

Mandatory: No

authentication > httpAuthentication Copied

Allows HTTP level authentication to be set

authentication > httpAuthentication > password Copied

Allows username/password combinations to be sent to servers. When using a web browser, this authentication method is typically seen by a pop-up dialog box.

authentication > httpAuthentication > password > loginCredentials Copied

Contains details of the username and optional password. To set an encrypted password, click on the “Set Password” button, then enter and confirm the password to be used. Kerberos authentication (GSS-Negotiate) does not require this setting as it relies on Kerberos tickets to authenticate with the web server. See Authenticating with Kerberos for more details.

authentication > httpAuthentication > password > method Copied

Allows various HTTP authentication methods to be selected. These are all enabled by default but only one method should be selected by the user. Disabling other methods may speed up the request and prevent usage of incorrect methods (depending on which methods are employed) so disabling other methods is highly recommended.

For example, if the user wants to use NTLM authentication, and the host is known to have both NTLM and Kerberos (GSS-Negotiate) authentication, it is highly recommended to enable NTLM authentication, and disable both Basic and Kerberos authentication.

Kerberos authentication requires additional configuration prior to use. See Authenticating with Kerberos for more details.

Mandatory: No

Default: All methods are enabled

display Copied

Contains a number of settings to control how the information is displayed.

display > displayMode Copied

The display mode will be one of:

Mandatory: No

Default: SUMMARY

display > displayURL Copied

You can display URLs in one of the following ways:

You may not wish the query part of the URL to be shown in the view if it contains sensitive information, however if you use the ’encoded’ query variables option then it will be shown as name=[encoded] so that it is not visible in Geneos. Even with all these measures in place, this will not prevent the information showing up in any server logs.

Mandatory: No

Default: PATH

display > displayHeaders Copied

If you wish to see additional HTTP headers then they can be specified here. Each one will appear as a new column in the view. This is particularly useful if your web application writes out custom headers.

A full list of standard headers can be found in RFC2616 References. Examples of potentially useful headers are: Content-Length, Last-Modified, X-Powered-By.

Mandatory: No

Default: No additional headers

maxInitialSample Copied

When each sample starts it will check the status of the downloads every 0.1 seconds for an initial period. If it hasn’t finished after that time then it will leave the downloads in the background and relinquish control to other samplers. It will then check the status again while other samplers aren’t sampling, until all the scenarios are complete. The minimum time between these additional checks is 1 second.

Mandatory: No

Units: Seconds

Default: 5

maxServerDuration Copied

This setting allows the maximum amount of time to wait for the main server status - the settings which allow the headline variables to be populated.

Mandatory: No

Units: Seconds

Default: 60

GSS-Negotiate Copied

Note

Kerberos authentication for the Web-Mon plugin is only supported on Linux platforms.

Beginning Geneos 5.6.x, you can set a Kerberos principal and keytab on Web-Mon samplers running on Linux x64 platforms. This facilitates automatic Kerberos ticket renewal.

Once the principal and keytab are defined, the sampler will generate the Kerberos ticket inside the current working directory.

scenarios Copied

Contains the list of scenarios. If no scenarios are configured then only the default server webpage (/), or the serverUrl(if provided), will be monitored and the results shown in the headline variables.

scenarios > scenario Copied

A scenario is a named object that consists of a number of requests to the same web server (scenarios > scenario > stages). Cookies are maintained within a scenario but not between scenarios.

scenarios > scenario > name Copied

Specifies the name of a scenario. Each scenario should have a unique name within this sampler. The scenario mode will be displayed as the row name in the dataview, and will also form the first part of the row names when SUMMARY+DETAILS is selected as the display > displayMode.

scenarios > scenario > connection Copied

This allows the connection details to be overridden. See the following sections for more details:

• host
• port
• protocol
• authentication
• proxy

scenarios > scenario > successCriteria Copied

Allows success criteria to be specified for the whole scenario. Each stage also has its own, more extensive, success criteria.

scenarios > scenario > successCriteria > maxDuration Copied

This specifies the maximum amount of time the scenario is allowed to run for. If this time is exceeded then the scenario will be marked as TIMEDOUT, the current stage will be CANCELLED and any remaining stages will be SKIPPED.

Mandatory: No

Units: Seconds

Default: 60

scenarios > scenario > stages Copied

Contains the list of stages. A stage is a single request to a web server. Requests in a scenario are made in the order they are declared in the setup.

scenarios > scenario > stages > stage Copied

A stage is a named step inside a scenario. A stage is a single request to a web server.

scenarios > scenario > stages > stage name Copied

Specifies the name of the stage. This should be unique within the scenario. It will be seen in the scenario line if this particular stage fails. It will also form the second part of the row names when SUMMARY+DETAILS is selected as the display > displayMode.

scenarios > scenario > stages > stage > connection Copied

This allows the connection details to be overridden. See the following sections for more details:

• host
• port
• protocol
• authentication
• proxy

scenarios > scenario > stages > stage > url Copied

Specifies the URL (relative to the server root) of the page to request. Example:

/path/to/file.html

It is possible to specify the query string as part of the URL, but it must be properly encoded. This may be used in addition or as an alternative to the queryVars table. The queryVars table is preferred as any name/value pairs in this table will be encoded by the plugin, and hiding of sensitive information is also supported. Example:

/path/to/file.html?name=value&name=value

Mandatory: Yes

scenarios > scenario > stages > stage > requestData Copied

This configuration allows the request to be altered

scenarios > scenario > stages > stage > requestData > method Copied

Sets the request method to GET or POST.

GET is the normal option for standard page requests, and POST is the normal option when submitting information to forms, particularly if a lot of data is to be sent, or if sensitive information needs to be transferred so that it won’t show up in server logs and proxies as part of the request URL.

Although it is possible that either method can be used in either case, sometimes when forms are involved the server will insist on one method or another so it is worth checking the page source to see which is used. See the Checking Secured Pages example for more details.

Mandatory: No

Default: GET

scenarios > scenario > stages > stage > requestData > method > get > queryVars Copied

The query variables are appended to the URL as name/value pairs. They will be URL encoded automatically so there is no need to encode them before entering them.

It is also possible to perform Geneos-level encoding of the values for when sensitive information such as passwords is used. This information will not show up in the setup file, and if the PATH+QUERY or FULL+QUERY displayURL option is selected then this data will show up as [encoded] in the dataview. For example:

/login.php?username=myname&password=[encoded]

Mandatory: No

Default: No additional variables

scenarios > scenario > stages > stage > requestData > method > post > body > queryVars Copied

The query variables to be sent as the body of the POST request. Each name value pair is url encoded and then passed to the server with the Content-Type: x-www-form-urlencoded unless overridden in the requestHeaders configuration.

For example:

• Geneos: Netprobe
• Gateway: Webmon

would be encoded as:

geneos=netprobe&gateway=webmon

Mandatory: No

Default: Empty Post Request

scenarios > scenario > stages > stage > requestData > method > post > body > rawData Copied

The body of the post request to be sent to the server, as a string. This allows Webmon to post any type of string data to the server, for example SOAP requests.

Note

You should also add the Content-Type to the requestHeaders configuration to indicate to the server the mime-type of the raw data that Webmon will send. For example a SOAP request would have a Content-Type of application/soap+xml. If this header is not specified the type will default to x-www-form-urlencoded.

Mandatory: No

Default: Empty Post Request

scenarios > scenario > stages > stage > requestData > queryVars Copied

Deprecated: use queryVars under the GET or POST elements

The query variables are appended to the URL as name/value pairs. They will be URL encoded automatically so there is no need to encode them before entering them.

It is also possible to perform Geneos-level encoding of the values for when sensitive information such as passwords is used. This information will not show up in the setup file, and if the PATH+QUERY or FULL+QUERY displayURL option is selected then this data will show up as [encoded] in the dataview. For example:

/login.php?username=myname&password=[encoded]

Mandatory: No

Default: No additional variables

scenarios > scenario > stages > stage > requestData > requestHeaders Copied

The request headers allow additional headers to be sent to the server as part of the request. An example of use might be to change the User-Agent header for applications that serve different pages depending on the web browser being used.

A full list of standard headers can be found in RFC2616 [1].

An example of use may be seen in the Changing Request Headers example.

Mandatory: No

Default: No additional headers

scenarios > scenario > stages > stage > successCriteria Copied

This configuration section allows the response to be checked against a set of criteria. This will determine whether the scenario and stage show as OK or FAILED in the dataview.

scenarios > scenario > stages > stage > successCriteria > responseCodes Copied

The response codes specify the acceptable responses given by the server. These are all three digit codes. The first digit specifies the type of response, and the other two digits provide more detail. 4xx codes are problems with the request, such as specifying a URL for a file that doesn’t exist. 5xx codes are server errors, when a problem occurred trying to fulfil the request.

A full list of the response codes and their meanings can be found in RFC2616 References.

Mandatory: No

Default: All codes in the 100 to 399 range

scenarios > scenario > stages > stage > successCriteria > maxDuration Copied

This specifies the maximum amount of time the stage is allowed to run for. If this time is exceeded then the stage will be TIMEDOUT and any remaining stages in the scenario will be SKIPPED. The scenario will then show FAILED.

Mandatory: No

Units: Seconds

Default: Unlimited

scenarios > scenario > stages > stage > successCriteria > response Copied

Can check the response from the server for various different conditions

scenarios > scenario > stages > stage > successCriteria > response > expression Copied

The expression defines, using Boolean and/or/not logic, which of the conditions need to be met in order for the server response to be valid. For example, you may define a page content condition called ‘failed’ which matches against the text ’login failed please try again’ and then the expression would be:

not “failed”

Right clicking on the expression editor will bring up a menu that gives access to the available operators, and also provides some common templates for expressions that may be used.

scenarios > scenario > stages > stage > > successCriteria > response > conditions Copied

Allows the various different conditions to be specified. These can then be used in the expression above to define the criteria under which the response matches.

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent Copied

The page content checks look at the actual page - the text that would be seen in a browser’s ‘Show Page Content’ or ‘View Page Source’ options.

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > string Copied

Checks the page content against an exact piece of text.

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > string > text Copied

The actual text to match against

Mandatory: Yes

scenarios > scenario > stages > stage successCriteria > response > conditions > condition > type > pageContent > match > string > caseSensitive Copied

Whether to perform a case sensitive comparison. Case sensitive comparisons will be slightly quicker, so if the case of the text you are looking for is not going to change then this is the best option.

Mandatory: No

Default: true

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex Copied

Checks the page content against a regular expression.

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex > data > regex Copied

The perl-compatible regular expression to use. Example:

a.\*b

Mandatory: Yes

scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex > data > flags Copied

This a set of zero or more regex flags which can affect how the regex is applied to the contents of the web page. For example if ‘i’ is specified then the web page contents is considered in a case-insensitive manner when the regex is being applied to it.

Any of the following flags may be specified:

Mandatory: No

Default: All flags are false

scenarios > scenario > stages > stage > dataTransfer Copied

If a page downloads correctly and passes all the success criteria then the content may be exported for other samplers to read, such as EXTRACTOR. The purpose of the web-mon plugin itself is to allow the server/app to be checked to ensure that it is returning pages. In contrast, the data transfer may be used, for example, to display the page content in a separate dataview so that the figures displayed can be monitored by Geneos.

The name selected does not have to match anything else in the web-mon plugin, however:

• The name must match the name used in the sampler reading the data.
• It must be unique on any particular Netprobe - if multiple instances of the same web-mon sampler are used on the same Netprobe (through use of different Managed Entities or Types) then variables must be used to make it unique.

If web-mon is only present to provide other samplers with information and you do not wish to see the status of the pages being retrieved, then once it has been set up you can prevent it being shown by setting the ‘Publish’ option to false in the Visibility tab of the Sampler configuration section.

Mandatory: No

Default: The page content is not exported.

Additional Configuration Information Copied

This section provides additional configuration information needed to use certain features of this plug-in.

Authenticating with Kerberos Copied

Note

Kerberos authentication for the Web-Mon plugin is only supported on Linux platforms.

Before setting the plugin to use Kerberos authentication to connect to a web server, the client machine must first acquire a Kerberos ticket-granting ticket from that web server. The following guidelines describe how to acquire the Kerberos ticket:

Verify the Kerberos realm Copied

Verify that the Kerberos realm of the web server is defined in the Kerberos configuration of the client. The configuration file is located in /etc/krb5.conf. Below is an example of the realms section of the configuration file:

Example realms definition in krb5.conf

[realms]
EXAMPLE.COM = {
   kdc = kerberos.example.com:88
   admin_server = kerberos.example.com:749
   default_domain = example.com
 }

Check that the realm of the web server is defined with the corresponding names of the kdc, admin_server, and default_domain.

After verifying the Kerberos realm, you can follow any of the options below to set up the Kerberos ticket generation:

• Generate the Kerberos ticket-granting ticket for an authorized user
• Set up the Kerberos principal and keytab on the sampler

Generate the Kerberos ticket-granting ticket for an authorized user Copied

1. Generate the Kerberos ticket-granting ticket for an authorized user and store it in the default location. This can be done by running kinit <user@realm> on the command line. Enter the password when prompted:

   # kinit user@example.com
   

2. Run klist on the command line to view the generated ticket. Verify that ticket is stored in the default location, /tmp/krb5cc_0:

   # klist
   

When using this method, consider the following limitations:

• The ticket has a finite lifetime and the client machine will need to regenerate it once it expires. The lifetime of a ticket is controlled by the Kerberos Key Distribution Center (KDC) of the web server, which issues the tickets. The default expiration is typically set to 8 or 10 hours, but can be configured to a longer duration in the KDC. Ticket renewal polices can also be set between the web server and client. Consult your web server administrator on how to configure ticket lifetime and renewal.
• The plugin requires that the client machine generate the Kerberos ticket-granting ticket from the corresponding web server and store it using the default file setting. The plugin does not generate the ticket on its own and only looks for it in the default location when performing the authentication.

Set up the Kerberos principal and keytab on the sampler Copied

Beginning Geneos 5.6.x, you can set a Kerberos principal and keytab on Web-Mon samplers running on Linux x64 platforms. This facilitates automatic Kerberos ticket renewal.

If you have a Kerberos principal, you can set it up on the sampler for Kerberos authentication. The Kerberos options can be found in the Advanced tab > GSS-Negotiate. For more information, see GSS-Negotiate.

Examples Copied

This section provides more detailed examples possible uses of this plug-in.

Simple Server Status Monitoring Copied

If the requirement is just to check that a particular server is up, then no scenarios need to be configured. The plug-in will make requests for the default server page ( / ), or the serverUrl (if provided), and use this to decide on the server status.

Checking Simple Pages Copied

If there are pages that need to be available on the server, these may be configured as single stage scenarios. One scenario would be written for each page, as the requests do not have to happen in any particular order. The plug-in would try and access all these pages simultaneously to minimise the time taken to perform a sample. Since each scenario only has one stage, the display should probably be set to SUMMARY.

Checking Secured Pages Copied

If a login is required to view pages, scenarios may be configured with the login page as the first stage, and the page to check as the second stage. Query variables can then be used to pass the username and password to the login page.

To find out the query variables that need to be used, it is necessary to look at the source of the login page. This would look something like this:

...
<form action="/site/login.php">
...
<input type="text" name="username">
...
<input type="password" name="passwd">
...
</form>
...

In this case, the URL should be set to /site/login.php, and the query variables needed are username and passwd.

Depending on how the login was written, it may require other name/value pairs to be set. It may require hidden variables, like this:

<input type="hidden" name="action" value="login">

or the submit button, like this:

<input type="submit" name="submit" value="Log Me In">

It is also worth checking the request method, which will also be part of the form definition:

<form action="/site/login.php" method="POST">

The method (either GET or POST) can be set as part of the request data for the stage.

Checking Security of Pages Copied

It is also possible to ensure that it is not possible to access pages that have been secured behind a login. In this case, a single stage is needed that accesses the secured page. The acceptable responseCode should then be set to 403 (Forbidden). The scenario will then be successful if it is not possible to view the page.

Another similar test would be to visit the login page first, but deliberately enter in an invalid username/password.

Changing Request Headers Copied

It is possible to change the headers that get sent as part of the request. One possible use would be to change the User-Agent if the same URL is used to serve pages for different browsers, or for a browser and a PDA.

In this case scenarios could be set up with a User-Agent requestHeader of:

Mozilla/4.0 (compatible; MSIE 6.0; Win32)

and another with

Nokia6630/1.0 (2.39.129) Series60/2.6 Profile/MIDP-2.0 Configuration/CLDC-1.1

That would allow the responses to be compared for Internet Explorer 6 and a Nokia 6630 mobile phone. User-Agent strings for common browsers and wireless devices can be found on the Internet.

References Copied

RFC2616 - Hypertext Transfer Protocol - HTTP/1.1

RFCs are “Request For Comments” documents and each system used on the Internet has one that describes exactly how to use it. The documents are all numbered and are hosted many places on the Internet. RFC2616 can be found by performing a search for “RFC2616” in any search engine.

Known Issues Copied

IPv6 with NTLM

In a few cases timeout issues have been seen when using NTLM authentication with some types of IPv6 environments.

If you experience any issues, contact ITRS Support .