Strange behaviour, have to restart router to get https back

R

raldnor

New Member
#1
#1
Hi,

I am running 1.4.3 of Openlitespeed and noticed some strange behaviour which I don't know how to debug:

I run a number of https virtual hosts which are all proxies to other services. This setup runs well for some hours after which I cannot seem to reach the https server anymore. Only a reboot of the router in front of it, or restarting the gateway interface on the router resolves the situation (for another few hours). I cannot find any relating messages in the syslog of the router or in the syslog of the host running OLS. The only messages OLS gives (though not direcly related in time with new requests) are the ones about 'sess get failed to find ssl session'.
With other webservers I had previously running in a comparable setup I did not encounter this behaviour.
Any ideas what might be the culprit or how to find the cause?

Obviously at the moment I am not able to use this great piece of software in production use :).


Thanks :D
 
Last edited:
R

raldnor

New Member
#2
#2
More info:
It only happens for computers within my internal LAN, external systems can reach the server and view pages.
Connections seem to stall, I can connect to the server, but nothing happens when trying to request the page. See the debug below:

Code: 
[root@xxxxxx ~]# openssl s_client -connect mail.xxxxxxx.com:443
CONNECTED(00000003)
depth=0 C = x, ST = x, L = x, O = x, OU = x, CN = *.xxxxxxx.com, emailAddress = -
verify error:num=18:self signed certificate
verify return:1
depth=0 C = x, ST = x, L = x, O = x, OU = x, CN = *.xxxxxxxx.com, emailAddress = -
verify return:1
---
Certificate chain
 0 s:/C=x/ST=x/L=x/O=x/OU=x/CN=*.xxxxxxxxx.com/emailAddress=-
  i:/C=x/ST=x/L=x/O=x/OU=x/CN=*.xxxxxxxxx.com/emailAddress=-
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDpTCCAo2gAwIBAgIJAOgsXUSNmDPEMA0GCSqGSIb3DQEBBQUAMGkxCzAJBgNV
BAYTAkhMMQowCAYDVQQIDAEtMQowCAYDVQQHDAEtMQowCAYDVQQKDAEtMQowCAYD
VQQLDAEtMRgwFgYDVQQDDA8qLmhlbGx3aG9yZS5jb20xEDAOBgkqhkiG9w0BCQEW
AS0wHhcNMTUwMTA3MjE0MjQwWhcNMjUwMTA0MjE0MjQwWjBpMQswCQYDVQQGEwJI
TDEKMAgGA1UECAwBLTEKMAgGA1UEBwwBLTEKMAgGA1UECgwBLTEKMAgGA1UECwwB
LTEYMBYGA1UEAwwPKi5oZWxsd2hvcmUuY29tMRAwDgYJKoZIhvcNAQkBFgEtMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq3PL25PoVQhLNC/zF15aOH8t
1Z3gz3vvvAb1fvzAsDiGhI2Qyg8E9D0eLrwXa9y+DQkwE2SnmKLEHIL2zZDSlUAP
/gn7yQaBeGiCY1V0gsZsPR1DyJCBAHh1CrQRqyRnXoKm6GWMWk6JZc65lKCPr5Ag
BRG1P75PbAVdr2VzHEezeyiJn4gHjcUkvgfPbteKy+LGV8SMinFgUUkS7UqLN8Zu
lMUSPZADQ9peEG++55uAcg4O7VYeW7u1uvdwxARwXxhc407JxYr8vWZzrtGHhoOi
fznE+ZlobjOhiZVs3JkCDqtxpzthrz00ORmNYl8UaXwKkzSJBDet6h9cbzn86wID
xxxxo1AwTjAdBgNVHQ4EFgQUhqE0s2Ep51oIUBIGawxUrbhaqOYwHwYDVR0jBBgw
FoAUhqE0s2Ep51oIUBIGawxUrbhaqOYwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B
AQUFAAOCAQEAWeOV6TyuaebRRTup7tMuh4aXtg2YG9DWLm7zIWq8m1dDgsS3Zbgg
Za5/xxxxSP92v8zI+ygQEaC3+vF8jfTuL2HabnXm7x3UpDW2593t7z9f+NbtmStf
QJjHKFYrbsZ8MCm00kxsm9tOTQdTdXJPU/jUfFnYGW7KnLC5TOWRGtfEosUOTA3M
PyC+zqRrRqXBlSrChM3jF/n+Di6YEUD/+eDrSdGc58hk3WIieBdRhXcIo+O4nRSr
q0waJeGe/S8Q9abAHGxfD7dCXFAxvFK9DqgI+IiGsBhs598UZf/ofB3GHNgS6mLw
0JKhnWPXuci25XyRcYwOV1VsEwGMx4o1uA==
-----END CERTIFICATE-----
subject=/C=x/ST=x/L=x/O=x/OU=x/CN=*.xxxxxxxx.com/emailAddress=-
issuer=/C=x/ST=x/L=x/O=x/OU=x/CN=*.xxxxxxxx.com/emailAddress=-
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 1489 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
  Protocol  : TLSv1.2
  Cipher  : ECDHE-RSA-AES128-SHA256
  Session-ID: 8DE6174AA3BED58794D1C32A6DAF97CADE4025EDB2530EAB22E50D283E813DB1
  Session-ID-ctx:
  Master-Key: 5C6E4E1340948608F7702128C5EA28104945054B0F90C81B14154E08775806A54F7FD0D141C9D83158DC73D402713ABA
  Key-Arg  : None
  Krb5 Principal: None
  PSK identity: None
  PSK identity hint: None
  Start Time: 1421065984
  Timeout  : 300 (sec)
  Verify return code: 18 (self signed certificate)
---
HEAD / HTTP/1.0
After the HEAD request nothing happens, not even an timeout.

P.s. it might be this needs to be in the bugs section, but I am not sure yet.
 
R

raldnor

New Member
#3
#3
Update:
I now changed the backend to https (the proxy also serves over https) and it seems to work now. It must have something to do with the reverse proxy implementation. Perhaps it's in the rewriting of headers, because that's the difference with my former webserver software where I could modify the server replies.
 
R

raldnor

New Member
#4
#4
Update:
I get ajax-timeouts in my applications immediatelly after starting the web app. Even though the request timeout in OLS has been set to 120 secs.
 
R

raldnor

New Member
#7
#7
Hi LSMichael,

Thanks for your response! Both my modem and router have upnp disabled. I moved the admin port to another port, but the same problems remain. To me it seems the reverse proxy functionality is broken somewhere since static and php pages work fine.
Anything I can do to help debug?
 
lsmichael

lsmichael

Active Member
#8
#8
Howdy Raldnor,

Just wanted to touch base. I agree that it seems to be a bug. I've added it to our bug list.

We may need you to make further changes when we're addressing this bug. I'll be in touch when we're working on it.

Michael
 
You must log in or register to reply here.
Top