Load balancing

Flows and outflows

On this page

Available since

  • Outflows are available since ALOHA 16.0.

Use the Flows tab to configure flows and outflows. A flow or outflow can specify whether matching packets should be allowed, dropped, or routed according to a routing table. Matching criteria can include any combination of interface, protocol, IP address, and port. In addition, flows (not outflows) can also direct incoming traffic to an LVS load balancer (see LB Layer4 tab).

  • A flow defines match rules and a routing policy for incoming packets. Flows are particularly powerful because they can match on ranges of IP addresses and ports. This capability allows them to direct the matching traffic to an LVS load balancer, which would otherwise be limited to traffic from a single IP address and port.

  • An outflow defines match rules and a routing policy for outgoing packets. For example, you can use an outflow to specify a custom routing table that applies to a load balanced application’s return traffic. The ability to specify outflow matching is particularly important when you need to specify the gateway for outgoing packets.

    Important

    For a given TCP connection, the outgoing packets do not automatically use the same interface as the incoming packets. Instead, the outgoing packets use the gateway indicated in the main routing table. To control the route for outgoing packets, define an outflow and a custom routing table.

    Policy-based routing

    Beginning in HAProxy ALOHA 16.5, you can also use policy-based routing to accomplish custom routing.

Configuration file syntax Jump to heading

Define flows by including flow sections in the flowmgr configuration file. Flows are evaluated sequentially.

text
{ flow | outflow } <name> <policy>
  <rule>  [ [ not ] iface <name> ]
          [ [ not ] proto { tcp | udp | icmp } ]
          [ [ not ] src <ip>[/<mask>] ]
          [ [ not ] dst <ip>[/<mask>] ]
          [ [ not ] srcport <port>[:<port>] ]
          [ [ not ] dstport <port>[:<port>] ]
          [ [ not ] icmptype <icmptype> ] ]
  [<rule>]...
text
{ flow | outflow } <name> <policy>
  <rule>  [ [ not ] iface <name> ]
          [ [ not ] proto { tcp | udp | icmp } ]
          [ [ not ] src <ip>[/<mask>] ]
          [ [ not ] dst <ip>[/<mask>] ]
          [ [ not ] srcport <port>[:<port>] ]
          [ [ not ] dstport <port>[:<port>] ]
          [ [ not ] icmptype <icmptype> ] ]
  [<rule>]...

The terms are as follows.

Info

Where the term flow is used, the term outflow may be substituted except where indicated.

name Jump to heading

  • name

    Unique identifier for this flow. Allowed characters are alphanumerics, hyphen (-), and underscore (_). Maximum length is 27 characters.

policy Jump to heading

  • policy

    Action to be applied. One of:

    Policy Description
    permit Matching packets are allowed.
    deny Matching packets are dropped.
    director <director_name> Matching packets are routed using the specified LVS director. Directors are defined in the LB Layer4 tab. Available for flows only, not outflows.
    skip The flow is skipped and the next one is evaluated. This policy is useful for temporarily disabling a flow. This policy is the default action if no other policy is specified.
    table <id> Matching packets are routed using the specified custom routing table instead of the default system routing table. Routing tables are defined in network setup under the Services tab. Available since HAProxy ALOHA 12.5.

rule Jump to heading

  • rule

    The match and ignore rules are evaluated sequentially.

    Rule Description
    match If a packet matches the specified conditions, the defined policy is immediately applied. Otherwise, the next ignore or match rules of the current flow are evaluated. If there are no more rules, the packet is considered not part of the current flow and the next flow is evaluated.
    ignore If a packet matches the specified conditions, the packet is considered not part of the current flow and the next flow is evaluated. Otherwise, the next ignore or match rules of the current flow are evaluated.

