- stunnel-users - stunnel.org

Re: [stunnel-users] Possible to verify client certificate BUT ignore expiration-date?
by Eric Eberhard 14 May '19

14 May '19

Use openssl to make a private cert? E -----Original Message----- From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Christopher Schultz Sent: Monday, May 13, 2019 2:28 PM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] Possible to verify client certificate BUT ignore expiration-date? All, Does anyone know if it is possible to perform all other verification of a client certificate EXCEPT allow the certificate to have expired? We have a vendor whose certificate has expired, and we want to allow their old certificate to work while they chase their tails trying to figure out the best way to re-issue a new cert for us. *eyeroll* Is it possible? Thanks, -chris

2 1

Re: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug?
by Eric Eberhard 14 May '19

14 May '19

Yes. Use inetd (or equivalent). Making an independent server work is difficult due to the problems like you are having. Inetd is in many O/S included and essential, others available. It always works. Always. Yes, there is a tiny amount of overhead for making connections. On an ancient AIX IBM I manage 2-4 million XML documents exchanged per day with no problems, all with inetd. Try it – save yourself some misery. Or maybe it won’t help at all except to add information :) E From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Martin Got Sent: Monday, May 13, 2019 9:08 AM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug? I'm trying to make stunnel wrapped ppp connection to achieve bidirectional data transfer over stunnel like shown below. Stunnel client --connect--> Stunnel server pppd client --connect--> pppd server 10.0.1.2 <--data--> 10.0.1.1 OpenBSD 6.4amd64 with Stunnel 5.44 server works till stunnel retries 'exec = pppd' section once stunnel client is reconnected. Also 'exec = pppd' section retries after a short network related communication lag also. Previous 'pppd' child instance haven't killed by stunnel 5.44 before new instance started. So second 'pppd' process started and runs simultaneously with the first 'pppd' and link down. Restarting Stunnel server can clear child 'pppd' processes. So newly reestablished 'pppd' link between 10.0.1.1 <--> 10.0.1.2 endpoints works till next interconnection. Does stunnel server have an option to start only one instance in 'exec' section or what should be done to fix this? Any suggestions highly appreciated. # ps -axu | grep pppd user 43231 0.0 0.0 476 0:00.01 persist lock passive 10.0.1.1:10.0.1.2 local noauth (pppd) user 39187 0.0 0.0 468 0:00.01 persist lock passive 10.0.1.1:10.0.1.2 local noauth (pppd) # tail -n 10 /var/log/daemon pppd[39187] pppd 2.3.5 started by user, uid 0 pppd[43231] Using interface ppp1 pppd[43231] Connect: ppp0 <--> /dev/ttyp2 pppd[43231] Local IP address 10.0.1.1 pppd[43231] Remote IP address 10.0.1.2 pppd[39187] pppd 2.3.5 started by user, uid 0 pppd[39187] Using interface ppp0 pppd[39187] Connect: ppp0 <--> /dev/ttyp5 pppd[39187] Couldn't set interface address: Address 10.0.1.1 or destination 10.0.1.2 already exists Stunnel configurations for server and client: 1. Server's configuration ... foreground = yes debug = 7 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ;socket = l:SO_LINGER=1:60 ; Session cache sessionCacheSize = 100 sessionCacheTimeout = 600 stack = 65536 TIMEOUTbusy = 600 TIMEOUTconnect = 10 TIMEOUTidle = 43200 TIMEOUTclose = 5 [ppp] accept = LOCAL-IP:PORT exec = /usr/sbin/pppd execargs = lock 10.0.1.1:10.0.1.2 local debug noauth ;execargs = lock passive 10.0.1.1:10.0.1.2 local debug noauth pty = yes CAfile = ca.crt cert = server.crt key = server.key verifyChain = yes 2. Stunnel client's configuration ... foreground = yes debug = 7 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ; Session cache sessionCacheSize = 1 sessionCacheTimeout = 600 failover = rr [ppp] client = yes retry = yes connect = REMOTE-IP:PORT exec = /usr/sbin/pppd execargs = defaultroute persist lock passive 10.0.1.2:10.0.1.1 local debug noauth name ppp-client pty = yes CAfile = ca.crt cert = client.crt key = client.key verifyChain = yes checkHost = REMOTE-HOSTNAME ;checkIP = 1.2.3.4

