pfSense Multi-WAN Configuration: Part Three

pfSense multi-WAN

Advanced Outbound NAT settings in pfSense 2.2.4.

Some multi-WAN configurations require special workarounds because of limitations in pfSense. This article covers those special cases.

Because of the way pfSense distributes traffic over multiple Internet connections using the same gateway IP, you will need to insert a NAT device between all but one of those connections. This is not an elegant solution, but it is a workable one.

pfSense can only accommodate one PPPoE or PPTP WAN connection. Therefore, OPT WAN interfaces cannot use PPPoE or PPTP WAN types. If you need to use PPPoE or PPTP, the best workaround is to use them on your modem or another firewall. Most DSL modems can handle PPPoE and either directly assign your public IP to pfSense or give it a private IP and provide NAT. Public IP passthrough is possible on many modems and is the preferred means of doing this.

pfSense Multi-WAN: NAT Rules

The default NAT rules generated by pfSense will translate any traffic leaving the WAN or an OPT WAN interface to that interface’s IP address. In a default two interface LAN and WAN configuration, pfSense will NAT all traffic leaving the WAN interface to the WAN IP address. The addition of OPT WAN interfaces extends this to NAT any traffic leaving an OPT WAN interface’s IP address. This is the default behavior and is all handled automatically unless Advanced Outbound NAT is enabled. The policy routing rules direct the traffic to the wAN interface used, and the outbound and 1:1 NAT rules specify how the traffic will be translated. If you require Advanced Outbound NAT with multi-WAN, you will need to configure NAT rules for all your WAN interfaces.

When using port forwarding with a multiple WAN setup, keep in mind that each port forward applies to a single WAN interface. A given port can be opened on multiple WAN interfaces by using multiple port forward entries, one per WAN itnerface. The easiest way to accomplish this is to add the port forward on the first WAN connect, then click the plus button to the right of that entry to add another port forward based on that one. Change the interface to the desired WAN interface, and press the Save button.

1:1 NAT entries are specific to a single WAN interface. Internal systems can be configured with a 1:1 NAT entry on each WAN interface, or a 1:1 entry on one or more WAN interfaces and use the default outbound NAT on others. Where 1:1 entries are configured, they always override any other Outbound NAT configuration for the specific interface where the 1:1 entry is configured.

External Links:

Network Load Balancing on Wikipedia

pfSense Multi-WAN Configuration: Part Two

pfSense multi WAN

Configuring the DNS forwarder in pfSense 2.2.4.

In the first article, we covered some basic considerations with a multi-WAN setup. in this article, we will cover multi-WAN configuration.

First, the WAN interfaces need to be configured. You should set up the primary WAN the same way you would in a single WAN setup. Then for the OPT WAN interfaces, select either DHCP or static, depending on your Internet connection type. For static iP conncections, you will need to fill in the IP address and gateway.

Next, you need to configure pfSense with DNS servers from each WAN connection to ensure it is always able to resolve DNS. This is important, especially if your network uses pfSense’s DNS forwarder for DNS resolution. If you only use one ISP’s DNS servers, an outage of that WAN connection will result in a complete Internet outage regardless of your policy routing configuration.


pfSense uses its routing table to reach the configured DNS servers. This means without any static routes configured, it will use only the primary WAN interface to reach DNS servers. Static routes must be configured for any DNS server on an OPT WAN interface to reach that DNS server. Static routes must be configured for any DNS server on an OPT WAN interface, so pfSense uses the correct WAN interface to reach that DNS server.

This is required for two reasons. [1] Most ISPs prohibit recursive queries from hosts outside their network. Thus, you must use the correct WAN interface to access that ISP’s DNS server. [2] If you lose your primary WAN interface and do not have a static route defined for one of your other DNS servers, you will lose all DNS resultion ability in pfSense, since all DNS servers will be unreachable when the system’s default gateway is unreachable. If you are using pfSense as your DNS server, this will result in a complete failure of DNS for your network.

pfSense Multi-WAN: Static IPs vs. Dynamic IPs

A setup that has all static IPs on the WAN interfaces is easy to handle, as each WAN has a gateway IP that will not change. Dynamic IP WAN interfaces, on the other had, pose difficulties because their gateway is subject to change and static routes in pfSense must point to a static IP address. This usually is not a major problem, since only the IP address changes while the gateway remains the same. If your OPT WAN public IP changes subnets (and therefore gateways) frequently, use of the DNS forwarder in pfSense is not an acceptable solution for redundant DNS servcies; you will still have no reliable means of reaching a DNS server over anything other than the WAN interface.

