Navigation

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

    Feature Request: move listen (pool) port to the virtual server config tab entry

    General pfSense Questions
    2
    4
    662
    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.
    • A
      adam65535 last edited by

      In the loadbalancer (relayd) configuration it would be great to reuse pools for multiple virtual servers.  I have a couple groups of servers that host different services but contain the same list of servers.  Currently you can not reuse the same pool for multiple services because the listen port is defined with the pool.

      The config files get generated so that pools only specify the servers and not the port.  The listen and forward port are put into the raw config file in the redirect item so there is no technical reason that the listen port would be defined in the pool.

      This is the way things are generated now where you have to define two different pools.

      table <serverpool1>{ 10.1.1.1, 10.1.1.2 }
      table <serverpool2>{ 10.1.1.1, 10.1.1.2 }
      redirect "VirtualServer1" {
        listen on 20.1.1.1 port 80
        forward to <serverpool1>port 80 check tcp
      }
      redirect "VirtualServer2" {
        listen on 20.1.1.1 port 443
        forward to <serverpool2>port 443 check tcp
      }

      This is what could be generated if pools only specified the servers and not the port:

      table <serverpool1>{ 10.1.1.1, 10.1.1.2 }
      redirect "VirtualServer1" {
        listen on 20.1.1.1 port 80
        forward to <serverpool1>port 80 check tcp
      }
      redirect "VirtualServer2" {
        listen on 20.1.1.1 port 443
        forward to <serverpool1>port 443 check tcp
      }

      If the pool just specified the servers and not the listen port and the virtual server defined the listen port and forward port I could make use of the same pool specification for multiple virtual servers.  This would reduce the amount of gui work to setup multiple services on the same group of servers.

      Is there some other reason pools are associated with ports that I am not aware of?  It just seems like how it was implemented and not a technical reason to associate the port with the pool.

      I realize nobody will have time to implement this as I am sure there are more important things to work on but it would be a nice thing to keep in mind for the future.  Less work to do the same thing is a sure win for people using a lot of load balancer entries.</serverpool1></serverpool1></serverpool1></serverpool2></serverpool1></serverpool2></serverpool1>

      1 Reply Last reply Reply Quote 0
      • jimp
        jimp Rebel Alliance Developer Netgate last edited by

        That would remove functionality that people require now. The port for the VS and the port for the pool are separate. They do not have to be the same. The VS can listen on one port and the actual servers in the pool can listen on another, for example a VS on port 80 but the pool servers are on port 8080 running unprivileged. Moving that to an additional setting on the VS might work, but introduces other issues on upgrade or otherwise accommodating existing configurations that need to use separate ports.

        1 Reply Last reply Reply Quote 0
        • A
          adam65535 last edited by

          The ports could still be different.  You would just specify both ports separately into the Virtual Server definition instead of one in the pool and one in the virtual server entry.  This would allow the two ports to be different and still be able to reuse tables (pools).

          Upgrading script would require looking up the pool associated with the virtual server and pull in the port that was specified for the pool and put it into the newly added port specification on the virtual server.  There will be 2 ports specified on the virtual server entry now.  The only issue to the upgrade script would be what to do if someone has a pool defined but does not have a virtual server defined yet for it.  Since there would be no association to put the pool port into a virtual server you would just not use the port specified anymore.  That is really not a complication though and more of a realizing that both ports or now specified in the virtual server entry.

          This configuration matches the way the relayd actually gets configured in the config file and allows for pool reuse for other virtual servers.

          1 Reply Last reply Reply Quote 0
          • jimp
            jimp Rebel Alliance Developer Netgate last edited by

            As the saying goes: Patches accepted.

            I don't see anyone here going through the trouble, but if the code shows up…

            1 Reply Last reply Reply Quote 0
            • First post
              Last post

            Products

            • Platform Overview
            • TNSR
            • pfSense Plus
            • Appliances

            Services

            • Training
            • Professional Services

            Support

            • Subscription Plans
            • Contact Support
            • Product Lifecycle
            • Documentation

            News

            • Media Coverage
            • Press
            • Events

            Resources

            • Blog
            • FAQ
            • Find a Partner
            • Resource Library
            • Security Information

            Company

            • About Us
            • Careers
            • Partners
            • Contact Us
            • Legal
            Our Mission

            We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

            Subscribe to our Newsletter

            Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

            © 2021 Rubicon Communications, LLC | Privacy Policy