2 1

Re: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug?
by Eric Eberhard 13 May '19

13 May '19

Sounds good. The inetd will handle the dropping of connections just fine ... but the below sounds like it would help even more. E -----Original Message----- From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Peter Pentchev Sent: Monday, May 13, 2019 2:16 PM To: Martin Got <martingot(a)protonmail.com> Cc: stunnel-users(a)stunnel.org Subject: Re: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug? On Mon, May 13, 2019 at 04:07:57PM +0000, Martin Got wrote: > I'm trying to make stunnel wrapped ppp connection to achieve bidirectional data transfer over stunnel like shown below. > > Stunnel client --connect--> Stunnel server > pppd client --connect--> pppd server > 10.0.1.2 <--data--> 10.0.1.1 > > OpenBSD 6.4amd64 with Stunnel 5.44 server works till stunnel retries 'exec = pppd' section once stunnel client is reconnected. Also 'exec = pppd' section retries after a short network related communication lag also. Previous 'pppd' child instance haven't killed by stunnel 5.44 before new instance started. > > So second 'pppd' process started and runs simultaneously with the first 'pppd' and link down. Restarting Stunnel server can clear child 'pppd' processes. So newly reestablished 'pppd' link between 10.0.1.1 <--> 10.0.1.2 endpoints works till next interconnection. > > Does stunnel server have an option to start only one instance in 'exec' section or what should be done to fix this? Unfortunately, stunnel was not designed for your use case; it was designed to allow many different clients to make use of different instances of the same server program, one instance per client. You might try to do something else: if you really only have a single PPP client and you can really guarantee that anything that connects to stunnel must reuse the same connection, you could write a separate program that listens on a TCP port or on a local Unix socket, waits for the first connection, starts an instance of pppd, and then, from that point on, sends all the traffic from this instance to all the connections that it has received, even if a new connection appears before the old one has been torn down. Then you can point stunnel to the local Unix socket of that service, and anything that connects to stunnel will establish a new connection to your service, but it will not matter, since your service will be written in such a way as to send all the traffic to all the connections. So the service should do something like: 1. Create a local Unix socket and start listening on it. 2. Wait for the first connection. 3. Start an instance of pppd (at most one instance shall be running at any point in time) 4. Keep waiting for new connections; accept any and treat them all in the same way. 5. If any data comes from a remote connection, send it to pppd. 6. If any data comes from pppd, send it to *all* the remote connections. 7. If any of the remote connections is closed, well, so be it, good riddance, another one will come along presently (or maybe another one has already come along and has started talking to pppd through this service). 8. If the pppd child process dies, close all the remote connections and go back to step 2. Then you shall only have a problem if there are two "real" connections from different places at the same time - but if I understand your setup correctly, this should not really happen, since it is only you (your laptop or something like that) that connects to the PPP server. If you want, I could try to whip up some simple implementation of such a pseudo-multiplexer. G'luck, Peter -- Peter Pentchev roam(a){ringlet.net,debian.org,FreeBSD.org} pp(a)storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

1 0

Possible to verify client certificate BUT ignore expiration-date?
by Christopher Schultz 13 May '19

13 May '19

All, Does anyone know if it is possible to perform all other verification of a client certificate EXCEPT allow the certificate to have expired? We have a vendor whose certificate has expired, and we want to allow their old certificate to work while they chase their tails trying to figure out the best way to re-issue a new cert for us. *eyeroll* Is it possible? Thanks, -chris

1 0

Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug?
by Martin Got 13 May '19

13 May '19

