HaProxy with 2 websites



  • I've been trying figure out how to deal with this for a few days and I can't figure it out.

    I have 2 websites hosted on my home server, both have ssl certificates installed on my server.

    one of the website is using port 443 and the other is 4234 (virtual host) on my server.

    I can get one of the website to work if i use tcp, the other methods http/https offloading and ssl/https don't seem to working. If I however add another website to tcp then my seconds website starts using the first website certificate and it come up an ssl mismatch error.



  • @slim2016
    Configure a backend for each, and use mode ssl/tcp and configure the proper acl's the SNI name to match and then the action use-backend to use the desired backend.
    If it aint working please post your haproxy.cfg (from bottom of settings tab) and probably i can spot where the issue is.

    p.s. if you dont want to use 'offloading' then don't use certificates in haproxy frontend, and do NOT select SSL-encryption checkbox on the server configuration, but do still use ssl-checks.



  • Thanks, your advise worked. This is my current config, if any advice in improving it then please let me know, thanks.

    global
    	maxconn			1000
    	log			/var/run/log	local0	info
    	stats socket /tmp/haproxy.socket level admin  expose-fd listeners
    	uid			80
    	gid			80
    	nbproc			1
    	nbthread			1
    	hard-stop-after		15m
    	chroot				/tmp/haproxy_chroot
    	daemon
    	tune.ssl.default-dh-param	2048
    	server-state-file /tmp/haproxy_server_state
    
    listen HAProxyLocalStats
    	bind 127.0.0.1:3976 name localstats
    	mode http
    	stats enable
    	stats admin if TRUE
    	stats show-legends
    	stats uri /haproxy/haproxy_stats.php?haproxystats=1
    	timeout client 5000
    	timeout connect 5000
    	timeout server 5000
    
    frontend frontend-https
    	bind			88.88.88.88:443 name 88.88.88.88:443   
    	mode			tcp
    	log			global
    	timeout client		30000
    	tcp-request inspect-delay	5s
    	acl			acl1	req.ssl_sni -i site1.co.uk
    	acl			acl2	req.ssl_sni -i site2.co.uk
    	tcp-request content accept if { req.ssl_hello_type 1 }
    	use_backend backend1_ipvANY  if  acl1 
    	use_backend backend2_ipvANY  if  acl2
    
    frontend http-https
    	bind			88.88.88.88:80 name 88.88.88.88:80   
    	mode			http
    	log			global
    	option			http-keep-alive
    	timeout client		30000
    	http-request redirect scheme https 
    
    backend backend1_ipvANY
    	mode			tcp
    	id			102
    	log			global
    	timeout connect		30000
    	timeout server		30000
    	retries			3
    	server			backend1 172.217.5.35:443 id 103 check inter 1000  
    
    backend backend2_ipvANY
    	mode			tcp
    	id			101
    	log			global
    	timeout connect		30000
    	timeout server		30000
    	retries			3
    	server			backend2 172.217.5.35:4172 id 104 check inter 1000
    	
    	#port 4172 is SSL
    

  • LAYER 8 Rebel Alliance



  • @Rico

    Thanks, looks interesting, will have to go through the video and take some notes when I have a bit more time.



  • @slim2016
    Few things.

    • health-checks , currently only a Layer 4 check is performed (if the connection is accepted on TCP level.) , if possible try and make that a http-check to verify that Layer7 actually provides a expected/valid http response.
    • your servers are using IP's in the 172.217 range, are those the actual IP's you use? Or just replaced to anonymize the config a bit before posting? You are aware that these are not supposed to be used on private networks right? If they are truly your public-ip's of the server its okay, if you use this network on your private lan, then you might get into issues using certain webservices that really 'own' these public ip's. private IPv4 space is defined as: 192.168/16 , 172.16/12 , 10/8 where the 172.16/12 does not include 172.217.x.x.


  • @PiBa

    i will change to http from basic, thanks for the advice.

    I was using fake ip's - even my fake ip's were wrong LOL, nice catch.


  • LAYER 8 Rebel Alliance

    You don't need to fake RFC1918 addresses when posting, anyone can use them anyway. 😁

    -Rico



  • @Rico

    Good point.


Log in to reply