pfSense multi-WAN

Configuring DNS servers with multiple WAN interfaces in pfSense 2.2.4.

With dynamic IP WANs, you have two alternatives. Because traffic from the inside networks is policy routed by your firewall rules, it is not subject the the limitation of requiring static routes. You can either use DNS servers on the Internet on all your internal systems, or use a DNS server or forwarder on your internal network. As long as DNS requests are initiated from inside your network and not on the firewall itself (as it is in the case of the DNS forwarder), static routes are not required and have no effect on traffic initiated inside your network when using policy routing.

A second option to consider is using one of your DNS server IPs from each Internet connection as the monitor IP for that connection. This will automatically add the appropriate static routes for each DNS server.

If you have a mix of statically and dynamically addressed WAN interfaces, then the primary WAN should be one of your dynamic IP WANs, as static routes are not required for DNS servers on the primary WAN interface.

The image on the right shows separate DNS servers with a multi-WAN setup in pfSense. In System -> General Setup, you can enter the DNS servers, and you can select the gateway used with the selected DNS server in the dropdown box on the right. As you can see, I have selected different WAN interfaces for each of the DNS servers, so the two WAN interfaces (WAN and WAN1) are not dependent on the same DNS server.


 

External Links:

Network Load Balancing on Wikipedia

pfSense Multi-WAN Configuration: Part One

pfSense multi-WANpfSense incorporates the ability to set up multiple WAN interfaces (multi-WAN), which allows you to utilize multiple WAN connections. This in turn enables you to achieve higher uptime and greater throughput capacity (for example, if the user has one 1.5 Mbps connection and a second 2.5 Mbps connection, their total bandwidth using a multi-WAN setup would be 4 Mbps). It has been reported that some pfSense deployments have used as many as 12 WAN connections, and pfSense may scale even higher than that with the right hardware.

Any additional WAN interfaces are referred to as OPT WAN interfaces. References to WAN refer to the primary WAN interfaces, and OPT WAN to any additional WAN interfaces.

There are several factors to consider in a multi-WAN deployment. First, you’re going to want to use different cabling paths, so that multiple Internet connections are not subject to the same cable cut. If you have one connection coming in over a copper pair, you probably want to choose a secondary connection utilizing a different type and path of cabling. IN most cases, you cannot rely upon two or more connections of the same type to provide redundancy. Additional connections from the same provider are typically a solution only for additional bandwidth; the redundancy provided is minimal at best.

Another consideraton is the path from your connection to the Internet. With larger providers, two different types of connections will traverse significantly different networks until reaching core parts of the network. These core network components are generally designed with high redundancy and problems are addressed quickly, as they have widespread effects.

Whether an interface is marked as down or not is determined by the following ping command:

ping -t 5 -oqc 5 -i 0.7 [IP ADDRESS]

In other words, pfSense sends 5 pings (-c 5) to your monitor IP, waiting 0.7 seconds between each ping. it waits up to 5 seconds (-t 5) for a resoibsem and exits successfully if one reply is received (-o). It detects nearly all failures, and is not overly sensitive. Since it is successful with 80 percent packet loss, it is possible your connection could be experiencing so much packet loss that it is unusable but not marked as down. Making the ping settings more strict, however, would result in false posiitives and flapping. Some of the ping options are configurable in pfSense 2.2.4.

In the next article, we’ll cover WAN interface configuration in a multi-WAN setup.


External Links:

Network Load Balancing on Wikipedia

Configuring Dynamic DNS in pfSense

pfSense DDNS

Adding a domain name at the Duck DNS website.

Dynamic DNS (DDNS) is a method of automatically updating a name server in the Domain Name System (DNS), often in real time, with the active DNS configuration of its configured hostnames and/or addresses. The term is used to describe two separate concepts. The first is dynamic DNS updating, which refers to systems that are used to update traditional DNS records without manual editing; this mechanism is described in RFC 2136. The second permits lightweight and immediate updates, often using an update client. These clients provide a persistent addressing method for devices that change their location or IP addresses.

Most internet users who have consumer-grade internet access have a dynamic IP address, most likely assigned by their Internet service provider’s (ISP) DHCP server. These types of IP addresses pose a problem if the user wants to provide a service to other users on the Internet (e.g. a file server). DDNS provides a solution to this problem by providing a means of mapping a potentially rapidly changing IP address to a domain name without suffering the delay which it usually takes for a DNS change to propagate through the hierarchy of DNS servers.