I'm trying to make stunnel wrapped ppp connection to achieve bidirectional data transfer over stunnel like shown below. Stunnel client --connect--> Stunnel server pppd client --connect--> pppd server 10.0.1.2 <--data--> 10.0.1.1 OpenBSD 6.4amd64 with Stunnel 5.44 server works till stunnel retries 'exec = pppd' section once stunnel client is reconnected. Also 'exec = pppd' section retries after a short network related communication lag also. Previous 'pppd' child instance haven't killed by stunnel 5.44 before new instance started. So second 'pppd' process started and runs simultaneously with the first 'pppd' and link down. Restarting Stunnel server can clear child 'pppd' processes. So newly reestablished 'pppd' link between 10.0.1.1 <--> 10.0.1.2 endpoints works till next interconnection. Does stunnel server have an option to start only one instance in 'exec' section or what should be done to fix this? Any suggestions highly appreciated. # ps -axu | grep pppd user 43231 0.0 0.0 476 0:00.01 persist lock passive 10.0.1.1:10.0.1.2 local noauth (pppd) user 39187 0.0 0.0 468 0:00.01 persist lock passive 10.0.1.1:10.0.1.2 local noauth (pppd) # tail -n 10 /var/log/daemon pppd[39187] pppd 2.3.5 started by user, uid 0 pppd[43231] Using interface ppp1 pppd[43231] Connect: ppp0 <--> /dev/ttyp2 pppd[43231] Local IP address 10.0.1.1 pppd[43231] Remote IP address 10.0.1.2 pppd[39187] pppd 2.3.5 started by user, uid 0 pppd[39187] Using interface ppp0 pppd[39187] Connect: ppp0 <--> /dev/ttyp5 pppd[39187] Couldn't set interface address: Address 10.0.1.1 or destination 10.0.1.2 already exists Stunnel configurations for server and client: 1. Server's configuration ... foreground = yes debug = 7 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ;socket = l:SO_LINGER=1:60 ; Session cache sessionCacheSize = 100 sessionCacheTimeout = 600 stack = 65536 TIMEOUTbusy = 600 TIMEOUTconnect = 10 TIMEOUTidle = 43200 TIMEOUTclose = 5 [ppp] accept = LOCAL-IP:PORT exec = /usr/sbin/pppd execargs = lock 10.0.1.1:10.0.1.2 local debug noauth ;execargs = lock passive 10.0.1.1:10.0.1.2 local debug noauth pty = yes CAfile = ca.crt cert = server.crt key = server.key verifyChain = yes 2. Stunnel client's configuration ... foreground = yes debug = 7 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ; Session cache sessionCacheSize = 1 sessionCacheTimeout = 600 failover = rr [ppp] client = yes retry = yes connect = REMOTE-IP:PORT exec = /usr/sbin/pppd execargs = defaultroute persist lock passive 10.0.1.2:10.0.1.1 local debug noauth name ppp-client pty = yes CAfile = ca.crt cert = client.crt key = client.key verifyChain = yes checkHost = REMOTE-HOSTNAME ;checkIP = 1.2.3.4

2 1

Stunnel for O365 Sending Some Reports but not Others
by David Schmidt 10 May '19

10 May '19

Hello, We needed to reconfigure Stunnel for the SAP Business Objects server that sent email reports from G Suite over to a configuration that sends from an O365 account. The problem is that some of the reports work fine after the reconfiguration, while others always fail and I can't find out why and nothing has changed other than the mail settings. Microsoft doesn't even see the failed reports hitting their servers but when I look at Stunnel it seems like the TLS connection is being established correctly and I can see the connection being established from our firewall logs. I've attached the current O365 config as well as the old GSuite conifg, as well as logs of the debug output I see when I run a report that succeeds versus a report that fails. Can anyone give me an idea as to why Stunnel seems to be working to send out some reports but not others? Thank you, David Schmidt | Administrateur TI / IT Administrator | MTYGroup.com<http://mtygroup.com/> T+1 514-336-8885 Ext 8236 | C+1 514-708-7299 | 8210, route Transcanadienne, St. Laurent, QC, H4S 1M5 [http://mtygroup.com/signature/gif/use_this_left.gif]<http://mtygroup.com> [http://mtygroup.com/signature/gif/use_this_right.gif] <http://mtygroup.com> AVERTISSEMENT CONCERNANT LA CONFIDENTIALIT? / WARNING CONCERNING CONFIDENTIALITY Ce message peut contenir des informations confidentielles, privil?gi?es, et seulement pour ses destinataires. Si vous avez re?u ce message par erreur, veuillez en informer imm?diatement l'exp?diteur par retour de courriel et supprimer cette communication de votre syst?me. This email message may contain information that is confidential, privileged, and for communication only to its intended recipient or recipients. If you have received this message in error, please immediately notify the sender and delete the original message without making a copy.

1 0