conditions Jump to heading

  • conditions

    If no conditions are specified, all packets are considered a match. To negate the match, use the keyword not. Use the following terms to specify match conditions.

    Condition Description
    proto IP protocol: tcp, udp or icmp.
    iface In a flow (incoming packets): input network interface. In an outflow (outgoing packets): routing chosen output interface.
    src Packet IP source address, or network mask.
    dst Packet IP destination address, or network mask.
    srcport Packet port source, or port range. Only available for udp and tcp protocols.
    dstport Packet port destination, or port range. Only available for udp and tcp protocols.
    icmptype Packet icmp type code. Only available for icmp protocol.

Important

To save a new flow or changes to an existing flow, save the HAProxy ALOHA configuration. Click on the Setup tab. In the Configuration section, click Save.

Examples Jump to heading

In this section, we demonstrate examples that use the Flows tab.

Allow access only to clients in a given network Jump to heading

This flow allows users to access a specific host using ssh but only if they are on the same network as the host.

  1. From the Flows tab, add the following lines:

    haproxy
    flow ssh permit
      ignore not src 192.168.0.0/24
      match proto tcp dst 192.168.0.1 dstport 22
    haproxy
    flow ssh permit
      ignore not src 192.168.0.0/24
      match proto tcp dst 192.168.0.1 dstport 22

    where:

    • We define a flow named ssh that will permit only traffic that matches the rules.
    • We ignore all traffic unless it comes from the 192.168.0.0/24 network, so that the permit policy applies only to it.
    • We match on TCP traffic targeting the IP/port 192.168.0.1:22.
    • If the packet does not match these conditions, it is passed through to the next flow for processing.

  2. Click OK, then Apply.

  3. To make the changes persist after a reboot, go to the Setup tab and click Save within the Configuration section.

Match UDP packets Jump to heading

This flow allows UDP packets to go to a DNS server.

  1. From the Flows tab, add the following lines:

    haproxy
    flow dns permit
      match proto udp dst 192.168.0.1 dstport 53
    haproxy
    flow dns permit
      match proto udp dst 192.168.0.1 dstport 53

    where:

    • We define a flow named dns that will permit only the traffic that matches the rules.
    • We match UDP traffic targeted for IP/port 192.168.0.1:53.
    • If the packet does not match these conditions, it is passed through to the next flow for processing.

  2. Click OK, then Apply.

  3. To make the changes persist after a reboot, go to the Setup tab and click Save within the Configuration section.

Match ICMP messages Jump to heading

This flow allows echo replies to reach a specific host, regardless of where they originate. It also allows other types of ICMP packets to reach the host but only if they originate on the same network as the destination host.

  1. From the Flows tab, add the following lines:

    haproxy
    flow ping permit
      match proto icmp dst 192.168.0.1 icmptype 0
      ignore not src 192.168.0.0/24
      match proto icmp dst 192.168.0.1
    haproxy
    flow ping permit
      match proto icmp dst 192.168.0.1 icmptype 0
      ignore not src 192.168.0.0/24
      match proto icmp dst 192.168.0.1

    where:

    • We define a flow named ping that will permit only the traffic that matches the rules.
    • We match ICMP traffic targeted for IP 192.168.0.1 with an icmptype value of 0. If the packet does not match these conditions, it is passed to the next rule for processing.
    • Any packet not originating on the 192.168.0.0/24 network is ignored by this flow but is passed through to the next flow for processing. If the packet does originate on the 192.168.0.0/24 network, it is passed to the next rule for processing.
    • Any ICMP packet targeted for IP 192.168.0.1 is permitted. If the packet does not match these conditions, it is passed through to the next flow for processing.

  2. Click OK, then Apply.

  3. To make the changes persist after a reboot, go to the Setup tab and click Save within the Configuration section.

Route traffic to LVS Jump to heading

