Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring MS-MPC-Based or MX-SPC3-Based Static HTTP Redirect Services

 
Note

Starting in Junos OS Release 19.3R1, static HTTP redirect service provisioning is also supported for MX-SPC3 services card–based captive portals if you have enabled Next Gen Services on the MX Series router.

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. The captive portal page is typically the initial page a subscriber sees after logging in to a subscriber session.

When subscribers try to access sites outside the walled garden, HTTP redirect services process IPv4 and IPv6 HTTP requests to manage that traffic. The subscriber HTTP request traffic that is not destined for the walled garden is sent to the redirect server, which responds with a redirect URL that sends traffic to a captive portal instead of to the unauthorized external site. The captive portal provides authentication and authorization services for the redirected subscribers before granting them access to protected servers outside of the walled garden.

The redirect server can be local or remote:

  • Local redirect server—Resides on the router and redirects subscriber traffic to a captive portal inside a walled garden.

  • Remote redirect server—Resides on a device such as a policy server inside a walled garden behind the router. The destination address for the subscriber’s HTTP traffic is rewritten to the address of the remote redirect server. The remote server redirects subscriber traffic to a captive portal inside that walled garden.

You configure the walled garden as a firewall service filter. The service filter is attached to a static interface. The CPCD service is applied to a service interface (ms- on the MS-MPC or vsp- on the MX-SPC3 services card) by means of a service set; the service set is then attached to a static interface.

Configuring a Walled Garden as a Firewall Service Filter

When you configure the walled garden as a firewall service filter, traffic that is destined to servers within the walled garden is identified and skipped. Because this traffic does not flow to the line card, handling requirements are reduced.

All other HTTP traffic is destined for addresses outside the walled garden. Because this traffic does not match the filter conditions, it flows to the line card for handling.

You can configure the service filter so that the walled garden contains a single server as the captive portal or a list of servers.

  • Configure the walled garden with a single server as the captive portal:

    1. Create the service filter.
    2. Define a filter term to identify and skip processing for traffic to the captive portal.
      1. Specify filter conditions to match traffic that is destined for the captive portal by specifying the destination address of the captive portal and the destination port.

      2. Specify that the matching traffic skips processing on the line card.

    3. Define a filter term to identify HTTP traffic from all the traffic that did not match the previous term and send it for processing by CPCD service rules.
      1. Specify one or more HTTP port numbers to match the skipped HTTP traffic.

      2. Specify that the matching traffic is processed by a CPCD service.

    4. Define a filter term to skip further action for any remaining, non-HTTP traffic.

    For example, the following configuration creates a filter for IPv4 HTTP traffic, walled-v4, with the captive portal on 192.0.2.0. Traffic matching the address is skipped. Nonmatching traffic goes to term http, where HTTP traffic is picked out of all skipped traffic and sent to be processed according to a CPCD service. Finally, term skip causes all the remaining, non-HTTP traffic to be skipped.

  • Configure the walled garden as a list or subnet of servers.

    1. Create the service filter.
    2. Define a filter term.
      1. Specify filter conditions to match traffic that is destined for any server in the walled garden by specifying a destination prefix list of servers.

      2. Specify that the matching traffic skips processing on the line card.

    3. Define a filter term to identify HTTP traffic from all the traffic that did not match the previous term and send it for processing by CPCD service rules.
      1. Specify one or more HTTP port numbers to match the skipped HTTP traffic.

      2. Specify that the matching traffic is processed by a CPCD service.

    4. Define a filter term to skip further action for any remaining, non-HTTP traffic.
    5. (Optional) Define a prefix list that specifies servers within the walled garden. You can specify a subnet or multiple individual addresses.

    For example, the following configuration creates a filter for IPv6 HTTP traffic, walled-v6-list, with a prefix list, wg-list, that specifies two servers in the walled garden. Filter term portal6 identifies IPv6 traffic that is destined for the walled garden. Nonmatching traffic goes to term http6, where HTTP traffic is picked out of all skipped traffic and sent to be processed according to a CPCD service. Finally, term skip causes all the remaining, non-HTTP traffic to skipped.

Configuring HTTP Redirect for Local and Remote Redirect Servers

When HTTP requests are made for sites outside the walled garden, CPCD can redirect the traffic to a captive portal for authentication and authorization.