Over the years, several companies and organizations have provided dynamic DNS capabilities. One such company, Dyndns (now called Dyn), provided a free domain name. In 2014, Dyn discontinued their free domain name service. They now charge $40 a year, which I still consider to be a reasonable price. But why pay for domain names when you can still get them for free? Duck DNS provides up to 5 free domain names (all subdomains of duckdns.org; e.g. mydomainname.duckdns.org) and is easy to configure with pfSense. In this article, I will outline the process.

Configuring Dynamic DNS: Creating a Duck DNS Domain Name

First, create a free account on Duck DNS. Once you have done this, scroll down to the domains section of the page. There will be an edit box for entering your domain name and a green add domain button. Enter a domain and press this button; if your domain isn’t taken already, you should see a page similar to the one shown in the screen capture in which your new domain is listed.

Next you need to install the Duck DNS client on your computer. The Windows version of the client can be downloaded from www.etx.ca and installed easily. The Linux version can be installed even more easily. You will need to install zenity, cron and curl first. Cron comes with most if not all Linux distros; zenity and curl can be installed with the apt-get command. There is a script you can download and execute which provides the same functionality as the Windows Duck DNS client. You will need to enter the domain you created in the first step in the Domain field and in the Token field you need to enter the token generated by Duck DNS for your domain. [This token can be found in the as part of the Update URL provided in the pfSense installation instructions on the Duck DNS website. The token is the part between token= and the ampersand.]

Configuring Dynamic DNS: Adding a DynDns Entry in pfSense

pfSense DDNS

Adding a DynDns entry in pfSense 2.2.4.

With Duck DNS configured and the client installed, now we can log into our pfSense box and configure DynDNS. From the pfSense menu, navigate to Services -> Dynamic DNS. There will be two tabs on the page: DynDns and RFC2136; select DynDns if it is not already selected. Press the plus button to the right of the table to add a new entry. For Service type, select Custom from the dropdown box. The Username and Password fields can be left blank. For the Update URL, you need to copy and paste the URL provided in the pfSense installation instructions on the Duck DNS webside. [You can find this instructions page by clicking on install on the menu at the top and then clicking on pfSense in the Routers section.] For Results Match, enter OK. Once these settings are entered, click on Save to save the changes.

Now the dynamic DNS configuration is complete, but since the whole point of setting up DDNS is to make services on your home network available to others, you are probably going to want to add an entry to the Network Address Translation (NAT) table to redirect incoming traffic to the node providing the service. You also need a corresponding firewall rule to allow the traffic through (NAT can create such a rule automatically). This is assuming that you didn’t already alter the NAT/firewall rules for the service you want to make available. One potential issue is that your ISP may block port 80 traffic, so if you want to set up your own web server, you may have to use a different port. [You can use NAT to redirect traffic from the port you selected to port 80.] If you cannot access the service you are trying to make available from the WAN side, you might want to try a different port and see if it works.


External Links:

Dynamic DNS on Wikipedia

Duck DNS website

 

Video: Configuring Dynamic DNS with pfSense

You may want to set up a domain name for your home or SOHO WAN IP. This video demonstrates how to do this. In this video I cover:

  • What DDNS is, why you might want to use it, and different methods of implementing DDNS
  • Configuring Duck DNS on the Duck DNS web site; downloading and installing the Duck DNS client
  • Configuring DDNS in pfSense and setting up NAT so we can access an Apache web server behind the firewall
  • Accessing a web site using the domain name I set up in the previous steps

IPsec VPN Configuration in pfSense: Part One

IPsec VPN

Phase 1 IPsec configuration in pfSense 2.2.4.

In the previous article, we covered how to set up a PPTP VPN connection in pfSense, and how to connect to it in Mint Linux. Since PPTP relies on MS-CHAPv2, which has been compromised, we probably want to use another method if security is paramount. In this article, we will cover setting up an IPsec tunnel with pfSense and connecting to it with Mint Linux.

IPsec VPN Configuration: Phase 1

