Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring Routing Engine-Based, Static HTTP Redirect Services

 
Note

Starting in Junos OS Release 19.3R2, the HTTP redirect service is also supported if you have enabled Next Gen Services on the MX Series.

You can configure HTTP redirect services on the Routing Engine as an alternative to using an MS-MPC/MS-MIC or MX-SPC3 services card. You configure the walled garden as a firewall service filter. 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 walled garden service filter identifies traffic destined for the walled garden and traffic destined outside the walled garden. Only HTTP traffic destined outside the walled garden is sent to the Routing Engine for processing by the HTTP redirect service. The CPCD service is associated with a service interface on the Routing Engine by means of a service set.

The service interfaces on the Routing Engine are identified with an si- prefix (for example, si-1/1/0). The si- interface processes all redirect and rewrite traffic and services for the Routing Engine. The si- interface must be operational with a status of up to enable and activate the captive portal content delivery (CPCD) service. After the CPCD service is enabled, any change in the operational state of the si- interface does not affect existing CPCD services.

The CPCD service sends the subscriber HTTP request traffic that is not destined for the walled garden to a redirect server, which responds with a redirect URL. The redirect URL 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.

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. 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 Routing Engine 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. Processing is skipped for traffic matching the address; the traffic is sent to the captive portal. 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 skip6 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, or identified and accepted by the walled garden service rule. 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:

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 Routing Engine. 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 that the service set is for Routing Engine–Based CPCD.
  5. Specify the CPCD service profile.
  6. 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 is specified as being for Routing-Engine-based CPCD. The set associates the CPCD service profile redir-prof with the service interface si-4/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 Routing Engine service interface where the CPCD profile is applied.

  1. Enable inline services and specify a bandwidth.
  2. Configure the logical inline services interface.
  3. Configure the address family.
  4. Attach the service set and service filter to the interface.
    • Static interface:

    • Dynamic interface

For example, the following configuration enables inline services on the line card in chassis slot 4 and on the MIC in slot 0 of the line card. It assigns an address to the logical interface. Then it attaches service set sset2 and service filter walled-v4 to ge-2/0/1.0 for the IPv4 address family. The service set and filter are both applied to the interface input and output.

Inserting GET Header Tags That the HTTP Server Can Use to Control Content Access

In some cases you might want your HTTP server to determine whether to allow users to access content. Starting in Junos OS Release 19.1, you can configure Routing Engine-based, static HTTP redirect service filters to specify tags that the Routing Engine inserts in to the packet header of HTTP GET messages for this purpose. You can insert tags for the router hostname or the subscriber’s MAC address, IPv4 address, or IPv6 address.

The following steps correspond to Figure 1.

  1. The user’s device, the HTTP client, performs a TCP handshake sequence with the HTTP server.

  2. When the handshake is successful, the client sends an HTTP GET with the URL requested by the user.

  3. The Routing Engine modifies that URL by concatenating a string of random characters enclosed by /$ and $/. The string length matches the combined length of the tags that will be inserted later. The string serves as an identifier when returned by the client.

    Suppose the length of the tags to be inserted is 30 characters, and the requested URL is http://192.51.100.20/test.html. The Routing Engine returns the URL modified with a string of 30 random characters as in the following example:

    http://192.51.100.20/test.html/$IIGSbVdNDTDvnJFIAyoysXwVJawoYj$/

  4. The Routing Engine sends the modified URL with a status code of 302 (Found) or 307 (Temporary Redirect). The code sent depends on the version of HTTP being used and the version of Junos OS on the BNG. Both codes indicate to the client that the access request needs to be resent with the modified URL.

  5. The Routing Engine resets the TCP connection with the client and the server.

  6. The client performs a TCP handshake with the HTTP server for a modified URL.

  7. The client sends an HTTP GET with the modified URL.

  8. The Routing Engine checks whether the length of the concatenated string is the same as it sent to the client.

    • If the length is correct, it strips the URL back to the original requested URL, inserts the tags into the GET header, and forwards the GET to the HTTP server. If configured, the GET can be optionally forwarded to a redirect URL instead of the original requested server.

    • If the length is not correct, the Routing Engine drops the packet and increments the drop counter.

  9. The HTTP server evaluates the GET message and sends a response to the client with a status code of 200 (OK) if it grants access or 403 (Forbidden) if the request is rejected.

  10. The Routing Engine terminates the TCP connection with the client and the server.

Figure 1: Tag Insertion for HTTP Redirect Message Flow.
Tag
Insertion for HTTP Redirect Message Flow.
Note

Tags are inserted into the header in the same order as they are configured. The tag name is case-sensitive so that tag ABCD and tag abcd are processed as different names.

To configure tags to be inserted in GET headers:

  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. (Optional) Specify one or more destination addresses to filter traffic for tagging.
    Note

    Alternatively, you can specify destination addresses for identifying traffic in the firewall service filter.

  5. 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 example, the following configuration creates a service rule, insert-rule, that matches traffic on the input interface. Term t1 inserts two tags, x-mac-addr with the subscriber’s MAC address and x-sub-ip with the value of the subscriber’s IPv4 address.

In the following sample rule, only traffic with a destination address that matches 198.51.100.50 or 198.51.100.75 is tagged. Tags are inserted for the subscriber’s IP address and the hostname of the router. A second term in the rule provides a redirect URL where the traffic is forwarded instead of being sent to the original requested URL.

As with any CPCD service rules for Routing-Engine-Based HTTP redirect, you must include the rules in a CPCD service profile, then use a CPCD service set to associate the profile with an inline service interface. The Routing Engine uses the rules to process HTTP traffic passed by a service filter on the same logical interface as the service set.

Consider the following sample configuration. The tag-redirect rule is defined to match traffic on the input interface and then insert two tags in the GET header, the value of the subscriber’s IP address and the hostname of the router. The rule then provides a redirect URL for the tagged traffic. The CPCD service profile http-insert-redirect is defined to include this rule.

The service set sset1 is defined as being for Routing Engine-based CPCD. It applies the CPCD service profile to an inline service interface.

The service filter walled-tag identifies and acts on three kinds of traffic: HTTP traffic to send to the walled garden at 192.0.2.100, HTTP traffic destined for 198.51.100.50 to go to service processing, and all other traffic to be skipped. This is an example of matching a destination address in the service filter instead of in the service rule.

The service-set sset1 and service filter walled-tag are applied to a logical interface.

Release History Table
Release
Description
Starting in Junos OS Release 19.1, you can configure Routing Engine-based, static HTTP redirect service filters to specify tags that the Routing Engine inserts in to the packet header of HTTP GET messages for this purpose.