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

    HAProxy - hostnames not working in backend

    Scheduled Pinned Locked Moved Cache/Proxy
    9 Posts 2 Posters 2.5k 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.
    • M
      madas
      last edited by

      Hello,

      I'm running Pfsense 2.2 on VMWARE and using the HAProxy 1-5 package from the PF repository.

      I have a TCP backend that fails if I am using a FQDN in the address field, but if I switch to the IP address it connects straight away.  If I ssh to the PF box I am able to resolve that DNS entry without problem.  At some point in the past it also worked fine with the DNS name, but I cannot say for sure when it broke (probably around the 2.1 to 2.2 upgrade).

      I have another 2.2 box with the same setup (except not VMWARE) that seems to work fine with a FQDN.

      Any ideas what I might try? am I missing another setting somewhere?

      Thanks

      M

      1 Reply Last reply Reply Quote 0
      • P
        PiBa
        last edited by

        The package webgui resolves the names before putting the resulting ip's into the haproxy config..

        Its done with approximately this command on pfsense 2.2:

        
        /usr/bin/drill {$host_esc} A 127.0.0.1 | /usr/bin/grep {$host_esc} | /usr/bin/grep -v ';' | /usr/bin/awk '{ print $5 }
        
        

        Can you check if that results in the desired ip's when you run it manually?

        What dns settings do you use on pfsense? dnsforwarder or dnsresolver? System/general dns settings?

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

          Hello,

          I use dnsforwarder and in system/general I have both google dns's configured (8.8.8.8 and 8.8.4.4).  I do not have any of the boxes on the system/general page ticked.

          when I run that command manually it says  "Unmatched '."

          breaking it out into just the drill command (where the problem shows) i get this for www.cnn.com.  So something appears wrong with this part of the command (the grep won't find what its looking for)

          [2.2.2-RELEASE][root@xxx]/root: drill www.cnn.com A 127.0.0.1
          ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 6821
          ;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
          ;; QUESTION SECTION:
          ;; 127.0.0.1.  IN      A

          ;; ANSWER SECTION:

          ;; AUTHORITY SECTION:
          .      567    IN      SOA    a.root-servers.net. nstld.verisign-grs.com. 2015050101 1800 900 604800 86400

          ;; ADDITIONAL SECTION:

          ;; Query time: 26 msec
          ;; SERVER: 8.8.8.8
          ;; WHEN: Fri May  1 14:52:14 2015
          ;; MSG SIZE  rcvd: 102

          without the 127.0.0.1 i get

          [2.2.2-RELEASE][root@xxx]/root: drill www.cnn.com
          ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3581
          ;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
          ;; QUESTION SECTION:
          ;; www.cnn.com. IN      A

          ;; ANSWER SECTION:
          www.cnn.com.    200    IN      CNAME  turner.map.fastly.net.
          turner.map.fastly.net.  25      IN      A      23.235.46.73

          ;; AUTHORITY SECTION:

          ;; ADDITIONAL SECTION:

          ;; Query time: 26 msec
          ;; SERVER: 8.8.8.8
          ;; WHEN: Fri May  1 14:55:59 2015
          ;; MSG SIZE  rcvd: 80

          1 Reply Last reply Reply Quote 0
          • P
            PiBa
            last edited by

            Oh in the command above i missed a @ which is actually in the php code..
            Anyway..

            drill www.cnn.com A @127.0.0.1 | grep www.cnn.com
            

            This does not result in a ip but only in a cname..
            While this does:

            drill www.google.com A @127.0.0.1 | grep www.google.com
            

            So it seems im filtering wrong..

            I will try and fix it in a few days..

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

              ah ok - thank you.  So it'll be a fix to HAProxy itself or the webgui script?

              1 Reply Last reply Reply Quote 0
              • P
                PiBa
                last edited by

                Ill fix it in the webgui scripts, which is where i broke it for you also as i introduced that a while back..

                Somewhere around this line..
                https://github.com/pfsense/pfsense-packages/blob/master/config/haproxy-devel/pkg/haproxy_utils.inc#L51

                1 Reply Last reply Reply Quote 0
                • P
                  PiBa
                  last edited by

                  Could you try and test if the line below works for you when you replace it in the  /etc/local/pkg/haproxy_utils.inc ?

                  exec("/usr/bin/drill {$host_esc} $type @$dnsserver | /usr/bin/awk '{ if($1!=\";;\" && $4==\"{$type}\") print $5 }'", $resolved);
                  
                  1 Reply Last reply Reply Quote 0
                  • M
                    madas
                    last edited by

                    Yes sir - that worked.  I was able to connect to a backend that had a FQDN instead of an ip (which failed previously)

                    Thanks

                    1 Reply Last reply Reply Quote 0
                    • P
                      PiBa
                      last edited by

                      This should be fixed / changed and re-fixed with recent pullrequest.. https://github.com/pfsense/pfsense-packages/commit/8d74433d9b8da1fc508f03ad2eb27fd8ea3ba504

                      So 0.26 should work correctly for hopefully all cases. Without drill and with native dns_get_record function..

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