Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Traffic Redirection Overview

    The redirect server is part of a captive portal system that redirects subscribers’ Web requests to a captive portal page. You can use a captive portal page as the initial page a subscriber sees after logging in to a subscriber session and as a page used to receive and manage HTTP or HTTPS requests to unauthorized Web resources.

    Proxy Request Management

    The redirect server examines requested paths and detects proxy HTTP requests by the proxy prefix “<scheme>:” followed by the address of the requested host. If the requested URL is served by the captive portal server:

    1. The redirect server opens a TCP connection to the captive portal and forwards the request for the URL. The redirect server adds to the request an X-Forwarded-For header that specifies the IP address of the client.
    2. The captive portal server inspects the incoming request for the X-Forwarded-For header for the IP address. The captive portal server uses this address instead of the source IP address to determine the originator of the request.
    3. If the captive portal authorizes the client and activates a service that enables a direct connection between the client and the proxy, the redirect server then sends the returned data to the subscriber’s Web browser.

      or

      If the requested URL is not served by the captive portal server, the redirect server opens a TCP port and sends the type of response configured to a subscriber’s browser in response to a captured request:

      • HTTP 200 OK response with an HTML document that includes the <HTTP-Equiv="Refresh"> header (default)
      • HTTP 302 Found response to a subscriber’s browser in response to a captured request

        The subscriber browser follows the redirect request, and the proxied request is served by the redirect server again, which opens a connection to the captive portal.

    Support for HTTP proxy requests requires the following:

    • A local HTTP proxy server that can handle the traffic from all clients configured with a proxy.
    • A location for the local HTTP proxy server that is one IP hop from each access router.
    • A proxy service that the captive portal server can activate to send proxy requests to the local HTTP proxy server when the portal server authorizes proxy clients.
    • A proxy service activation policy that includes a next-hop policy that points to the local HTTP proxy server, and a classifier that matches the client’s IP address and the address of the proxy server configured on the client.

    Services that the client accesses through the proxy server, such as HTTP and FTP, cannot be activated based on destination address.

    You must redirect all ports to the redirect server because you cannot know which ports are configured on the client for the proxy. Consequently, the redirect server receives non-HTTP requests as well as HTTP requests. The non-HTTP requests generate error log entries. To reduce overhead, HTTP error messages are logged as system log debug messages.

    HTTP Proxy and DNS

    Make sure that your network includes a domain name service (DNS) server to resolve unknown names to a fixed IP address. A DNS server is required because proxy servers can be configured with DNS names in private domains that are not valid in the public environment. You can use the DNS server included with the redirect server, or another DNS server on your network.

    The DNS server can be configured on a client with DHCP. Alternatively, the service provider can set up a transparent DNS proxy by configuring a next-hop policy on the JunosE router for UDP and TCP port 53 traffic. The policy redirects traffic on these two ports to the redirect server’s DNS server.

    Because proxy addresses must be resolved even if general access to the Internet is enabled, the DNS server must continue to resolve all client requests for proxy clients. Nonproxy clients can use their regular DNS server after the initial service has been activated.

    The redirect server’s DNS server either forwards the request to a set of configured DNS servers or resolves the request by using the root domain name server. If a request for an IPv4 or IPv6 address cannot be resolved and the request results in an NXDOMAIN error, the DNS server returns a configurable IP address. The redirect server returns an error message to the clients for any other type of request that cannot be resolved.

    HTTPS Traffic Redirection Support

    The SRC software supports to redirect HTTPS traffic by using the redirect server. The redirect server redirects HTTPS traffic to a configured destination web server. The redirect server requires a Secure Sockets Layer (SSL) certificate.

    Note: Whenever you open up an HTTPS page, you get a security warning in the browser for the mismatch between common name of the certificate with the domain name of the URL until you add an exception for the certificate in the browser.

    Protection Against Denial-of-Service Attacks

    The redirect server incorporates a number of properties to protect against denial-of-service attacks. The following list shows the default values set for these properties:

    • The redirect server can serve no more than 12,000 requests per minute, with a burst of 18,000 requests.
    • The redirect server can serve no more than 25 requests per client per minute, with a burst of 50 requests.
    • Incoming requests can be no larger than 4 KB.
    • Incoming requests have a time limit of 2 seconds.

    You can change the values for any of these properties.

    Published: 2014-12-10