HAProxy - hostnames not working in backend



  • 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



  • 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?



  • 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



  • 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..



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



  • 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



  • 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);
    


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

    Thanks



  • 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..


Log in to reply