Forum Discussion
Aziz-90s
Altocumulus
AltocumulusAPM portal access error 404
Created two portals one works fine as it should be but the seconed when choosing the portal access get a HTTP 404 in return. Knowing that both url good and dns good also both portal have same config. The only differences are different url and path plus IPs 😁
also created Network access as a vpn when activating that both url are fine the issue is with one url when trying to access it through portal access it displays error 404
tried to troubleshoot the issue and noticed something in Inspection tool and it seems have something with cache in the header not sure what's that
help🙏
AlexBCTCumulonimbus
Hi Aziz,
It's a bit tricky to say at the moment what it is, but here are some things that come to mind - hope there's something useful in them;
- The 404 indicates that the backend server did send a response back, so looks like routing is all good.
- If it is indeed the server that is sending the 404 back, can you have a look in the server logs to see when they are triggered? The server logs is your best bet for finding the answer for why it got triggered.
- Alternatively, have you checked the exact syntax used in the portal access object against the actual resource?
- Can you run a "curl" command from the F5 CLI and confirm that you can still reach the same URL that way? (seen that it is working when you are using the Network Access, it should be fine, but would be good to check)
If still no luck, any chance that you could post the URL's and IP structures that you are using for these Portal Access objects, as well as the exact messages you found in the Inspection Tool with regards to caching? (with anything sensitive replaced with x-es 😉
Hope this helps.
Aziz-90sHi
I believe found the issue, here is what's going on:
the web server has a redirection by its url so when we click the portal access the f5 do the hashing and redirect it as a loop
vpn.example.com/f5-w/hash/f5-h$$/f5-w/hash and so on
that is why i get the error 404
what does f5-h$$ means
is there a solution from f5 side like irule or rewrite portal access
- AlexBCT
The f5-w-XXXXXXXX is what they call the "F5 mangle", and it is encoded (not encrypted!) the URL that the user will be sent to inside the environment. With this feature, any links on the internal application can be rewritten with links that redirect the user to the vpn.XXXX domain, ensuring all links will always work. (the main reason why Portal Access should be used)
This URL rewrite process sometimes goes "wrong", causing unexpected behaviour, such as forcing return traffic to go through the F5 even if it's not needed, and other things.
This F5 mangle should however not be seen by the internal web servers though, as APM removes it from the request before forwarding on the request to the backend webserver. As such, if you DO see that section coming back in the URL multiple times, I suspect you actually have a redirect function in the F5, rather than in the backend server, or the traffic from the client is bypassing APM altogether and going straight to the backend server.
Before talking about solutions, I would recommend you check exactly where the traffic goes, what virtual server picks it up (both the initial request as well as any follow-up requests), what exact URL requests are being received by the backend webserver, and how the return traffic makes its way back to the client.
This will not only help you understand the problem better, but also help resolve the issue in the best possible way. (as you may find you don't need Portal Access at all... 😉