pfSense Support Subscription

Author Topic: source-track, src.track, and incoming load balancing  (Read 1274 times)

0 Members and 1 Guest are viewing this topic.

Offline adam65535

  • Sr. Member
  • ****
  • Posts: 326
  • Karma: +9/-0
    • View Profile
source-track, src.track, and incoming load balancing
« on: April 24, 2013, 10:03:52 am »
I noticed that 2.1 will support src.track option based on the feature list.  Does that sticky source tracking timeout (not to be confused with normal state timeout) only apply to rules that specify source-track rule option and sticky-address option on nat rules?  I am hopeful that is true because that would open up a lot of ways to restrict it's use to just load balance connections.  From my reading on openbsd it seems that is true which I assume this is based on:

The goal is to keep incoming load balance connections from an individual IP going to a single server for up to 5 minutes even if there are no firewall states for that source IP for up to 4 minutes and 59 seconds before another connection from that source IP comes in.  I only want that behavior for the load balance rules.  If it only applies to rules that use source-track and sticky-address then that would be ideal because some load balance rules I would not want to use that behavior so on some I would.  Assuming that option were put into a per load balance rule.

I wonder if pfctl -K (not be be confused with lowercase -k) would need to be used to kill any active source tracking connections form connections to that server when the server stopped responding too.  If that didn't happen existing connections would take up to src.track timeout before moving to the working server.  I would generally set it to 5 minutes and that would be unacceptable for a failover to fully start working.  With pfctl -K the IPs would be cleared so that connections from a specific source would be guaranteed to go to the backup load balance server.
This problem is also mentioned here but for openbsd:

set timeout option value
  Set various timeouts (in seconds).
    interval - seconds between purges of expired states and packet fragments. The default is 10.
    frag - seconds before an unassembled fragment is expired. The default is 30.
    src.track - seconds to keep a source tracking entry in memory after the last state expires. The default is 0 (zero).

set timeout src.track 300

I wonder if the reason above is why the person who posted below did not get it to work when he patched pfsense to set that timeout.  He probably didn't specify source-track option on a load balance rule.

Finding details on this option seems very difficult and it seems to be misunderstood a lot when discussed so I am trying to find out how it really works.
« Last Edit: April 24, 2013, 11:05:05 am by adam65535 »