Problem with stunnel 5.51
by Carter Browne 08 May '19

08 May '19

I received the following error trying to connect to a Windows host using RDP. I use stunnel as a connection point with secure messages coming in and then forwarded as secure messages going the desired end point. Stunnel is running on all three systems, the originator, the relay, and the destination. I have been using stunnel in this role for many years. As an additional point, 5.51 did work properly in the same role for secure telnet. The part of the log showing the failure is below. Thanks, Carter Before 2019.05.03 15:44:02 LOG5[ui]: stunnel 5.50 on armv7l-unknown-linux-gnueabihf platform 2019.05.03 15:44:02 LOG5[ui]: Compiled with OpenSSL 1.1.1a 20 Nov 2018 2019.05.03 15:44:02 LOG5[ui]: Running with OpenSSL 1.1.1b 26 Feb 2019 2019.05.03 15:44:02 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI 2019.05.03 15:44:02 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf 2019.05.03 15:44:02 LOG5[ui]: UTF-8 byte order mark not detected 2019.05.03 15:44:02 LOG5[ui]: FIPS mode disabled 2019.05.03 15:44:52 LOG5[ui]: Configuration successful 2019.05.03 15:44:52 LOG5[ui]: Switched to chroot directory: /var/run/stunnel/ ... 2019.05.08 08:26:08 LOG5[980]: Service [c13alt-rdp] accepted connection from 192.168.179.22:63218 2019.05.08 08:26:09 LOG5[980]: Certificate accepted at depth=0: C=US, ST=Massachusetts, L=Winchester, O=CBCS, OU=MIS, CN=cbrowne-39, emailAddress=cbrowne(a)cbcs-usa.com 2019.05.08 08:26:09 LOG5[981]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49180 2019.05.08 08:26:09 LOG5[980]: s_connect: connected 127.0.1.127:3389 2019.05.08 08:26:09 LOG5[981]: s_connect: connected 10.251.129.118:8001 2019.05.08 08:26:09 LOG5[981]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44796 2019.05.08 08:26:09 LOG5[980]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49180 2019.05.08 08:26:09 LOG5[981]: Certificate accepted at depth=0: C=US, ST=Massachusetts, L=Winchester, O=CBCS, OU=MIS, CN=cbrowne-13.cbcsnet.local, emailAddress=cbrowne(a)cbcs-usa.com 2019.05.08 08:26:23 LOG5[980]: Connection closed: 1615 byte(s) sent to TLS, 1061 byte(s) sent to socket 2019.05.08 08:26:23 LOG5[981]: Connection closed: 1061 byte(s) sent to TLS, 1615 byte(s) sent to socket 2019.05.08 08:26:23 LOG5[982]: Service [c13alt-rdp] accepted connection from 192.168.179.22:63243 2019.05.08 08:26:23 LOG5[983]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49184 2019.05.08 08:26:23 LOG5[982]: s_connect: connected 127.0.1.127:3389 2019.05.08 08:26:23 LOG5[982]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49184 2019.05.08 08:26:23 LOG5[983]: s_connect: connected 10.251.129.118:8001 2019.05.08 08:26:23 LOG5[983]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44800 After 2019.05.08 12:50:18 LOG5[ui]: stunnel 5.51 on armv7l-unknown-linux-gnueabihf platform 2019.05.08 12:50:18 LOG5[ui]: Compiled/running with OpenSSL 1.1.1b 26 Feb 2019 2019.05.08 12:50:18 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI 2019.05.08 12:50:18 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf 2019.05.08 12:50:18 LOG5[ui]: UTF-8 byte order mark not detected 2019.05.08 12:50:18 LOG5[ui]: FIPS mode disabled 2019.05.08 12:50:42 LOG5[ui]: Configuration successful 2019.05.08 12:51:01 LOG5[2]: Service [c13alt-rdp] accepted connection from 192.168.179.22:64139 2019.05.08 12:51:02 LOG5[2]: Certificate accepted at depth=0: C=US, ST=Massachusetts, L=Winchester, O=CBCS, OU=MIS, CN=cbrowne-39, emailAddress=cbrowne(a)cbcs-usa.com 2019.05.08 12:51:02 LOG5[3]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49330 2019.05.08 12:51:02 LOG5[2]: s_connect: connected 127.0.1.127:3389 2019.05.08 12:51:02 LOG5[2]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49330 2019.05.08 12:51:02 LOG5[3]: s_connect: connected 10.251.129.118:8001 2019.05.08 12:51:02 LOG5[3]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44946 2019.05.08 12:51:02 LOG5[3]: Certificate accepted at depth=0: C=US, ST=Massachusetts, L=Winchester, O=CBCS, OU=MIS, CN=cbrowne-13.cbcsnet.local, emailAddress=cbrowne(a)cbcs-usa.com 2019.05.08 12:51:15 LOG5[2]: Connection closed: 1615 byte(s) sent to TLS, 1061 byte(s) sent to socket 2019.05.08 12:51:15 LOG5[3]: Connection closed: 1061 byte(s) sent to TLS, 1615 byte(s) sent to socket 2019.05.08 12:51:15 LOG5[4]: Service [c13alt-rdp] accepted connection from 192.168.179.22:64141 2019.05.08 12:51:15 LOG5[5]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49334 2019.05.08 12:51:15 LOG5[4]: s_connect: connected 127.0.1.127:3389 2019.05.08 12:51:15 LOG5[4]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49334 2019.05.08 12:51:15 LOG5[5]: s_connect: connected 10.251.129.118:8001 2019.05.08 12:51:15 LOG5[5]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44950 2019.05.08 12:51:18 LOG3[4]: transfer() loop executes not transferring any data 2019.05.08 12:51:18 LOG3[4]: please report the problem to Michal.Trojnara(a)stunnel.org 2019.05.08 12:51:18 LOG3[4]: stunnel 5.51 on armv7l-unknown-linux-gnueabihf platform 2019.05.08 12:51:18 LOG3[4]: Compiled/running with OpenSSL 1.1.1b 26 Feb 2019 2019.05.08 12:51:18 LOG3[4]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI 2019.05.08 12:51:18 LOG3[4]: protocol=TLSv1.2, SSL_pending=0 2019.05.08 12:51:18 LOG3[4]: sock_open_rd=Y, sock_open_wr=Y 2019.05.08 12:51:18 LOG3[4]: SSL_RECEIVED_SHUTDOWN=n, SSL_SENT_SHUTDOWN=n 2019.05.08 12:51:18 LOG3[4]: sock_can_rd=n, sock_can_wr=n 2019.05.08 12:51:18 LOG3[4]: ssl_can_rd=n, ssl_can_wr=n 2019.05.08 12:51:18 LOG3[4]: read_wants_read=Y, read_wants_write=n 2019.05.08 12:51:18 LOG3[4]: write_wants_read=n, write_wants_write=n 2019.05.08 12:51:18 LOG3[4]: shutdown_wants_read=n, shutdown_wants_write=n 2019.05.08 12:51:18 LOG3[4]: socket input buffer: 0 byte(s), TLS input buffer: 0 byte(s) 2019.05.08 12:51:18 LOG5[4]: Connection reset: 2786 byte(s) sent to TLS, 5077 byte(s) sent to socket 2019.05.08 12:51:18 LOG5[5]: Connection closed: 5077 byte(s) sent to TLS, 2989 byte(s) sent to socket 2019.05.08 12:52:03 LOG5[6]: Service [c13alt-rdp] accepted connection from 192.168.179.22:64144 2019.05.08 12:52:03 LOG5[6]: s_connect: connected 127.0.1.127:3389 2019.05.08 12:52:03 LOG5[6]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49340 2019.05.08 12:52:03 LOG5[7]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49340 2019.05.08 12:52:03 LOG5[7]: s_connect: connected 10.251.129.118:8001 2019.05.08 12:52:03 LOG5[7]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44956 2019.05.08 12:52:14 LOG5[6]: Connection closed: 1615 byte(s) sent to TLS, 1061 byte(s) sent to socket 2019.05.08 12:52:14 LOG5[7]: Connection closed: 1061 byte(s) sent to TLS, 1615 byte(s) sent to socket 2019.05.08 12:52:14 LOG5[8]: Service [c13alt-rdp] accepted connection from 192.168.179.22:64147 2019.05.08 12:52:14 LOG5[9]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49344 2019.05.08 12:52:14 LOG5[9]: s_connect: connected 10.251.129.118:8001 2019.05.08 12:52:14 LOG5[9]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44960 2019.05.08 12:52:14 LOG5[8]: s_connect: connected 127.0.1.127:3389 2019.05.08 12:52:14 LOG5[8]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49344 2019.05.08 12:52:16 LOG3[8]: transfer() loop executes not transferring any data 2019.05.08 12:52:16 LOG3[8]: please report the problem to Michal.Trojnara(a)stunnel.org