Configure a CPCD service rule that specifies the action to be taken for traffic destined outside the walled garden. This traffic was identified by the walled garden service filter and passed to the service. The action you configure depends on whether you are using a local or a remote HTTP redirect server:

  • If you are using a local HTTP redirect server on the router, you specify the redirect action.

  • If you are using a remote HTTP redirect server, which resides in a walled garden behind the router, then you cannot simply specify a redirect URL. In this case, the service rule must rewrite the IP destination address for the traffic. The new destination address is the address of the remote HTTP redirect server. The remote server then supplies a redirect URL to send the traffic to a captive portal.

The CPCD service is associated with a service interface by a service set. Both the service set and the walled garden service filter are applied to a statically configured interface.

  1. Access the CPCD service configuration level.
  2. Create a rule to apply to traffic destined outside the walled garden.
  3. Specify that the rule applies to incoming traffic.
  4. Define a rule term for CPCD to apply an action to HTTP traffic. Because the walled garden is configured as a service filter, the traffic is already filtered to be HTTP traffic before being sent to the service.
    • For a local HTTP redirect server, provide the redirect URL, which is the URL of the captive portal with the original URL (outside the walled garden) appended:

    • For a remote HTTP redirect server, provide the destination address of the remote server:

    Note

    If you want the service to apply to both redirect and rewrite traffic, you can either configure a single rule with multiple terms to manage both cases, or separate rules for each case.

For example, in the following configuration for a local server, the CPCD service rule redir-svc redirects traffic to a captive portal, http://www.portal.example.com. The original URL entered by the subscriber is appended to the redirect URL.

The following configuration for a remote server creates CPCD service rule rewr-svc that rewrites the original destination address to the address of the remote server, 192.0.2.230.

Configuring the Service Profile and the Service Set to Associate the Service Profile with a Service Interface

Service sets define one or more services to be performed by the MS-MPC/MS-MIC, or the MX-SPC3 services card if you have enabled NEXT Gen Services on the MX Series router. For HTTP redirect services, you define a CPCD service profile that includes CPCD rules. The service set applies the CPCD service profile to a specific service interface.

  1. Create the service profile.
  2. Specify one or more CPCD rules for the service profile.
  3. Create the service set.
  4. Specify the CPCD service profile.
  5. Specify the service interface.

For example, the following configuration creates CPCD service profile redir-prof, which references the CPCD rule redir-svc. Service set ss2 associates the CPCD service profile redir-prof with the service interface ms-5/0/0.

Attaching a CPCD Service Set and Service Filter to a Logical Interface

To use the HTTP redirect services, you must attach the CPCD service set to a logical interface. If the walled garden is configured as a service filter, then you must attach it to the same interface as the service set. Traffic arriving on and leaving that interface is filtered by the service filter. Traffic identified for servicing is sent to the MS-MPC, or to the MX-SPC3 services card if you have enabled Next Gen Services on the MX Series router, and the CPCD profile is applied at the service interface.

  1. Configure the logical interface.
  2. Configure the address family.
  3. Configure the interface address.
  4. Attach the service set and service filter to the interface.

For example, the following configuration attaches service set sset2 and service filter walled-v4 to ge-2/0/1.0 for the IPv4 address family. It assigns an address to the logical interface. The service set and filter are both applied to the interface input and output.

Installing a Service Package for CPCD Service

To use CPCD services on an MS-MPC/MS-MIC, or on an MX-SPC3 services card if you have enabled Next Gen Services on the MX Series router, you configure a service interface on the MS-MIC or MX-SPC3. You must install the required service package on each MS-MIC that has a service interface or on theMX-SPC3 services card.

  1. Configure Junos OS to support a service package on a service interface on an MX Series 5G Universal Routing Platform with MS-MPCs or anMX-SPC3 services card.
  2. Configure the CPCD service package to run on the PIC. When the extension-provider statement is first configured, the PIC reboots.Note

    Static MS-MPC-based or MX-SPC3 services card-based CPCD requires the CPCD service package (jservices-cpcd).

  3. (Optional) Enable PIC system logging to record or view system log messages on the PIC. You can specify one or more facilities, each at a configurable severity level.

For example, the following configuration loads the CPCD services package on the MS-MPC in chassis slot 1 and the MS-MIC in slot 0 of the MPC. System log messages are generated for any daemon and for local external applications at all severity levels.

Release History Table
Release
Description
Starting in Junos OS Release 19.3R1, static HTTP redirect service provisioning is also supported for MX-SPC3 services card–based captive portals if you have enabled Next Gen Services on the MX Series router.