Remote HTTP Redirect Server Operation Flow
You can use the remote HTTP redirect feature in configurations where the redirect server resides outside of the router and on a policy server, such as Session and Resource Control (SRC).
An HTTP redirect remote server that resides in a walled garden behind routers processes HTTP requests redirected to it and responds with a redirect URL to a captive portal. When you use a remote HTTP redirect server, you need to configure an HTTP service rule to rewrite the IP-DA of the incoming HTTP requests on the service router so that the requests reach the remote HTTP redirect server before being redirected to a captive portal.
The following general sequence occurs during access configuration for a remote HTTP redirect server deployment:
- The subscriber logs in.
- RADIUS authenticates the subscriber and sends a service activate (IP-DA rewrite), which redirects traffic to the redirect policy server in a walled garden.
- The subscriber attempts to access the content server.
- The router first redirects the HTTP traffic to SRC, which redirects it to the captive portal.
- The captive portal sends an authorization page back to the subscriber.
- The subscriber enters credentials to obtain authorization.
- The captive portal verifies the subscriber credentials.
- The captive portal authorizes the subscriber and notifies SRC.
- SRC checks the subscriber database and formulates a policy to allow the subscriber access to the content server.
- SRC sends the policy directly to the router or notifies the RADIUS server, which in turn sends a change of authorization (COA) to the router.
- The router attaches the new policy, overriding the initial IP-DA write.
The subscriber now has access to the content server.
The following example shows a configuration for IP-DA rewrite:
[edit services captive-portal-content-delivery]
rule ipda-rewrite {
match-direction input-output;
term 1 {
from {
applications http {
destination-port 80;
}
}
then {
rewrite destination-address 100.20.1.2;
}
}
}