2 2

Automatic stunnel-client reconnect and keep initial session
by Martin Got 01 May '19

01 May '19

Which commands to stunnel can perform keeping session ID in case of stunnel-client reconnection? Do I add commands to both stunnel-client and stunnel-server to keep the initial session?

1 0

Keep initial session-ID when stunnel-client reconnect to a stunnel-server
by Martin Got 01 May '19

01 May '19

Trying to establish link using pppd connection overlapped into stunnel 5.44. Server runs on OpenBSD 6.4, client uses the same stunnel and OS versions. From the client's side I have to reconnect to stunnel-server in case of Internet link is dropped. And expecting that pppd session is kept by stunnel over reconnections possible. But stunnel-server runs another pppd instance when stunnel-client reconnects. After reconnection in system processes I see two pppd processes (as shows below), and pppd link has no pings after it. # ps -aux | grep pppd user 45359 0.0 0.0 440 1672 ?? I Tue11PM 0:00.01 lock passive 10.0.1.1:10.0.1.2 local debug noauth (pppd) user 1156 0.0 0.0 321 1210 ?? I Tue12PM 0:00.01 lock passive 10.0.1.1:10.0.1.2 local debug noauth (pppd) 1. The question is how to keep initial session established by stunnel-client and do not run second pppd process by stunnel-server? 2. May I keep session by cache-ID on the client's side only or do I need to do it on both client and server? Can it help not to run another pppd process? Both server config and client config parts are below: # cat /etc/stunnel/stunnel-server.conf ... [ppp] ;SERVER accept 1.2.3.4:443 exec = /usr/sbin/pppd execargs = lock passive 10.0.1.1:10.0.1.2 local debug noauth pty = yes CAfile = ca.crt cert = server.crt key = server.key verifyChain = yes TIMEOUTclose = 0 ... # cat /etc/stunnel/stunnel-client.conf ... [ppp] ;CLIENT client = yes retry = yes connect = 1.2.3.4:443 exec = /usr/sbin/pppd execargs = persist lock 10.0.1.2:10.0.1.1 local debug noauth name ppp-client pty = yes CAfile = ca.crt cert = client.crt key = client.key verifyChain = yes checkHost = hostname ;checkIP = 1.2.3.4 ... Thank you for answer in advance.

