Skip to main content

Layer 4 Proxy

ArvanCloud's layer 4 proxy feature helps you provide security and acceleration for TCP or UDP based applications. Using this feature, you can route Non-Web protocols such as email, SSH, FTP, games, etc. through TCP or UDP in ArvanCloud, to hide the address of the origin servers and protect them from DDoS attacks.

When creating a layer 4 proxy application, ArvanCloud assigns it an IP from its set of IPs. It is also possible to transfer it to ArvanCloud to use your desired IP. After migration, ArvanCloud will advertise your private IP in Anycast format and use it exclusively for your website and applications.

To start, it is enough to create an application from "ArvanCloud User Panel > CDN > Choose Domain > Security > Layer 4 Proxy > New Application".

1st Step: Application Settings

In this page, first entering the name and description of your application, select a subdomain on which you want to create the application.

Note that this subdomain must not be already used.

In the following sections, it is necessary to specify the port, protocol and how to use PROXY PROTOCOL.

Protocol

The protocol based on which the traffic received from the users is received. You can choose TCP or UDP protocol.

Note that the protocol cannot be edited once selected.

Port

The port to which users send their requests and is hosted on the CDN network. The selected port must be unique among your applications and you cannot use the same port more than once.

Note that the port cannot be edited once selected.

PROXY PROTOCOL Support

Since ArvanCloud monitors packets before sending them to the main server, you will see ArvanCloud's IP in your logs instead of the actual user's IP.

It may be necessary to get the user's real IP in some services. In these cases, you can use the PROXY PROTOCOL to forward the user's IP to your service. Sending proxy information depends on whether TCP or UDP is used. For TCP, ArvanCloud supports Proxy Protocol v1 and Proxy Protocol v2, which are also supported by NGINX.

  • Activating Version 1:

    Version 1 sends each connection with a header containing the user's IP address and port.

    A version 1 header has the following format:

    PROXY_STRING + single space + INET_PROTOCOL + single space + CLIENT_IP + single space + PROXY_IP + single space + CLIENT_PORT + single space + PROXY_PORT + "\r\n"

    An example Proxy Protocol v1 for an IPv4 address is as follows:

    PROXY TCP4 192.0.2.0 192.0.2.255 42300 443\r\n

    An example Proxy Protocol v1 for an IPv6 address is as follows:

    PROXY TCP6 2001:db8:: 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff 42300 443\r\n
  • Activating Version 2:

    When TCP applications are configured to use Proxy Protocol v2, ArvanCloud adds a binary Proxy Protocol v2 header to each incoming TCP connection. Proxy Protocol v2 sends each connection with a header containing the user's IP address and port.

    A binary Proxy Protocol header for an IPv4 ingress address looks like this:

0          1          2          3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

\+ +

| Proxy Protocol v2 Signature |

\+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version|Command| AF | Proto.| Address Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| IPv4 Source Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| IPv4 Destination Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port | Destination Port |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A binary Proxy Protocol header for an IPv6 ingress address looks like this:

 

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

\+ +

| Proxy Protocol v2 Signature |

\+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version|Command| AF | Proto.| Address Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

\+ +

| |

\+ IPv6 Source Address +

| |

\+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

\+ +

| |

\+ IPv6 Destination Address +

| |

\+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port | Destination Port |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2nd Step: Load Balancing Settings

At this point, you can create a cluster by entering the addresses of multiple origin servers. Then, use page rules to send one-way traffic from your domain to this cluster, and use the monitoring section to monitor the status of the cluster.

  • Load Balancing Method

    In this section, you can specify the algorithm based on which an address is selected from among the addresses of the origin servers.

    • Round Robin Algorithm

      This algorithm is the simplest and most common load balancing algorithm. User requests are distributed between your origin servers in simple rotation. For example, imagine you have 6 users (u1, u2, u3, u4, u5 and u6) who want to connect to your application and you have 3 servers (s1, s2 and s3). u1 is connected to s1, u2 to s2 and u3 to s3, and then u4 is connected to s1, u5 to s2 and u6 to s3. Round Robin algorithm is suitable for predictable requests and servers with relatively equal processing power and resources.

      But if one of the servers has more capacity to handle requests than the others, you can use the maximum power of that server with the help of weighting.

      Weighted Round Robin is a slightly more advanced algorithm for load balancing. Imagine that s1 is twice as powerful as s2 and s3. As a result, it can be assigned more weight because it can carry more load and because the assigned weight is more, it will have more traffic.

      The main difference is that in the example above, u1 connects to s1 and then u2 connects back to s1. U3 is connected to s2 and u4 to s3, then u5 to s1 and u6 to s1.

      There is another scenario where Weighted Round Robin can be useful. Maybe your servers are similar, but you have more important data on one and want it to weigh less. So, in this case you assign higher values to the rest of the servers. This way they handle more load and your critical server will have less processing and traffic load.

    • Source Algorithm

      This method combines the source and destination IP addresses of the traffic and uses a mathematical function to convert it into Hash. Based on this Hash, the request is assigned to a specific server. Since the key can be regenerated by terminating a session, the user's request is directed to the same server that was connected to in the first request. This method is more suitable when consecutive connections of a user need to always return to the same server.

    • Least Connection Algorithm

      In this method, it is assumed that all requests require the same amount of processing power, and as a result, the request goes to the server that has the least open connection at the moment.

  • Servers

    In this section, you must enter the IP address of your servers along with the desired port and weight of each one.

3rd Step: Monitoring Settings

When an error occurs in one of the defined cluster servers, ArvanCloud can take that server out of the circuit and stop sending traffic until the error is fixed. Also this feature can report the errors of that server via email.

In this page, the "Repetition Interval" means the time interval for sending monitoring requests to the main servers.

Also, the "Number of Tolerable Errors" is the threshold of errors that must occur in order to consider the status of that server as faulty.

4th Step: Firewall Settings

Using a firewall, you can block access to your application based on two parameters, IP and country.

ArvanCloud Layer 4 proxy provides DDoS protection at layers 3 and 4 of the OSI model (TCP and UDP based attacks).

ArvanCloud works as a Layer 4 reverse proxy, so a proper TCP connection must first be established before traffic is proxied to the origin. This forwards any impact of SYN or SYN-ACK attacks to ArvanCloud's edge servers. In addition, by using a layer 4 proxy in front of your application, your source IP will be hidden and your servers IP will be prevented from being targeted. It is recommended to close the access of all IPs to the main server after transferring the traffic to the ArvanCloud and whitelist only the IP range of the ArvanCloud servers.

Final Step: Submitting Request

Finally, to activate the Layer 4 Proxy on the cluster you created, you need to be in contact with the ArvanCloud support team through tickets or organizational support groups.