[stunnel-users] "Reverse" tunneling with stunnel.
C. Petro
petro at cpetro.us
Fri Jul 20 06:02:16 CEST 2018
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 <roam at ringlet.net> 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} pp at storpool.com
> PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
> Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20180719/4ba336c8/attachment.html>
More information about the stunnel-users
mailing list