First we need to set up the IPsec tunnel in pfSense. Navigate to VPN -> IPsec and click on the plus button on on the lower right to add a new tunnel. Under General information, there is an entry for Interface, where we select the interface for the local endpoint of the tunnel. Since our end user will be connecting remotely, the local endpoint should be WAN. The next entry is Remote Gateway, where we enter the IP address or host name of the remote gateway. Enter a brief description and scroll down to the Phase 1 proposal (Authentication) section. At Pre-Shared Key, you need to enter a key (PSK), which will essentially be the tunnel’s password. Whether you alter the Phase 1 proposal (Algorithms) settings or not, take note of the settings, as we will need them for future reference. Press the save button at the bottom to save the Phase 1 configuration. On the next page, press the Apply changes button to commit changes.

IPsec VPN

Phase 2 IPsec configuration.

IPsec VPN Configuration: Phase 2

Now there should be a new entry in the IPsec table for the new Phase 1 configuration. Click on the big plus button underneath the entry you just created to initiate Phase 2 configuration. This section should expand, revealing an empty table for Phase 2 settings. Click on the (smaller) plus button to the right of the table to bring up the Phase 2 settings page. For Mode, you can select whichever method you prefer, but note that whoever connects will have to use the same method. For Local Network, enter the network or address to which you want to give the VPN user access (probably LAN net). For Remote Network, enter the address of the remote end of the VPN tunnel. Enter a brief description. In the Phase 2 proposal section (SA/Key Exchange), set the protocol and encryption options, again taking note of them for future reference (AES-256 is the commonly used standard). When you are done, press the Save button at the bottom of the page. Press the Apply changes button on the next page to commit changes. Finally, check the Enable IPsec check box on the main IPsec page and press the Save button.


Now that Phase 1 and Phase 2 configuration are complete, all that remains is to create a firewall rule for IPsec traffic. Navigate to Firewall -> Rules. There should be a new tab for IPsec; click on it. There may already be a rule there allowing traffic to pass to whatever network or address you specified in the Phase 2 configuration. If not, then create one now by pressing the one of the plus buttons on this page. Most of the default settings can be kept, but set Destination to the network or address specified in Local Network in the Phase 2 configuration. For Destination port range, specify any. Add a brief description, and press the Save button. On the next page, press the Apply changes button to commit these changes.

In part two of this article, we will cover connecting to the VPN tunnel from the remote node.

External Links:

IPsec on Wikipedia

pfSense IPsec configuration information from the official pfSense site

Siproxd: Part One

SiproxdSiproxd is a proxy/masquerading daemon for the SIP protocol. It handles registrations of SIP clients on a private IP network and performs rewriting of the SIP message bodies to make SIP connections work via a masquerading firewall (NAT). It allows SIP software clients or SIP hardware clients to work behind an IP masquerading firewall or NAT router.

SIP, or Session Initiation Protocol, is a standardized set of formats for communicating messages used to initiate, control, and terminate interactive Unicast or Multicast user sessions with multimedia services such as Internet telephone calls, video conferencing, chat, file transfer and online games. Originally developed in 1996 (and standardized in 2002 under the name RFC 3261 by the Internet Engineering Task Force), SIP is the most widely used communication protocol and is the protocol of choice for most VoIP phones to initiate communication. By itself, SIP does not work via masquerading firewalls, as the transferred data contains IP addresses and port numbers. Thus, using SIP over a firewall requires solutions to traverse NAT, but such solutions may have disadvantages or may not be applied in certain situations. Siproxd does not aim to be a replacement for these solutions; however, in some situations it may bring advantages.

Siproxd: Installation and Configuration

Siproxd runs on a variety of Unix variants. It is currently known to work on:

  • Linux
  • FreeBSD
  • OpenBSD
  • SunOS
  • Mac OS X

Installation of the siproxd package in pfSense is easy. Navigate to System -> Packages, scroll down to sixproxd in the packages list, and press the “plus” button (+) to install siproxd. On the next page, press the “Confirm” button to confirm installation, which should take less than two minutes.


Once siproxd is installed, you can begin configuration by navigating to Services -> siproxd. There are three tabs: “Settings“, “Users“, and “Registered Phones“. On the “Settings” tab there are several general settings. Check the “Enable siproxd” check box to enable or disable siproxd. The “Inbound interface” dropdown box allows you to select the inbound interface (usually WAN). You can also select the “Outbound interface” (usually LAN). The “Listening port” edit box allows you to enter the port on which to listen for SIP traffic (default port is 5060). The “Default expiration timeout” specifies the timeout (in seconds), provided that the REGISTER request does not contain an Expires header or an “expires=” parameter.

