Thank you for you quick reply, and sorry it's taken me so long to respond back.
Frankly I'm not exactly sure what is going on, or what layer the problem is. I don't think this is a firewall issue--I'm not seeing the connections closed in "minutes", I'm seeing them dropped So I want to connect FROM the indexer TO the DMZ host so the DMZ host can send log data back. Or to put it another way, the *client* opens the connection to the server and the server starts flowing data. But if I have rsyslogd listening on 3002 ( on the Indexer (client) side, then the tunnel never gets initiated, and if I have rsyslogd set up to *send* from the DMZ (server) side I get: 2018.07.19 23:59:41 LOG7[24275:140358448011328]: Service [tunnel_from_10.3.209.52] accepted (FD=3) f rom 10.3.209.52:43042 2018.07.19 23:59:41 LOG7[24275:140358448006912]: Service [tunnel_from_10.3.209.52] started 2018.07.19 23:59:41 LOG7[24275:140358448006912]: Waiting for a libwrap process 2018.07.19 23:59:41 LOG7[24275:140358448006912]: Acquired libwrap process #0 2018.07.19 23:59:41 LOG7[24275:140358448006912]: Releasing libwrap process #0 2018.07.19 23:59:41 LOG7[24275:140358448006912]: Released libwrap process #0 2018.07.19 23:59:41 LOG7[24275:140358448006912]: Service [tunnel_from_10.3.209.52] permitted by libw rap from 10.3.209.52:43042 2018.07.19 23:59:41 LOG5[24275:140358448006912]: Service [tunnel_from_10.3.209.52] accepted connecti on from 10.3.209.52:43042 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): before/accept initialization 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SNI: no virtual services defined 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 read client hello B 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 write server hello A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 write certificate A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 write key exchange A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 write server done A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 flush data 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 read client certificate A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 read client key exchange A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 read certificate verify A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 read finished A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 write session ticket A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 write change cipher spec A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 write finished A 2018.07.19 23:59:41 LOG7[24275:140358448006912]: SSL state (accept): SSLv3 flush data 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 0 items in the session cache 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 0 client connects (SSL_connect()) 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 0 client connects that finished 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 0 client renegotiations requested 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 1 server connects (SSL_accept()) 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 1 server connects that finished 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 0 server renegotiations requested 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 0 session cache hits 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 0 external session cache hits 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 0 session cache misses 2018.07.19 23:59:41 LOG7[24275:140358448006912]: 0 session cache timeouts 2018.07.19 23:59:41 LOG6[24275:140358448006912]: SSL accepted: new session negotiated 2018.07.19 23:59:41 LOG6[24275:140358448006912]: Negotiated protocol version: TLSv1.2 2018.07.19 23:59:41 LOG6[24275:140358448006912]: Negotiated TLSv1/SSLv3 ciphersuite: ECDHE-RSA-RC4-S HA (112-bit encryption) 2018.07.19 23:59:41 LOG6[24275:140358448006912]: Compression: null, expansion: null 2018.07.19 23:59:41 LOG6[24275:140358448006912]: connect_blocking: connecting 127.0.0.1:3000 2018.07.19 23:59:41 LOG7[24275:140358448006912]: connect_blocking: s_poll_wait 127.0.0.1:3000: waiti ng 10 seconds 2018.07.19 23:59:41 LOG3[24275:140358448006912]: connect_blocking: connect 127.0.0.1:3000: Connectio n refused (111) 2018.07.19 23:59:41 LOG5[24275:140358448006912]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket 2018.07.19 23:59:41 LOG7[24275:140358448006912]: Local socket (FD=3) closed 2018.07.19 23:59:41 LOG7[24275:140358448006912]: Service [tunnel_from_10.3.209.52] finished (0 left) so it never has a chance to send. Am I trying to do something that Stunnel just isn't designed for? On Wed, Jul 18, 2018 at 2:43 AM, Peter Pentchev <[email protected]> wrote: > On Tue, Jul 17, 2018 at 10:51:07PM -0600, C. Petro wrote: > > I have a client who is setting up a logging infrastructure involving a > > couple of DMZs forwarding logs into central logging points. > > > > They have to pass compliance audits (SOX, PCI at least) and have some > > rather specific desires in regards to how they want the log traffic to > > move, and which servers *initiate* the connections. > > > > Which is to say they want the internal servers to set up tunnels to the > DMZ > > servers and then the forwarders use that tunnel to deliver logs back. > > > > > > Lemme see if I can ascii art this: > > > > central1----------------------------------dmz1 > > \____________________ / > > _____________________\ _/ > > / \ > > central2----------------------------------dmz2 > > > > Something like that. > > > > Central1=10.10.1.2 > > Central2=10.9.1.2 > > > > DMZ1=172.18.0.5 > > DMZ2=172.20.0.5 > > > > Firewalls are in effect. > > > > I have gotten it set up so that I can initiate a connection FROM Central1 > > to DMZ2. > > > > [Tunnel_to_DMZ2] > > client = yes > > accept = 3002 > > connect = 172.20.0.5:5000 > > > > > > And > > > > [Tunnel_from_Central1] > > accept = 5000 > > connect = 3000 > > > > > > Like I said, I can open a tunnel from Central1 to DMZ2, but can't get > > traffic to pass backwards--I get a message in the log saying the session > is > > closed. > > So you are saying that the connection is established successfully? > (you can check that in the logs of both stunnel instances and also using > e.g. netstat or ss or similar tools on the hosts that should be talking to > each other through the tunnel) > ...but then, some indeterminate time later, one of the hosts tries to send > some data through this connection and gets a connection reset or something > like that? > > If so, this sounds like something I've seen *a lot* with firewalls and > other devices that try to keep track of connections passing through them > (e.g. for NAT and such) - the firewall/NAT/whatever decides that there has > been no traffic on that particular connection for, say, the last 15 > minutes, > so it drops it from its internal state - *obviously* those hosts do not > need > to talk to each other any more, who would ever have a 15-minute pause in > a TCP connection, why would anybody want that? So the next time one of > the hosts tries to send some data, the firewall/NAT/whatever says "hm, > well, > I don't know anything about this connection that you think you have, so, > yeah, no". > > TL;DR: maybe you should check the settings on some of the firewall devices > and see if you can somehow raise the timeouts for inactive connections or > something like that. > > > Is it possible to set stunnel up in a "reverse tunnel" mode--one where > the > > connect is initiated from one end, but the other does most of the message > > passing? > > > > What I am missing? > > Hope the above helps. > > G'luck, > Peter > > -- > Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} [email protected] > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 >
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