You can define a flow to direct traffic to a Layer 4 LVS load balancer. This configuration is particularly useful because an LVS load balancer, by itself, can bind to only one IP address and port. Using a flow, you can direct traffic from multiple IP addresses and ports to the LVS load balancer. In this flow, mail traffic targeted at ports 110, 143, and 25 are all routed to an LVS load balancer named maildirect.

  1. From the Flows tab, add the following lines:

    haproxy
    flow mail director maildirect
      match proto tcp dst 192.168.0.2 dstport 110
      match proto tcp dst 192.168.0.2 dstport 143
      match proto tcp dst 192.168.0.2 dstport 25
    haproxy
    flow mail director maildirect
      match proto tcp dst 192.168.0.2 dstport 110
      match proto tcp dst 192.168.0.2 dstport 143
      match proto tcp dst 192.168.0.2 dstport 25

    where:

    • We define a flow named mail that will direct only the traffic that matches the rules. Directed traffic goes to the Level 4 LVS load balancer named maildirect.
    • We match TCP traffic targeted for IP/port 192.168.0.2:110 and send it to LVS director maildirect. If the packet does not match these conditions, it is passed through to the next rule for processing.
    • We match TCP traffic targeted for IP/port 192.168.0.2:143 and send it to LVS director maildirect. If the packet does not match these conditions, it is passed through to the next rule for processing.
    • We match TCP traffic targeted for IP/port 192.168.0.2:25 and send it to LVS director maildirect. If the packet does not match these conditions, it is passed through to the next flow for processing.

  2. Click OK, then Apply.

  3. To make the changes persist after a reboot, go to the Setup tab and click Save within the Configuration section.

Direct outgoing traffic to a gateway Jump to heading

Normally, traffic returns to the client via the default gateway defined in the main routing table. When you have multiple network interfaces, however, you may want to route traffic through a different gateway, for example, the one that it arrived through. This example shows how to create a custom routing table and a flow that sets a policy to use that routing table.

  1. In the Services tab, click network instance setup next to the network interface that is on the network with the desired gateway. For example, if you have a second interface named eth1, add the following:

    service network eth1
  ip address 192.168.161.10/255.255.255.0
  ip route default 192.168.161.1 table 200
    service network eth1
  ip address 192.168.161.10/255.255.255.0
  ip route default 192.168.161.1 table 200

    where:

    • The ip address line sets a static IP address of 192.168.161.10 for the interface.
    • The ip route line sets a default route of 192.168.161.1 and assigns it to a custom routing table with the ID 200. Because we’re using a custom routing table, traffic will not use this route until we define an outflow for it.

  2. Click OK and Close to return to the Services tab.

  3. Restart the network service.

    Version > 16.0

    In versions greater than 16.0, instead of manually restarting the network service, click the Apply new configuration button on the interface to apply the changes and automatically restart the network interface service.

  4. From the Flows tab, add the following lines:

    outflow return-eth1 table 200
  match proto tcp src 192.168.161.0/24 srcport 80
    outflow return-eth1 table 200
  match proto tcp src 192.168.161.0/24 srcport 80

    where:

    • We define an outflow named return-eth1 that will use the custom routing table with ID 200 if the following rules match.
    • We match on TCP traffic that has a source IP address within the 192.168.161.0/24 network and a source port of 80. Here, source means a VIP on the HAProxy ALOHA. Note that you can assign a single IP address by leaving off the CIDR /24.

    Alternatively, you could match on the VIP’s interface by using the iface argument:

    outflow return-eth1 table 200
  match iface eth1
    outflow return-eth1 table 200
  match iface eth1

  5. Click OK, then Apply.

  6. To make the changes persist after a reboot, go to the Setup tab and click Save within the Configuration section.

Block unpermitted traffic Jump to heading

For security purposes, you may want to deny all traffic not explicitly permitted or routed in other flows.

  1. From the Flows tab, add the following lines:

    haproxy
    flow alltherest deny
      match
    haproxy
    flow alltherest deny
      match

    where:

    • We define a flow named alltherest that will deny the traffic that matches the rules.
    • We match all packets. This flow is useful for placing at the end of the flowmgr configuration to block all traffic not explicitly permitted in preceding flows.

  2. Click OK, then Apply.

  3. To make the changes persist after a reboot, go to the Setup tab and click Save within the Configuration section.

Do you have any suggestions on how we can improve the content of this page?

Previous page Geolocation with MaxMind Next page GSLB
© 2024 HAProxy Technologies, LLC. All Rights Reserved
Manage Cookie Preferences