Under “RTP Settings“, you can configure settings for the Real-time Transport Protocol (RTP), a standardized packet format for delivering audio and video over IP networks. The “Enable RTP proxy” dropdown box allows you to enable or disable the RTP proxy (default is enabled). In the next two edit boxes, you can enter the lower and upper bounds for the RTP port range (the default is 7070 to 7079). Finally, you can enter the “RTP stream timeout”, the number of seconds after which an RTP stream will be considered dead and proxying it will stop (the default is 300 seconds).

The next section is “Dejittering Settings“, which allows you to set an artificial delay to de-jitter RTP data streams (both input and output). The default is zero (no dejittering).

Next is “SIP over TCP Settings“. Here can can configure a “TCP Inactivity timeout” to set the amount of time (in seconds) after which an idling TCP connection will be disconnected. The “TCP Connect Timeout” defines how many milliseconds siproxd will wait for a successful connect when establishing an outgoing SIP signaling connection. “TCP Keepalive” is used for TCP SIP signaling. If this parameter is greater than zero, empty SIP packets will be sent every n seconds (where n is the number specified) to keep the connection alive. The default value is zero (off).

In the next article, we will continue our look at configuring siproxd.


External Links:

The official Siproxd site.

Siproxd on SourceForge.

Real-time Transport Protocol on Wikipedia

Nagios Installation and Configuration: Part Two

NagiosIn the previous article, we introduced Nagios and began covering installation. In this article, we will continue our look at Nagios, covering configuration and installation of plugins.

Nagios Configuration

Now that Nagios has been installed, it’s time to configure it. Sample configuration files have been installed in the /usr/local/nagios/etc directory. For the most part, the settings in the sample files should work fine for getting started with Nagios. You should, however change the e-mail address associated with the nagiosadmin contact definition to the address you’d like to use for receiving alerts. To do so, you change the email field in /usr/local/nagios/etc/objects/contacts.cfg with your favorite editor.

Next, install the Nagios web config file in the Apache conf.d directory:

make install-webconf

Create a nagionsadmin account for logging into the Nagios web interface. Remember the password you assign to this account.

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Now restart Apache to make the new settings take effect.

/etc/init.d/apache2 reload


Next, extract the Nagios plugins source code tarball:

tar xzf nagios-plugins-2.0.3.tar.gz

cd nagios-plugins-2.0.3

Compile and install the plugins:

./configure –with-nagios-user=nagios –with-nagios-group=nagios

make

make install

Now configure nagios to automatically start when the system boots:

ln -s /etc/init.d/nagios /etc/rc5.d/599nagios

Verify the sample Nagios configuration files:

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

If there are no errors, start Nagios:

/etc/init.d/nagios start

You should now be able to access the Nagios web interface at the URL below. You’ll be promoted for the username (nagiosadmin) and password you specified earlier:

http://localhost/nagios/

Click on the “Service Detail” navbar link to see details of what’s being monitored on your local machine. It will take a few minutes for Nagios to check all the services associated with your machine, as the checks are spread out over time.

If you want to receive e-mail notifications for Nagios alerts, you need to install the mailx (Postfix) package:

sudo apt-get install mailx

sudo apt-get install postfix

You’ll have to edit the Nagios e-mail notification commands found in /usr/local/nagios/etc/objects/commands.cfg and change and /bin/mail references to /usr/bin/mail. Once you do that, you’ll need to restart Nagios to make the configuration changes live:

sudo /etc/init.d/nagios restart

In the next article, we’ll access Nagios via the web interface and configure it to work with pfSense.


External Links:

The official Nagios site

Nagios on Wikipedia

netio: A Network Benchmark Tool

netio

netio in action under pfSense 2.1.5.

netio is a network benchmark utility for OS/2 2.x, Windows, Linux and Unix. It measures the net throughput of a network via TCP and UDP protocols using various different packet sizes. For netio to run a benchmark, one instance has to be run on one computer as a server process, while another instance is used on another computer to perform the benchmark. Starting with version 1.20, multi-threading support is required. While this does not affect anyone using the program under Linux or BSD, it did mean that DOS was no longer supported.

netio: Installation and Use

To install netio under pfSense, navigate to System -> Packages, and scroll down to netio in the list. Press the “plus” button to begin installation, and on the next screen, press “Confirm” to confirm installation. netio should complete installation within a few minutes.