1 0

Re: [stunnel-users] illegal instruction crash 5.50 Debian/Stretch
by Michal Trojnara 29 Apr '19

29 Apr '19

On 24.04.2019 16:06, Florian Lohoff wrote: > with the stunnel4 in Debian/Stretch i am experiencing pretty regular > crashes with illegal instruction. Version is 5.50. > In Bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880659 > you can see the drill down to a Lock beeing unlocked although > not locked. When i look at the code its some usage of openssl > primitives. (Unlock happens in openssl code) > I had a quick look at the changelog and this: > "Service threads are terminated before OpenSSL cleanup to prevent occasional stunnel crashes at shutdown." > sounds a bit like the issue i am experiencing. > Can you confirm this? Yes, I do confirm this is the issue described in the Debian bug #880659. It wasn't a simple coding error, but rather a design flaw introduced in version 3.0 that took 20 years to identify and fix. Before version 5.18, released almost 4 years ago, the shutdown race condition mostly manifested itself while terminating stunnel under extremely heavy load, such as stress testing. The probability has increased with the introduction of periodic DH parameter regeneration in version 5.18. I didn't test it, but I suspect some changes in the OpenSSL internals may have also cause the crashes to only surface fairly recently, and not 20 years ago. The fix itself involves a major redesign of the stunnel threading subsystem, so I made a beta version and I'd appreciate your help with testing it: https://www.stunnel.org/downloads/beta/stunnel-5.54b2.tar.gz Best regards, Mike

2 1