RE: Missing SRV cookie
Epiphany! I was conflating the stick table with peers - thinking it was required in order to not lose a connection if one of the HAProxy servers failed. As it turns out, I can't "stick on src" as the users in the client's data center will all present with the identical NAT address to the HAProxy servers. So I have to use the cookies. I do find it weird that some machines would see the SRV cookie and some not. If I delete the following lines, will my users lose their connection if one of the HAProxy servers fail (the HAProxy servers are protected by DNS failover)? stick-table type ip size 20k peers mypeers stick on src Or does the peers section mitigate that? peers mypeers # include hap_servers-haproxy declarations peer ip-10-241-1-140 10.241.1.140:1024 peer ip-10-241-1-237 10.241.1.237:1024 -Original Message- From: Cyril Bonté Sent: Monday, July 23, 2018 3:31 PM To: Norman Branitsky Cc: haproxy Subject: Re: Missing SRV cookie Hi Norman, Le 23/07/2018 à 18:36, Norman Branitsky a écrit : > My client's environment had 3 HAProxy servers. > > Due to a routing issue, my client's users could only see the old > HAProxy > 1.5 server when connecting from their data center. > They could not see the 2 new HAProxy 1.7 servers. > > The routing issue was resolved last week and they could now see the 2 > new HAProxy servers, as well the old server. > > They started getting quick disconnects from their Java application - > > the SEVERE error indicated that they had arrived at the wrong server > and had no current session. > [...] > New HAProxy servers configuration: > > backend ssl_backend-vr > balance roundrobin > stick-table type ip size 20k peers mypeers > stick on src Here you are using stick tables for session persistence. > [...] > cookie SRV insert indirect nocache httponly secure > server i-067c94ded1c8e212c 10.241.1.138:9001 check cookie > i-067c94ded1c8e212c > server i-07035eca525e56235 10.241.1.133:9001 check cookie > i-07035eca525e56235 But here, you are using cookies for the same purpose. > I realized that the cookie mechanism was different so I shut down the > old HAProxy server and the problem appeared to be resolved. > > This morning that client is complaining that the problem has returned > - disconnects resulting in the user being kicked out to the login screen. > > Checking with multiple browsers, I can see both the old JSESSIONID > cookie (with the machine name appended) and the new SRV cookie. > > Checking with multiple browsers, my colleagues can *NOT* see the new > SRV cookie from any browser in this office - > > but they can see the SRV cookie when browsing from a virtual PC in our > Atlanta data center! > Even more puzzling, though my client cannot see the SRV cookie (either > in the F12 cookies sent list, or in the browser's cookies folder) he > *never* experiences an unexpected disconnect. > > Suggestions, please? You have to make a choice, either you use stick tables, either you use cookies, but don't mix both otherwise you'll have the situation you are describing. -- Cyril Bonté
Re: Missing SRV cookie
Hi Norman, Le 23/07/2018 à 18:36, Norman Branitsky a écrit : My client’s environment had 3 HAProxy servers. Due to a routing issue, my client’s users could only see the old HAProxy 1.5 server when connecting from their data center. They could not see the 2 new HAProxy 1.7 servers. The routing issue was resolved last week and they could now see the 2 new HAProxy servers, as well the old server. They started getting quick disconnects from their Java application – the SEVERE error indicated that they had arrived at the wrong server and had no current session. [...] New HAProxy servers configuration: backend ssl_backend-vr balance roundrobin stick-table type ip size 20k peers mypeers stick on src Here you are using stick tables for session persistence. [...] cookie SRV insert indirect nocache httponly secure server i-067c94ded1c8e212c 10.241.1.138:9001 check cookie i-067c94ded1c8e212c server i-07035eca525e56235 10.241.1.133:9001 check cookie i-07035eca525e56235 But here, you are using cookies for the same purpose. I realized that the cookie mechanism was different so I shut down the old HAProxy server and the problem appeared to be resolved. This morning that client is complaining that the problem has returned – disconnects resulting in the user being kicked out to the login screen. Checking with multiple browsers, I can see both the old JSESSIONID cookie (with the machine name appended) and the new SRV cookie. Checking with multiple browsers, my colleagues can *NOT* see the new SRV cookie from any browser in this office – but they can see the SRV cookie when browsing from a virtual PC in our Atlanta data center! Even more puzzling, though my client cannot see the SRV cookie (either in the F12 cookies sent list, or in the browser’s cookies folder) he *never* experiences an unexpected disconnect. Suggestions, please? You have to make a choice, either you use stick tables, either you use cookies, but don't mix both otherwise you'll have the situation you are describing. -- Cyril Bonté
Missing SRV cookie
My client's environment had 3 HAProxy servers.
Due to a routing issue, my client's users could only see the old HAProxy 1.5
server when connecting from their data center.
They could not see the 2 new HAProxy 1.7 servers.
The routing issue was resolved last week and they could now see the 2 new
HAProxy servers, as well the old server.
They started getting quick disconnects from their Java application -
the SEVERE error indicated that they had arrived at the wrong server and had no
current session.
Old HAProxy server configuration:
backend ssl_backend-vr
balance roundrobin
option httpchk GET /le5/about.txt
http-check disable-on-404
http-request allow if { src -f /etc/CONFIG/haproxy/whitelist.lst } || {
ssl_c_used }
http-request deny
appsession JSESSIONID len 52 timeout 3h
acl path_root path /
redirect location /le5/ if path_root
# include ssl_servers-vr declarations
server i-067c94ded1c8e212c 10.241.1.138:9001 check
server i-07035eca525e56235 10.241.1.133:9001 check
New HAProxy servers configuration:
backend ssl_backend-vr
balance roundrobin
stick-table type ip size 20k peers mypeers
stick on src
option httpchk GET /le5/about.txt
http-check disable-on-404
http-request allow if { src -f /etc/CONFIG/haproxy/whitelist.lst } || {
ssl_c_used }
http-request deny
cookie SRV insert indirect nocache httponly secure
acl path_root path /
redirect location /le5/ if path_root
# include ssl_servers-vr declarations
server i-067c94ded1c8e212c 10.241.1.138:9001 check cookie
i-067c94ded1c8e212c
server i-07035eca525e56235 10.241.1.133:9001 check cookie
i-07035eca525e56235
I realized that the cookie mechanism was different so I shut down the old
HAProxy server and the problem appeared to be resolved.
This morning that client is complaining that the problem has returned -
disconnects resulting in the user being kicked out to the login screen.
Checking with multiple browsers, I can see both the old JSESSIONID cookie (with
the machine name appended) and the new SRV cookie.
Checking with multiple browsers, my colleagues can NOT see the new SRV cookie
from any browser in this office -
but they can see the SRV cookie when browsing from a virtual PC in our Atlanta
data center!
Even more puzzling, though my client cannot see the SRV cookie (either in the
F12 cookies sent list, or in the browser's cookies folder)
he never experiences an unexpected disconnect.
Suggestions, please?
