Remote HTTP Redirect Server Operation Flow
You can use the remote HTTP redirect feature in configurations where the redirect server resides outside of the MX Series 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 the router processes HTTP requests redirected to it and responds with a redirect URL that points to a captive portal. When you use a remote HTTP redirect server, you need to configure an HTTP service rule that rewrites the IP destination address of the incoming HTTP requests on the service router. The rewritten address ensures that the requests reach the remote HTTP redirect server before being redirected to a captive portal.
HTTP traffic is intercepted at the broadband network gateway (BNG) and the IP destination address is rewritten so that the HTTP requests are sent to the HTTP redirect server instead of the original destination. The HTTP redirect server sends a response with the HTTP 302 or 307 status code with the URL of the designated captive portal using either IPv4 destination address/destination port rewrite, or IPv6 destination address/destination port rewrite.
Figure 1 shows the general service deployment during access configuration for a remote HTTP redirect server. The HTTP redirect server resides outside of the MX Series router on a policy server, such as SRC. Service attachment occurs at subscriber login, and service detachment occurs at subscriber logout.
A complete HTTP redirect solution depends on back-end servers, such as SRC, captive portal, and RADIUS, and their integration specific to each customer’s favored integration scheme.
The subscriber logs in connecting through the access network.
RADIUS authenticates the subscriber and sends a service activate (IP destination address rewrite), which redirects HTTP traffic to the redirect policy server (such as SRC) in a walled garden.
The subscriber attempts to access the content server (HTTP traffic).
The subscriber’s HTTP traffic is first redirected to the SRC redirect policy server, which then 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’s credentials.
The captive portal authorizes the subscriber and notifies the SRC redirect policy server.
The SRC redirect policy server checks the subscriber database and formulates a policy so the subscriber can access the content server.
The SRC redirect policy server sends the policy directly to the MX Series router using JSRC or Diameter.
Alternatively, the SRC redirect policy server notifies the RADIUS server, which in turn sends a change of authorization (CoA) to the MX Series router.
The MX Series router attaches the new policy, overriding the initial redirect policy.
The subscriber now gains access to the content server.