I'm thinking about trying something a little out of the square with user-id and captive portal. Let me start with the context and business goal:
Here is how I propose solving the problem:
So far I've proved the following can work:
I have not yet coded the user authentication and subsequent redirection back to the intended web page but will be pretty straight forward.
It seems Paloalto have not intended (thought about) captive portal being used in this way. Has anyone else attempted this?
What do you think of this idea? Can you think of a better way to achieve the same goal?
In regards to your followup question. A session should only be redirected to captive portal if there is no user/IP mapping yet, if such mapping exists CP should not get triggered. are you seeing the opposite ?
your first post should work just fine if you are able to write the redirect after authentication to the original host to facilitate the user and make the authentication trigger the API which should add a user/IP mapping near instantaneously, it should go beautifully
You also define a Captive portal rule to identify what source and destination address space you want captive portal to be applied to. Remembering that the traffic needs to traverse a firewall interface and only kicks in if there is no user-id to IP address mapping already in the firewall (as tpiens mentions). It works quite well.
You could use a PBF rule for "unknown" users. (just not mapped IP with any user) to IP where CP is configured.
Then "your captive portal" have to redirect all incomming traffic to destination 80/tcp or 443/tcp to local address.
The CP shall be in DMZ (traffic to CP shall pass over firewall) - only then PBF works.
Also CP shall be connected to the different L3 interface than LAN and External.
ex. I have:
e1/1 - Internet/External
e1/2 - LAN
e1/3 - CP
PBF have to change a routing for unknown users from default:
Rule on PAN:
IPtables redirect/DNAT on Linux:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination <IP of Captive Portal>:80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination <IP of Captive Portal>:443
Note: HTTPS redirect could generate SSL warning.
After this you could user XML-API to adding users with timeout value.
There is no idle time as in generic PAN CP, only a timeout.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!