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

    Haproxy setup help

    Scheduled Pinned Locked Moved General pfSense Questions
    37 Posts 2 Posters 14.4k 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.
    • R
      rajbps
      last edited by

      ok might have made some progress. installed a syslog and changed HAproxxy to log everything. When I try to connect the phone from external this is what syslog shows me as error:

      Nov 24 22:40:44 192.168.3.251 ffww syslog notice haproxy[96712] Proxy Iredmail_https_ipvANY started.
      Nov 24 22:40:52 192.168.3.251 ffww syslog info haproxy[96902] X.X.X.X:59323 [24/Nov/2016:22:40:52.070] HTTPS-merged Iredmail_https_ipvANY/mailer 1/0/111 1866 – 1/1/0/0/0 0/0
      Nov 24 22:40:57 192.168.3.251 ffww syslog err haproxy[96902] X.X.X.X:23380 [24/Nov/2016:22:40:52.089] HTTPS-merged HTTPS-merged/ <nosrv>-1/-1/5002 0 SC 0/0/0/0/0 0/0
      Nov 24 22:41:07 192.168.3.251 ffww syslog err haproxy[96902] X.X.X.X:40317 [24/Nov/2016:22:41:07.378] HTTPS-merged HTTPS-merged/ <nosrv>-1/-1/0 0 SC 0/0/0/0/0 0/0
      Nov 24 22:41:25 192.168.3.251 ffww syslog info haproxy[96902] X.X.X.X:10799 [24/Nov/2016:22:41:25.175] HTTPS-merged Iredmail_https_ipvANY/mailer 1/0/132 1866 – 1/1/0/0/0 0/0

      Hope this helps

      Rajbps</nosrv></nosrv>

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

        The "<nosrv>" looks like it might be a problem. It usually means the request does not match the acl's used for the use_backend action. Can you share the haproxy.cfg file from bottom of settings tab?</nosrv>

        1 Reply Last reply Reply Quote 0
        • R
          rajbps
          last edited by

          will send you in a pm in a few min

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

            Could you try configuring the Iredmail backend as the default backend?

            Also afaik a SNIvalue will never contain a 'path' like /owa it might contain a portnumber though.. So add a acl for both  mailer.example.com and mailer.example.com:443 also try capturingnthe phone requests in a wireshark capture, the ssl connection packetshould show if/what sni value is send.

            1 Reply Last reply Reply Quote 0
            • R
              rajbps
              last edited by

              Cheers for that by changing the default to of the Iredmail frontend, the backend bit from default to Iredmail did the trick. Thanks so much for all the help. I am going to change the owa part now and see what happens

              1 Reply Last reply Reply Quote 0
              • R
                rajbps
                last edited by

                Just send you a new pm with the new change. Would you suggest doing the same with the other front ends?

                Cheers,

                Rajbps

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

                  Ok so with the 'default backend' set it works, that confirms the problem was with the requests not matching the acl checks and because of that ending up at <nosrv>.

                  A frontend as configured in haproxy.cfg can effectively only have 1 "default_backend" so no you should not set the default on each 'shared frontend', as available in the webgui. So best would be to figure out why the acl was not matched..

                  If the phones dont send SNI information another workaround could be to 'decrypt/offload' ssl traffic on haproxy preferably with a wildcard certificate to allow haproxy to read the host header in the http request to choose a backend.. Or ofcourse keep it like it is now.. with only the the frontend thats for the phones having a default.</nosrv>

                  1 Reply Last reply Reply Quote 0
                  • R
                    rajbps
                    last edited by

                    Hi PiBa,

                    Sorry to post on this ols post. You assisted me before and hopefully you can assist again. I have an iphone and its been working fine. I added an android today and it does not register with exchange. I done a bit of digging and believe that the issue is haproxy. I can see the following in syslog. Message: x.x.x.x:20655 [13/Jun/2017:20:49:43.498] HTTPS-merged majesty_https_ipvANY/ <nosrv>-1/-1/0 0 SC 1/0/0/0/0 0/0
                    I will send you the haproxy.cfg file in a pm if that`s ok. Could you assist please.

                    Cheers,
                    Rajbps</nosrv>

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

                      The iphone is also using this majesty backend? The backend got picked, but the <nosrv>seems to tell no server could be connected to in that backend. That also seems to match the description for your SC status code (see below). The backend server shows as 'up' on the stats page? Can you tcpdump/wireshark the traffic while the android attempts to connect?

                      SC  The server or an equipment between it and haproxy explicitly refused
                                the TCP connection (the proxy received a TCP RST or an ICMP message
                                in return). Under some circumstances, it can also be the network
                                stack telling the proxy that the server is unreachable (eg: no route,
                                or no ARP response on local network).</nosrv>

                      1 Reply Last reply Reply Quote 0
                      • R
                        rajbps
                        last edited by

                        The iphone has worked with  no issues and still work. Its connecting the the right backend as owa. Just the android seems to try to connect to majesty with is not the exchange server :-(

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

                          Ok 'default_backend majesty' is probably the reason it ends up there.. could be that none of the acl's matched..

                          The current acl might not always match.:
                          acl        OWA  req.ssl_sni -i mail.mydomian.com
                          Could you add also a:
                          acl        OWA  req.ssl_sni -i mail.mydomian.com:443

                          So including the port? that might solve something..

                          p.s. it seems you have to many 'default_backend' configured anyhow. but if the acl's pick up the traffic you shouldnt end up on majesty. (when requesting mail.mydomian.com)

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