Configuration of SSL offloading

0

 Hi,

I am currently playing a little bit around with the Free Load Balancer regaridng to use it as reverse proxy, and currently I have a problem that SSL offloading does not work as expected. Situation:

I want to configure a https connection on the virtual service 10.1.1.10:443 to a nextcloud docker instance listening on 10.1.1.50:80 if the domainname fits mydomain.com. A lets encrypt SSL certificate is installed on the load master. However I am not able to access the nextcloud instance if using ssl. Look at the following screenshot of my configuration:

I have created a rule that if the domainname matches mydomain.com it´s redirected to 10.1.1.50. It is the same rule as using in the virtual service for http.

What am I doing wrong?

Thanks,

Florian

3 comments

Avatar
0
Tony Vaughan

Hello,

you may require Server Name Indication (SNI)
more info on this can be found here
https://support.kemptechnologies.com/hc/en-us/articles/201814885-Server-Name-Indication-SNI-)

your clients may be trying to connect using an unsupported protocol such as SSLv3 or TLS 1.0
can you enable both of these for testing
they also may be using weaker ciphers, can you change this the cipher set to default?

or if you take a TCPdump from the LoadMaster you can see the protocol and ciphers being used during the SSL handshake
 
the option for TCPdump can be found under
System Configuration > System Administration > System Log Files and click Debug Options.
 

Avatar
0
office

Hi,

thank you for your repsonse, SNI is enabled and I have enabled debug options, as you suggested and I am getting the following output:

Dec 11 08:21:53 NTA-LM1 kernel: L7: ffff88006f880a60: maybe got alpn 0
Dec 11 08:21:53 NTA-LM1 kernel: L7: ffff88006f880a60: SSL accept on 10.1.1.10:443 from 192.168.1.27:64502 (0)
Dec 11 08:21:53 NTA-LM1 kernel: L7: ffff88006f880a60: RS 10.1.1.4:80 aconns 0 refcnt 5 weight 1000
Dec 11 08:21:53 NTA-LM1 kernel: L7: ffff88006f880a60: Connecting from 10.1.1.10:50398 to 10.1.1.4:80 NAT
Dec 11 08:22:13 NTA-LM1 kernel: L7: ffff88006f880a60: conn release 7
Dec 11 08:22:13 NTA-LM1 kernel: L7: ffff88006f880a60: maybe got alpn 0
Dec 11 08:22:13 NTA-LM1 kernel: L7: ffff88006f880a60: SSL accept on 10.1.1.10:443 from 192.168.1.27:64505 (0)
Dec 11 08:22:13 NTA-LM1 kernel: L7: ffff88006f880a60: RS 10.1.1.4:80 aconns 0 refcnt 5 weight 1000
Dec 11 08:22:13 NTA-LM1 kernel: L7: ffff88006f880a60: Connecting from 10.1.1.10:27032 to 10.1.1.4:80 NAT
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: Accept on 10.1.1.10:80 from 192.168.1.27:64506 (0)
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: Parse_http_header
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: User-Agent: WebDAVFS/3.0.0 (03008000) Darwin/18.2.0 (x86_64)
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: Parse_http_header: finished
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: request: PROPFIND /remote.php/webdav/
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: RS 10.1.1.50:80 aconns 0 refcnt 3 weight 1000
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: Connecting from 10.1.1.8:22451 to 10.1.1.50:80
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: Connected
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: updating persist 0 1
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: Parse_http_header
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: User-Agent: WebDAVFS/3.0.0 (03008000) Darwin/18.2.0 (x86_64)
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: Parse_http_header: finished
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: add_header Request: PROPFIND /remote.php/webdav/
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: addadd slen = 596 state = 2 ret = 0
Dec 11 08:22:27 NTA-LM1 kernel: L7: ffff880079f18510: http_client_read
Dec 11 08:22:33 NTA-LM1 kernel: L7: ffff880079f18510: Conn: Request 716 ms Response 5004 ms
Dec 11 08:22:33 NTA-LM1 kernel: L7: ffff880079f18510: Conn: client RTT 11394/5746 us min 6704 us
Dec 11 08:22:33 NTA-LM1 kernel: L7: ffff880079f18510: Conn: dest RTT 1666/1555 us min 915 us
Dec 11 08:22:33 NTA-LM1 kernel: L7: ffff880079f18510: conn release 7
Dec 11 08:22:34 NTA-LM1 kernel: L7: ffff88006f880a60: conn release 7
Dec 11 08:22:34 NTA-LM1 kernel: L7: ffff88006f880a60: maybe got alpn 0
Dec 11 08:22:34 NTA-LM1 kernel: L7: ffff88006f880a60: SSL accept on 10.1.1.10:443 from 192.168.1.27:64507 (0)
Dec 11 08:22:34 NTA-LM1 kernel: L7: ffff88006f880a60: RS 10.1.1.4:80 aconns 0 refcnt 5 weight 1000
Dec 11 08:22:34 NTA-LM1 kernel: L7: ffff88006f880a60: Connecting from 10.1.1.10:48924 to 10.1.1.4:80 NAT
Dec 11 08:22:54 NTA-LM1 kernel: L7: ffff88006f880a60: conn release 7
Dec 11 08:22:54 NTA-LM1 kernel: L7: ffff88006f880a60: maybe got alpn 0
Dec 11 08:22:54 NTA-LM1 kernel: L7: ffff88006f880a60: SSL accept on 10.1.1.10:443 from 192.168.1.27:64510 (0)
Dec 11 08:22:54 NTA-LM1 kernel: L7: ffff88006f880a60: RS 10.1.1.4:80 aconns 0 refcnt 5 weight 1000
Dec 11 08:22:54 NTA-LM1 kernel: L7: ffff88006f880a60: Connecting from 10.1.1.10:30049 to 10.1.1.4:80 NAT
Dec 11 08:23:15 NTA-LM1 kernel: L7: ffff88006f880a60: conn release 7

Seams to be a problem with the response from the server, however in port 80 it is working as excepted. I have already changed the destination from nextcloud to another webapplication to ensure that the problem ist not application dependent, even this should not be possible.

Florian

Avatar
0
office

Okay, after I changed "Add the strict transport" to "Add the strict transport security header - include subdomains" it´s working. See attached screenshot for details.

Florian