Once netio is installed, there will be a new item on the Diagnostics menu called “netio“. If you navigate to it, you will find two tabs: “Client” and “Server“. The “Client” tab, appropriately enough, is to configure netio to run as a client, while “Server” will allow it to act as a server. On the “Client” tab there are two settings: “Server” (for the IP address or hostname netio will connect to) and “Port” (for the port that netio will connect to). On the “Server” tab, there is only one field: “Port“, to specify the port netio will bind to (the default is 18767). Press the “Save” button at the bottom to save settings.

Running netio at the command prompt under Windows 8.1.

Whether you run netio as a client or server, netio requires another node with which to connect. As a result, you are going to have to download netio, which you can do from the official netio site. The zip file contains both the source code and binaries for several platforms, including Windows, Linux, BSD, OS/2 and Mac OS X. Select the right binary for your platform and run netio from your system’s command prompt/shell.

At the risk of stating the obvious, if you are running netio under pfSense as a server, then you want to be running it under the other system as a client, and vice-versa. To test netio, I decided to run it under pfSense as a server (I kept the default port and just pressed “Save”). In Windows, I typed:

win32-i386 -t 192.168.2.1

where win32-i386 is the name of the windows executable, -t specifies the TCP protocol, and 192.168.2.1 is the IP address of the server (my pfSense box). The output of netio can be seen in the screenshot on the right.

And here we are running it under Linux Mint 17.

One problem with this program is that it seems if you connect with one protocol (e.g. TCP), you cannot connect to the server again with another protocol (e.g. UDP). If you try to do this and you get an “error code 10060” message, try restarting the server and then attempt a client connection a second time.

Did I mention that netio supports several platforms? This last screenshot shows what happened when I ran netio under Linux on an old IBM Lenovo M51 running Mint Linux 17. The only shortcoming is that the binary for Linux is version 1.30 of the program, not the latest version (1.32). Thus if you want the latest version under Linux, you’ll have to compile it yourself.


External Links:

The official netio site

HAProxy Load Balancing: Part Two

HAProxy

Listener configuration in HAProxy under pfSense 2.1.5.

In the previous article, we introduced HAProxy as a load balancing solution for TCP and HTTP-based applications. In this article, we will continue our look at HAProxy configuration.

The next setting in the “Settings” tab is “Global Advanced pass thru“, which is for text that you would like to pass through to the global settings area. The next section is “Configuration synchronization“. The first check box allows you to synchronize the HAProxy configuration to back up CARP members via XML-RPC, a remote procedure call which uses XML to encode its calls and uses HTTP as a transport mechanism. The next two fields are for the username and password that will be used during configuration synchronization. The username is general “admin” or an admin-level privileged account on the target system, and the password is generally the remote web configurator password. The next three fields are for sync hosts 1, 2, and 3. HAProxy will synchronize settings to the host’s IP address, if it is specified here. Finally, there are two buttons at the bottom. “Save” will just save the configuration, whereas “Save and Check Config” will parse the automatically generated config file and check for errors.


HAProxy: Configuring Listener Settings

The next tab is “Listener“. By pressing the “plus” button on the right side, you can specify a server to which HAProxy will listen. “Name” is the IP address of the interface to listen to. You can also specify an option “Description“. “Status” indicates whether the server pool is active or disabled. In the next field, “External address“, if you want the rule to apply to an IP address other than the IP address of the interface chosen here, you can select it here. You need to define virtual IP addresses for it first. If you are trying to redirect connections on the LAN, select the “any” option. You can also specify the port to listen to at “External port“, a backend server pool, the default server port, and the protocol at “Type” (HTTP, HTTPS, TCP, or a check for health). You can specifyy an ACL at “Access Control lists“.

Under “Advanced settings“, you can specify several other paramters. “Connection timout” allows you to specify the amount of time in milliseconds HAProxy will wait for a connection to complete, while “Server timeout” indicates the amount of time to wait for data from the server. “Retries” indicates the number of retry attempts. “Balance” indicates what method is used to load balance. If “Round robin” is selected, each server is used in turns, according to their weights. The algorithm is dynamic, which means that server weights may be adjusted on the fly for slow starts. If “Source” is selected, the source IP address will be hashed and divided by the total weight of the running servers to designate which server will receive the request. As a result, the same client IP address will always reach the same server as long as no server goes up or down. If the hash result changes due to the number of running servers changing, many clients will be directed to a different server.

In the next article, we we conclude our look at HAProxy configuration.


External Links:

The official HAProxy site

HAProxy on Wikipedia

© 2013 David Zientara. All rights reserved. Privacy Policy