Re: dns fails to process response / hold valid? (since commit 2.2-dev0-13a9232)
Pieter,
Am 09.02.20 um 15:35 schrieb PiBa-NL:
> Before commit '2.2-dev0-13a9232, released 2020/01/22 (use additional
> records from SRV responses)' i get seemingly proper working resolving of
> server a name.
> After this commit all responses are counted as 'invalid' in the socket
> stats.
I can confirm the issue with the provided configuration. The 'if (len ==
0) {' check in line 1045 of the commit causes HAProxy to consider the
responses 'invalid':
https://github.com/haproxy/haproxy/commit/13a9232ebc63fdf357ffcf4fa7a1a5e77a1eac2b#diff-b2ddf457bc423779995466f7d8b9d147R1045-R1048
Best regards
Tim Düsterhus
Re: dns fails to process response / hold valid? (since commit 2.2-dev0-13a9232)
Pieter, Am 17.02.20 um 22:14 schrieb PiBa-NL: > (maybe the pcap attachment didn't fly well through spam filters. (or the > email formatting..)?) I received your first email perfectly fine. > If someone was already planning to, please don't feel 'pushed' by this > mail. i'm just trying to make sure this doesn't fall through the cracks :). I can't comment on the issue you are seeing, but consider filing an issue in the tracker if you don't get a reply on this "push" either: https://github.com/haproxy/haproxy/issues Other users have reported issues with 2.2-dev before. Best regards Tim Düsterhus
Re: dns fails to process response / hold valid? (since commit 2.2-dev0-13a9232)
Hi List, Hereby a little bump. Can someone take a look? (maybe the pcap attachment didn't fly well through spam filters. (or the email formatting..)?) (or because i (wrongly?) chose to include Baptiste specifically in my addressing (he committed the original patch that caused the change in behaviour)..) Anyhow the current '2.2-dev2-a71667c, released 2020/02/17' is still affected. If someone was already planning to, please don't feel 'pushed' by this mail. i'm just trying to make sure this doesn't fall through the cracks :). Regards, PiBa-NL (Pieter) Op 9-2-2020 om 15:35 schreef PiBa-NL: Hi List, Baptiste, After updating haproxy i found that the DNS resolver is no longer working for me. Also i wonder about the exact effect that 'hold valid' should have. I pointed haproxy to a 'Unbound 1.9.4' dns server that does the recursive resolving of the dns request made by haproxy. Before commit '2.2-dev0-13a9232, released 2020/01/22 (use additional records from SRV responses)' i get seemingly proper working resolving of server a name. After this commit all responses are counted as 'invalid' in the socket stats. Attached also a pcap of the dns traffic. Which shows a short capture of a single attempt where 3 retries for both A and records show up. There is a additional record of type 'OPT' is present in the response.. But the exact same keeps repeating every 5 seconds. As for 'hold valid' (tested with the commit before this one) it seems that the stats page of haproxy shows the server in 'resolution' status way before the 3 minute 'hold valid' has passed when i simply disconnect the network of the server running the Unbound-DNS server. Though i guess that is less important that dns working at all in the first place.. If any additional information is needed please let me know :). Can you/someone take a look? Thanks in advance. p.s. i think i read something about a 'vtest' that can test the haproxy DNS functionality, if you have a example that does this i would be happy to provide a vtest with a reproduction of the issue though i guess it will be kinda 'slow' if it needs to test for hold valid timings.. Regards, PiBa-NL (Pieter) haproxy config: resolvers globalresolvers nameserver pfs_routerbox 192.168.0.18:53 resolve_retries 3 timeout retry 200 hold valid 3m hold nx 10s hold other 15s hold refused 20s hold timeout 25s hold obsolete 30s timeout resolve 5s frontend nu_nl bind 192.168.0.19:433 name 192.168.0.19:433 ssl crt-list /var/etc/haproxy/nu_nl.crt_list mode http log global option http-keep-alive timeout client 3 use_backend nu.nl_ipvANY backend nu.nl_ipvANY mode http id 2113 log global timeout connect 3 timeout server 3 retries 3 option httpchk GET / HTTP/1.0\r\nHost:\ nu.nl\r\nAccept:\ */* server nu_nl nu.nl:443 id 2114 ssl check inter 1 verify none resolvers globalresolvers check-sni nu.nl resolve-prefer ipv4 haproxy_socket.sh show resolvers Resolvers section globalresolvers nameserver pfs_routerbox: sent: 216 snd_error: 0 valid: 0 update: 0 cname: 0 cname_error: 0 any_err: 108 nx: 0 timeout: 0 refused: 0 other: 0 invalid: 108 too_big: 0 truncated: 0 outdated: 0 haproxy -vv HA-Proxy version 2.2-dev0-13a9232 2020/01/22 - https://haproxy.org/ Status: development branch - not safe for use in production. Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open Build options : TARGET = freebsd CPU = generic CC = cc CFLAGS = -pipe -g -fstack-protector -fno-strict-aliasing -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -fno-strict-overflow -Wno-null-dereference -Wno-unused-label -Wno-unused-parameter -Wno-sign-compare -Wno-ignored-qualifiers -Wno-unused-command-line-argument -Wno-missing-field-initializers -Wno-address-of-packed-member -DFREEBSD_PORTS -DFREEBSD_PORTS OPTIONS = USE_PCRE=1 USE_PCRE_JIT=1 USE_REGPARM=1 USE_STATIC_PCRE=1 USE_GETADDRINFO=1 USE_OPENSSL=1 USE_LUA=1 USE_ACCEPT4=1 USE_ZLIB=1 Feature list : -EPOLL +KQUEUE -MY_EPOLL -MY_SPLICE -NETFILTER +PCRE +PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +REGPARM +STATIC_PCRE -STATIC_PCRE2 +TPROXY -LINUX_TPROXY -LINUX_SPLICE +LIBCRYPT -CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL +LUA -FUTEX +ACCEPT4 -MY_ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY -TFO -NS -DL -RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER -PRCTL -THREAD_DUMP -EVPORTS Default settings : bufsize = 16384, maxrewrite = 1024, maxpollevents = 200 Built with multi-threading support (MAX_THREADS=64, default=2). Built with OpenSSL version : OpenSSL 1.1.1a-freebsd 20 Nov 2018 Running on OpenSSL version
haproxy transparent + keepalived + squid = router?
Hello, I 'm using for many years an explicit web proxy solution based on HAProxy in transparent mode in combination with a pair of linux load balancers (keepalived) and some Squid servers behind it. The Squid servers have the VRRP IP address as default gateway. All users have defined in browser a PAC file that contains the VRRP IP and the port 3128.All squid proxies behind this solution are now seeing the real client IP and this helps me to identify and define web policies.(squidguard)I run SSL inspection on Squid, having a root authority pushed via GPO. For every site that needs to be accessed directly without going via proxy, I have defined a SNAT rule in firewall and a static exception in PAC file for direct outbound Internet access. I'd like to take this solution to a higher level and make a complete transparent web proxy solution without being necessary to define a PAC file in browser. In order to do that, I want to make the routing/ filtering directly on HAProxy servers. I've configured a PBR to send the traffic from local PCs for ports 80 and 443 to VRRP IP. I see now all traffic from clients on HAProxy servers. this is part of haproxy config frontend fe_frontend_pool_proxy_3128 timeout client 30m mode tcp bind 172.17.232.232:3128 transparent # VRRP IP default_backend bk_pool_proxy_3128 backend bk_pool_proxy_3128 timeout server 30m timeout connect 5s mode tcp balance leastconn stick-table type ip size 20k stick on src default-server inter 5s fall 3 rise 2 on-marked-down shutdown-sessions source 0.0.0.0 usesrc clientip server proxy1 172.17.232.229:3128 check port 3128 inter 3s rise 3 fall 3 server proxy2 172.17.232.230:3128 check port 3128 inter 3s rise 3 fall 3 And now the question comes: Is there a way to redirect the incoming clients traffic to 172.17.232.232:3128 and all of that without affecting the web traffic from clients point of view? Any help is highly appreciated. Thanks in advance, --Marius M
Hey
I hope you can find time to read this over, I want to share some very significant information that's been going throughout the internet relating to our future well being. We are moving towards a future of a one world cashless money society in which we will be mandated to have an RFID chip implanted in our body. This chip will contain all of our personal information and we will lose our privacy due to the tracking technology. More importantly, did you hear that this was prophesied about two-thousand years ago by a very well known person named Jesus? How could this be? Keep reading... This could be the most important thing you will ever read. ..."Also he (the false prophet who deceives many be his miracles) forces everyone — great and small, rich and poor, free and slave — to receive a mark on his right hand or on his forehead preventing anyone from buying or selling unless he has the mark, that is, the name of the beast or the number of its name. This is where wisdom is needed; those who understand should count the number of the beast, for it is the number of a person, and its number is 666" (Revelation 13:16-18 CJB) Speaking on the final times, this can only be referring to a cashless society, which has yet to occur, but we are on the horizon of. How come? Otherwise we could still buy or sell without receiving the mark between one another if physical money was still valid. It logically deduces itself to this end. The mark can't be something spiritual, because the word references two separate physical spots. If it was spiritual, the text would only conclude one place. This is just the beginning. It is astonishing how on the nail the scriptures are with respect to this RFID chip. These are notes from a man named Carl Sanders who labored with a group of engineers to help develop the RFID chip in the 1900's. Mr. Carl Sanders sat in seventeen New World Order conferences with heads-of-state officials such as Henry Kissinger and Bob Gates of the CIA to discuss plans on how to bring forth this one-world system. The US government commissioned Mr. Sanders to invent a microchip for identifying and controlling the peoples of the nations-a microchip that might be placed underneath the skin with a hypodermic needle(a quick, convenient procedure that would be gradually received by society). Mr. Sanders, along with a crew of engineers behind him, with US grant monies provided by tax dollars, took on this project and produced a chip which is powered by a lithium battery, rechargeable via the temperature changes in our skin. Without having knowledge of the biblical scriptures (Carl was not a Christian at the time), these engineers spent one-and-a-half-million dollars gathering information on the best and most convenient place to have the chip placed below the skin. These researchers observed that the forehead and the back of the hand(the two spots Revelation says the mark will be placed) aren't just the most convenient places, but are additionally the only viable spots for constant, consistent temperature changes in the skin to recharge the lithium battery. The chip is approximately seven millimeters in length, .75 millimeters in diameter, about the size of a grain of rice. It's capable of storing many pages of information about you. All of your basic data, work data, crime history, health history, and financial data may be saved on this chip. Mr. Sanders believes that this chip, which he regretfully helped engineer, is the "mark" spoken about in Revelation 13:16-18. The Greek word for "mark" is "charagma," which is defined as a "scratch or etching." It is also fascinating to be aware that the number 666 is a word in the original Greek. This word being "chi xi stigma," with the end word, "stigma," additionally meaning "to stick or prick. Carl believes that is alluding to the usage of a hypodermic needle being poked into the human flesh to insert the chip." Brother Sanders spoke with a doctor asking what would happen if the lithium contained within the chip was exposed in the human body. The physician answered by saying a horrible sore would arise in that location. Here is what the book of Revelation says: "And the first went and poured out his bowl on the earth; and there came an evil and grievous sore upon the men that had the mark of the beast, and those who worshipped its image" (Revelation 16:2 DARBY). The holy scriptures tell us that we will not be able to buy or sell without accepting the mark of the beast, or the number of its name. Which is the number of the beast, 666. Revelation 13:18 instructs us to count the number 666. How can we count 666? This is where it all tops off. Counting the number 666 has been long debated all throughout the centuries, but has finally been unveiled in these final times by the revelation of God. What I will show you establishes itself with the holy scriptures the true interpretation to count six-six-six. Throughout God's Holy Scriptures, God uses the number 3 for confirmation.
