Local HTTP Redirect Server Operation Flow (MX Series, ACX7100-48L, ACX7332 and ACX7348)
You can use the local HTTP redirect feature in configurations where the redirect server resides locally on a router. This feature is available on MX series routers and ACX7100-48L, ACX7332 and ACX7348 routers.
An HTTP redirect local server that resides locally on a router processes HTTP requests redirected to it and responds with a redirect URL that points to a captive portal. You can implement the local server as a service within a service set, which provides more scalability and better performance. When you use a local HTTP redirect server, you need to configure an HTTP service rule to redirect HTTP requests to a captive portal within a walled garden.
A walled garden is a group of servers that provide subscriber access to sites within the walled garden without requiring reauthorization through a captive portal. HTTP request traffic from subscribers destined to servers outside of the walled garden is intercepted and redirected by either the captive portal content delivery (CPCD) service or the Routing Engine. The CPCD service or Routing Engine locates the provisioned redirect URL for the specific subscriber and sends a response with the HTTP 302 or 307 status code that includes the located URL.
Figure 1 shows the general service deployment during access configuration for a local HTTP redirect server. The HTTP redirect server resides locally on the router. 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; their integration is 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 (HTTP redirect), which redirects HTTP traffic to the captive portal in a walled garden.
The subscriber attempts to access the content server (HTTP traffic) outside the walled garden.
The subscriber’s HTTP traffic is redirected to the captive portal by the router.
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 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 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 router.
The router attaches the new policy, overriding the initial redirect policy.
The subscriber now gains access to the content server.