Connection: Tunnels

Tunneling is one way to establish a connection between the Qrator Labs network and your network. This technology allows you to create a virtual connection – tunnel – on top of the Internet and pass traffic through it as if the networks are directly connected to each other. Other Qrator Labs technologies and services, such as reverse HTTP proxies or BGP connections can be set up to run through the tunnel.

Qrator Labs supports point-to-point tunneling using IPIP or GRE.

If you need to protect against DDoS attacks at the application layer of the OSI/ISO model, make sure that server logs are transmitted to the Qrator Labs servers automatically for analysis. If this is not done, reverse TCP proxy will not be able to protect against application layer (L7) attacks.

To start using tunneling, take the following three steps:

  1. Create a tunnel in your personal dashboard (see Tunnels).
  2. Let the tech support know your desired configuration on the Qrator Labs side.
  3. Configure your endpoint.

How tunnels work

A tunnel is created between two endpoints connected to the Internet. One is on the Qrator Labs network, the other is on your network.

An endpoint is an entity that routes inbound and outbound tunnel traffic at one end of the tunnel. For example, an endpoint could be a router, a firewall, a virtual machine with Linux as the router, a server directly hosting your resources, and so on.

Note

An endpoint for the tunnel is created in each of the traffic scrubbing centers in the Qrator Labs network. They all use the same configuration and the same addresses, making them interchangeable. From the customer's perspective, all the endpoints in the Qrator Labs network can be considered as a single endpoint with high fault tolerance.

Two pairs of IP addresses are used when setting up a tunnel: external and internal.

  • Internal addresses are the addresses assigned to the endpoints within a virtual network. For example, an application on your server can send IP packets to an internal address on the Qrator Labs network as if that address were on the same network as the server.

    If the endpoint on your side does not support internal IP addresses when configuring point-to-point tunnels, you can specify the name of the network interface. See Customer-side configuration.

    Internal addresses are generated automatically when adding a tunnel in your personal dashboard.

  • External addresses are real addresses where endpoints are available on the Internet. So, your endpoint packages an IP packet sent to a Qrator Labs internal IP address into another packet sent to a Qrator Labs external IP address.

    The external Qrator IP is the IP address corresponding to the domain for which the tunnel is configured. The customer's external IP address is specified by the customer itself.

All intermediate nodes through which a packet passes in the external network check only the external IP addresses and route the packet according to routing protocols. When a packet arrives at the external IP address of the Qrator Labs-side tunnel, the endpoint discards the external headers and then works with the packet that was originally sent by the application.

So, from the point of view of the customer-side application, the packet is transmitted directly to the Qrator Labs network unchanged, regardless of which route was actually used to reach Qrator Labs.

Packets in the opposite direction are forwarded in the same way.

Configuration on the Qrator Labs side

Port forwarding

To protect the customer against unwanted traffic, the Qrator Labs network passes packets through the tunnel only to ports that the customer has explicitly designated as open. For example, web services usually require that only ports 80 and 443 be kept open.

By default, no ports are considered open. To open a port, create a service of the TCP type in the personal dashboard.

Tunnel redundancy

The Qrator Labs network consists of many traffic scrubbing centers in different regions, but by default they all use the same tunnel to communicate with your endpoint. This tunnel is marked as active tunnel in the Tunnels section of your personal dashboard. You can choose which tunnel you want to make active. The network will not attempt to send traffic to inactive tunnels.

In order to provide redundancy in case of failure and to take full advantage of the Qrator Labs distributed network, it is recommended to set up multiple tunnels to different points and enable automatic switching between them.

Automatic switching works as follows:

  1. Once every 120 seconds, each traffic scrubbing center sends a diagnostic request to the internal customer-side tunnel address to check the availability of each tunnel. The request can be made over ICMP, HTTP or HTTPS. Request parameters and response timeout (in milliseconds) are configurable in the dashboard.

  2. If a traffic scrubbing center fails to receive a response several times in a row, the tunnel is considered temporarily unavailable, and traffic is directed to the next available tunnel according to the list from the dashboard. Tunnel availability statuses are tracked by each traffic scrubbing center independently of other centers.

  3. When the check is successful again, the traffic scrubbing center considers the tunnel available.

So, even if only one tunnel is consistently available from each region, the Qrator Labs network will continue to deliver traffic from any user to your network.

Changing internal IP address

Qrator Labs assigns the same internal IP address to all the tunnels of the same customer. This allows you to use the same configuration on all endpoints on your side. There will be traffic balancing between multiple available tunnels with the same internal IP address.

Note

At your request, Qrator Labs technical support can change the internal IP address of the tunnels.

Customer-side configuration

The endpoint at your end of the tunnel can either be the upstream itself or a router serving several of your servers.

In general, setup boils down to the following steps:

  1. Create a new tunnel in the system using the IP addresses you have generated in your Qrator Labs dashboard. The system will start accepting incoming packets from this tunnel automatically.

  2. Configure the endpoint such that for a packet received through the tunnel, the response packet is also routed to the tunnel. To do this, you can configure a separate routing table (e.g. with VRF), set up policy-based routing (PBR) or use a combination of these methods.

    If it is not possible to configure internal IP addresses for the tunnel, use the name of the tunnel interface when configuring traffic routing to the tunnel. This is possible because point-to-point tunnels are configured.

Please note that without a proper VRF or PBR setup, your endpoint will not be able to send outbound packets through the tunnel and will only receive inbound traffic. This would make the resource not work correctly. The Qrator Labs tech support team will help you make the proper settings.

The Windows operating system does not support VRF and PBR configuration. If your server is running on Windows, you should connect it to the Internet not directly but through a Linux proxy server or a router.

To avoid packet fragmentation when routing, it is recommended to configure the MTU (maximum transmission unit) and MSS (maximum segment size) taking into account the selected tunneling protocol:

  • For IPIP tunnels, set the MTU to be no more than 1480 bytes, MSS to be no more than 1440 bytes.
  • For GRE tunnels, set the MTU to be no more than 1476 bytes, MSS to be no more than 1436 bytes.

If inside a tunnel there will be traffic that is also one or more tunnels, the MTU and MSS values must be adjusted accordingly.