"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: [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>
NAGGlobalOptions NAGErrorOnIPMismatch=off in the MAG Global Advanced Settings in the Admin Console.
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:
It should be:
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.