IP mismatch. 403err due to having NAGGlobalOptions NAGErrorOnIPMismatch=on

  • Document ID:7011941
  • Creation Date:13-Mar-2013
  • Modified Date:03-Sep-2013
    • Micro Focus Products:
      Access Manager (NAM)
      Change Guardian
      NetIQ End of Life

Environment

NetIQ Access Manager 3.2
NAGErrorOnIPMismatch Setting

Situation

After migrating from 3.1 Linux Access Gateway (LAG) to 3.2 Apache based Access Gateway Appliance (MAG) get caught in a looping situation when trying to authenticate. On some browsers, the following error is displayed:

 "Access forbidden" "NULL".

In the error_log see the following error: IP mismatch. 403err

Example snippet from error_log:

Mar 5 22:24:40 ag01 httpd[5989]: [warn] AM#304600404 AMDEVICEID#ag-4E66CA3433EF6D2C: AMAUTHID#114550C3E84827830B55BE7D4C01F50E: AMEVENTID#10236: IP mismatch. 403err clientIP:8xxx.xxx.133.255 (inCk:xxx.xxx.140.135) (localIP:xx0110ac)<0100860050f68c872327ce15dfa7a07d01573edf>

Resolution

The bug in the csv file has been reported to engineering and will be fixed in a future release, in the meantime if using  the
/etc/lagDisableAuthIPCheck touch file on the LAG, be sure to set

NAGGlobalOptions NAGErrorOnIPMismatch=off in the MAG Global Advanced Settings in the Admin Console.

 

Cause

One of the pre-requisites for migrating from 3.1x LAG to 3,2 MAG is to copy the lag2mag_touchfiles.csv and migrate_touchfiles.sh to the LAG and then to run it. It will then populate what advanced options should be set in the MAG advanced options to get compatible experience to the LAG. This process is discussed in Section 2.2.3 of the Upgrade and Migration Guide

 

So currently as of v3.2sp1_IR1, there is an issue with the "mapping" in the lag2mag_touchfiles.csv between the following touch file and MAG advanced setting:

 

 

 /etc/lagDisableAuthIPCheck,Global Option,NAGErrorOnIPMismatch=on

 

It should be:

 

 /etc/lagDisableAuthIPCheck,Global Option,NAGErrorOnIPMismatch=off
 
If you were to paste the recommendations the script provides to the advanced settings window in the MAG this can cause this problem.

Additional Information

Here is the information from the Access Gateway Guide in regard to this setting:
 
NAGGlobalOptions NAGErrorOnIPMismatch=off

This is a global advanced option.

If this option is enabled, the Access Gateway does not perform the IP address check on incoming session cookies. Use this in a setup where two L4 switches are configured in parallel and the browser requests are bounced between these L4 switches.

This option is equivalent to .lagdisableAuthIPCheck in the 3.1 SP4 Access Gateway Appliance.

For example, if multiple back-end Web servers are accelerated by the Access Gateway, some users complain that they are not able to complete logging in. When they access the protected resources, they are redirected to the Identity Server for authentication, but they are not redirected to the original URL.

If multiple paths (at the network level) exist between a browser and the Access Gateway and proxies or NAT devices exist on these paths, it is possible that the source IP address of the incoming requests into the Access Gateway might change. For example, assume that user A connects to an ISP. This ISP has multiple transparent proxies in parallel for performance reasons.

User A accesses the Access Gateway for the first time. The request from User A goes through a local transparent proxy TP1, so the incoming IP address of the initial request has that transparent proxy's (TP1) IP address. The Access Gateway session cookie is set and the user is redirected back to the page the user was going to originally.

User A then sends the next request for this original page, but it goes through a different proxy, TP2. The incoming IP address of the request into the Access Gateway is now different than the one that the user used for authentication (TP1 IP address) and the validation fails. The Access Gateway loops as it continues to request the user to send a valid session cookie.

NOTE:On receiving IPC cookie from browser, the Access Gateway checks for the client IP address in the cookie. If the IP address in the cookie and the client IP address from which the request came do not match, Access Gateway displays an error page.