Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Load Balancing just doesn't work (but 1 WAN or the other is just fine)

    Scheduled Pinned Locked Moved Routing and Multi WAN
    18 Posts 9 Posters 10.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      billm
      last edited by

      I could see there being a potential issue with sticky sessions and multi-wan.  I believe the sticky sessions was really intended for inbound load balancing, not outbound balancing.

      –Bill

      pfSense core developer
      blog - http://www.ucsecurity.com/
      twitter - billmarquette

      1 Reply Last reply Reply Quote 0
      • N
        ns1000
        last edited by

        I am having the same problem, turning the sticky sessions option on caused alot of connection drops. If sticky session is off the behaviour is normal.

        The problem now afcourse, is if there are no sticky sessions available alot of "authorization" is going to fail because the connections are balanced.

        Anyone found a solution for this problem?

        1 Reply Last reply Reply Quote 0
        • F
          Freezone
          last edited by

          My main loadbalancing app is usenet.  So i stopped using loadbalancer and setup static routes to each news server.  Life has been much less fustrating since then.  The loadbalancer in pfsense seems to need much more work.

          1 Reply Last reply Reply Quote 0
          • M
            manjula
            last edited by

            Hi

            Even I had this problem. Then I spent alot of time with pfsense docs and I follow the docs well now its fine. I hope you will have to look at Firewall Rules. And check your routers are in different IP Nets always.

            However try to follow the sample till you get a working balancer and then customize it.

            http://doc.pfsense.org/index.php/MultiWanVersion1.2#Setting_up_Load_Balancing_pools
            http://devwiki.pfsense.org/OutgoingLoadBalancing
            http://devwiki.pfsense.org/IncomingLoadBalancing

            Manjula

            1 Reply Last reply Reply Quote 0
            • G
              guigux
              last edited by

              @billm:

              I could see there being a potential issue with sticky sessions and multi-wan.  I believe the sticky sessions was really intended for inbound load balancing, not outbound balancing.

              –Bill

              i ve just tested it , thinking is a bug while using sticky connections , and load balancer function in output …

              rgrds

              1 Reply Last reply Reply Quote 0
              • E
                eri--
                last edited by

                Well i don't recall if the GUI allows it set sticky connection option for NAT too.
                This should fix the problems.

                1 Reply Last reply Reply Quote 0
                • E
                  eri--
                  last edited by

                  Um just for clearness check the man page and you need to set for nat source-hash

                  1 Reply Last reply Reply Quote 0
                  • E
                    eri--
                    last edited by

                    Can you try the attached patch and report back if it fixes the issues?!

                    Thank you.

                    sticky_address_RELENG_1_2.diff.txt

                    1 Reply Last reply Reply Quote 0
                    • M
                      michelangelo
                      last edited by

                      Hi,
                      I'm having the same problem when using stickies + loadbalancer. What does the patch do? I will try it too anyways.
                      Thanks
                      Rodolfo

                      1 Reply Last reply Reply Quote 0
                      • M
                        michelangelo
                        last edited by

                        While searching the net a bit I found this:

                        http://lists.freebsd.org/pipermail/freebsd-pf/2008-January/003987.html

                        which says:

                        NOTE: I seriously doubt "sticky-address" will work on FreeBSD- it was broken
                        for couple of years already and looks like noone cares to fix it (it work on
                        OpenBSD of course). Without this option load balancing is a joke.

                        Anyone knows how much of this is true?
                        thanks again
                        Rodolfo

                        1 Reply Last reply Reply Quote 0
                        • E
                          eri--
                          last edited by

                          It is not true.

                          Just people misconfigure thing as usual.

                          1 Reply Last reply Reply Quote 0
                          • M
                            moose
                            last edited by

                            @ns1000:

                            I am having the same problem, turning the sticky sessions option on caused alot of connection drops. If sticky session is off the behaviour is normal.

                            The problem now afcourse, is if there are no sticky sessions available alot of "authorization" is going to fail because the connections are balanced.

                            Anyone found a solution for this problem?

                            To get around authorization issues I added firewall rules from LAN to a specific WAN.

                            For instance, I forwarded all HTTPS traffic to WAN1, so banking websites and just about everything else that starts with "https://" doesn't have auth issues.

                            Another example would be AIM/ICQ.  Those two apps require HTTPS to authenticate username and password, then use TCP 5190 to do their thing.  I just forwarded 5190 to WAN1 with the existing HTTPS rule.

                            I have kept sticky connections off as it breaks Source Dedicated Server (srcds).

                            1 Reply Last reply Reply Quote 0
                            • M
                              michelangelo
                              last edited by

                              @eri--:

                              It is not true.

                              Just people misconfigure thing as usual.

                              But in this case things aren't configured automatically by pfsense? I tried the patch, but stickies didn't work as usual :( (it works for say…. 20 minutes then I can't make any connections to the internet). What does the path do?
                              Thanks
                              Rodolfo

                              1 Reply Last reply Reply Quote 0
                              • E
                                eri--
                                last edited by

                                It depends on the load you have. You might be reaching source hash limit.

                                And the patch is a test and if you want it to be correct you should report back your findings.

                                1 Reply Last reply Reply Quote 0
                                • M
                                  michelangelo
                                  last edited by

                                  Hi,
                                  I studied a bit the patch and it seems to add sticky-address to the nat rules. But since I am not using a nat pool, it shouldn't do any difference.
                                  How do I check is I reach limits? BTW I don't think this is the cause, because we have only 5 clients connecting to the interent. I tried setting up a quick'n dirty box with openbsd, and the stickies work flawlessly with 2 wans.
                                  Regards
                                  Rodolfo

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post
                                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.