[stunnel-users] Problem using stunnel on Windows 7
Pierre DELAAGE
delaage.pierre at free.fr
Sat Nov 17 16:37:11 CET 2012
Hi Hal,
At least, when NOT ENCRYPTED, there is a strange use of port 7999...
in TCP, there is NO way to specify what port you are using for an
OUTGOING call !
are your apps using in fact UDP ???
stunnel is TCP !
Then, whatever you do, it is NORMAL that your traffic still goes as
usual ....with nothing trough stunnel !
Pierre
Le 17/11/2012 13:28, Hal Hovland a écrit :
> Pierre, thanks for response. I did try 127.0.0.1 with all the local ports
> during my testing. I will, though, re-examine my logic as per your comments.
> Its more than possible too, that I've mixed up the definition of 'accept'
> and 'connect' as used with a server and client - I'm assuming that on the
> client, the 'accept' defines the port used by the underlying program (here,
> the Sender), and on the server, the 'connect' defines the port used by the
> underlying program (here, the Listener)
>
> Drawing a little picture - before the use of stunnel
>
> 192.168.1.9| |192.168.1.158
> | |
> Listener | Network | Sender
> Port|8000 7999|Port
>
>
> After the introduction of stunnel on both machines
>
> Listener | Network | Sender
> ^ | | V
> Port 8000 | | Port 7999 (accept=)
> stunnel | | stunnel
> Port|8001 < < 8001|Port
> |accept= connect=|
>
> [Listener] client=yes
> [sender]
> connect=8000 accept = 7999
> accept=8001 connect = 192.168.1.9:8001
>
> My biggest worry was that no matter what, hovering over either stunnel icon
> both shows '0 session(s) active'. Do they only show as active when encrypted
> communication occurs or when a program is started that uses the relevant
> port?
>
> Regards, Hal
>
> -----Original Message-----
> From: Pierre DELAAGE [mailto:delaage.pierre at free.fr]
> Sent: 17 November 2012 11:31
> To: stunnel-users at stunnel.org; hhovland at btconnect.com
> Subject: Re: [stunnel-users] Problem using stunnel on Windows 7
>
> Hmm, are you sure you are respecting the simple following scheme where the
> encrypted STUNNEL is acting between TWO UNECRYPTED channels ?
>
>
> unencrypted client application ---- unencrypted channel ----> client
> stunnel accepting on PORT-1, connnecting to REMOTE STUNNEL on PORT-2,
>
> ---ENCRYPTED CHANNEL -------> REMOTE STUNNEL listening on PORT-2,
> connecting to a local UNENCRYPTED server on PORT-3 ---> unencrypted
> LOCAL application listening on port 3...
>
> according to your conf files :
> port-1 seems to be 7999,
> port-2 ..8001,
> port-3 : 8000
>
> To my mind the problem may come from the IP ADDRESSES you are using :
>
> your client unencrypted application should connect to CLIENT STUNNEL IP
> (if on the same machine : 127.0.0.1).
> AND NOT ANY MORE to the IP of your original unencrypted server.
>
> On the server side : connect to the IP of the NEW unencrypted
> application location,
> should be...I think...127.0.0.1.
>
> Failing to adapt IP in APPLICATIONS it is NORMAL that the traffic does
> not pass through stunnel.
>
>
> Something else: check firewall on both sides...but I really think you
> just have bad ip configured in your client/server original UNencrypted
> applications...
>
> Regards
> Pierre
>
>
>
>
>
>
> Le 17/11/2012 12:01, Uffe Vedenbrant a écrit :
>> A small tip..
>>
>> Use netstat to see if stunnel actually listens to the port that you have
>> set up. You can also see if you have a working TCP connection between
>> the machines.. I.e. established a stunnel session..
>> You will then both see line with LISTEN flag as well as a line with a
>> ESTABLISHED flag.
>>
>> On windows you also can use the flag "-B" to see which process ( in most
>> cases ) that is using a port.. This requires admin rights..
>> ( right click CMD and select run ad admin )
>>
>> Example
>>
>> CMD> netstat -B -an
>>
>> You will see a list of UDP/TCP listening port as well as established
>> sessions etc.. Look for the ports here..
>>
>> C:\>netstat -B -an
>>
>> Active Connections
>>
>> Proto Local Address Foreign Address State
>> TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
>> RpcSs
>> [svchost.exe]
>> TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
>> Can not obtain ownership information
>> TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING
>> Can not obtain ownership information
>> TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING
>> Can not obtain ownership information
>> TCP 0.0.0.0:8800 0.0.0.0:0 LISTENING
>> Can not obtain ownership information
>> TCP 0.0.0.0:17500 0.0.0.0:0 LISTENING
>> [Dropbox.exe]
>>
>>
>>
>>
>> On 2012-11-17 11:13, Hal Hovland wrote:
>>> Hi Brian, thanks for taking a look. The client .conf uses 7999 and 8001.
> On
>>> the accept side I've tried 7999 and 192.168.1.158:7999 and 0.0.0.0:7999.
>>>
>>>
>>>
>>> I should also say I tried all this with Ncat (same result) and that the
>>> machines have the latest .NET Framework installed, viz., 4.5 - could that
> be
>>> the problem?
>>>
>>>
>>>
>>> Regards, Hal
>>>
>>>
>>>
>>> From: Brian Wilkins [mailto:bwilkins at gmail.com]
>>> Sent: 16 November 2012 23:25
>>> To: Hal Hovland
>>> Cc: stunnel-users at stunnel.org
>>> Subject: Re: [stunnel-users] Problem using stunnel on Windows 7
>>>
>>>
>>>
>>> I didn't see a port setting in the clients stunnel.conf
>>>
>>> On Nov 16, 2012 6:18 PM, "Hal Hovland" <hhovland at btconnect.com> wrote:
>>>
>>> I've spent days googling this and read everything relevant in the
> archives.
>>>
>>>
>>> I'm developing a Windows 7 program that connects to a financial trading
>>> exchange that expects all communication to be SSL'd. Everything I read
> said
>>> that stunnel is the answer because of ease of installation and use. After
> a
>>> day of abortive attempts to link to the exchange, I decided to create a
> much
>>> simpler test environment involving two Windows 7 computers next to each
>>> other here.
>>>
>>>
>>>
>>> One, let's call it Riven-II (192.168.1.9), is set up with a simple
> Listener
>>> program that listens on port 8000. From stunnel's viewpoint this will be
> a
>>> server. The second machine, Lightning (192.168.1.158), has a simple
> Sender
>>> program that sends a text message via port 7999 to Riven-II
>>> (192.168.1.9:8000) - this will be the Client. In the absence of stunnel,
> all
>>> messages sent from Lightning/Sender appears on the window of Listener. So
>>> far so good.
>>>
>>>
>>>
>>> I've downloaded and installed the very latest version (4.54) of stunnel
> on
>>> both machines. On installation I entered the same responses to the
>>> certificate generating process.
>>>
>>>
>>>
>>> On the Server machine, hard wired to a Broadband Router, I configured
>>> stunnel.conf as (removing comments for simplicity)
>>>
>>>
>>>
>>> debug = 7
>>>
>>> output = stunnel.log
>>>
>>>
>>>
>>> socket = l:TCP_NODELAY=1
>>>
>>> socket = r:TCP_NODELAY=1
>>>
>>>
>>>
>>> cert = stunnel.pem
>>>
>>> key = stunnel.pem
>>>
>>>
>>>
>>> options = NO_SSLv2
>>>
>>>
>>>
>>> taskbar=yes
>>>
>>>
>>>
>>> [Listener]
>>>
>>> connect=8000
>>>
>>> accept=8001
>>>
>>>
>>>
>>> On the Client machine, connected to the router via wi-fi, we have in
>>> stunnel.conf
>>>
>>>
>>>
>>> debug = 7
>>>
>>> output = stunnel.log
>>>
>>>
>>>
>>> cert = stunnel.pem
>>>
>>>
>>>
>>> socket = l:TCP_NODELAY=1
>>>
>>> socket = r:TCP_NODELAY=1
>>>
>>>
>>>
>>> fips=no
>>>
>>>
>>>
>>> options = NO_SSLv2
>>>
>>>
>>>
>>> delay=yes
>>>
>>> taskbar=yes
>>>
>>>
>>>
>>> client=yes
>>>
>>>
>>>
>>> [sender]
>>>
>>> accept = 0.0.0.0:7999 (I've tried just 7999 and
> 192.168.1.158:7999,
>>> here. Makes no difference)
>>>
>>> connect = 192.168.1.9:8001
>>>
>>>
>>>
>>> I've tried many variations with the same result, but the above is where
> they
>>> have ended up.
>>>
>>>
>>>
>>> My understanding of this is that stunnel both ends will be intercepting
> port
>>> 8000 on the Server and port 7999 on the Client and presenting/receiving
> SSL
>>> encoded messages across the wire on port 8001.
>>>
>>>
>>>
>>> Starting stunnel in the Server (not as a Windows service, although I did
>>> try that as well) the following log appears:
>>>
>>>
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG7[3484:6184]: No limit
>>> detected for the number of clients
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG5[3484:6184]: stunnel 4.54
> on
>>> x86-pc-msvc-1500 platform
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG5[3484:6184]:
> Compiled/running
>>> with OpenSSL 1.0.1c-fips 10 May 2012
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG5[3484:6184]:
> Threading:WIN32
>>> SSL:+ENGINE+OCSP+FIPS Auth:none Sockets:SELECT+IPv6
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG5[3484:6184]: Reading
>>> configuration from file stunnel.conf
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG5[3484:6184]: FIPS mode is
>>> enabled
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG7[3484:6184]: Compression
> not
>>> enabled
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG7[3484:6184]: Snagged 64
>>> random bytes from C:/.rnd
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG7[3484:6184]: Wrote 1024
> new
>>> random bytes to C:/.rnd
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG7[3484:6184]: PRNG seeded
>>> successfully
>>>
>>> 2012.11.16 22 <tel:2012.11.16%2022> :34:08 LOG6[3484:6184]: Initializing
>>> service [Listener]
>>>
>>> 2012.11.16 22:34:08 LOG7[3484:6184]: Certificate: stunnel.pem
>>>
>>> 2012.11.16 22:34:08 LOG7[3484:6184]: Certificate loaded
>>>
>>> 2012.11.16 22:34:08 LOG7[3484:6184]: Key file: stunnel.pem
>>>
>>> 2012.11.16 22:34:08 LOG7[3484:6184]: Private key loaded
>>>
>>> 2012.11.16 22:34:08 LOG7[3484:6184]: Could not load DH parameters from
>>> stunnel.pem
>>>
>>> 2012.11.16 22:34:08 LOG7[3484:6184]: Using hardcoded DH parameters
>>>
>>> 2012.11.16 22:34:08 LOG7[3484:6184]: DH initialized with 2048-bit key
>>>
>>> 2012.11.16 22:34:08 LOG7[3484:6184]: ECDH initialized with curve
> prime256v1
>>> 2012.11.16 22:34:08 LOG7[3484:6184]: SSL options set: 0x01000004
>>>
>>> 2012.11.16 22:34:08 LOG5[3484:6184]: Configuration successful
>>>
>>> 2012.11.16 22:34:08 LOG7[3484:6184]: Service [Listener] (FD=272) bound to
>>> 0.0.0.0:8001
>>>
>>>
>>>
>>> On the Client, the log shows:
>>>
>>>
>>>
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: No limit detected for the number of
>>> clients
>>>
>>> 2012.11.16 22:25:53 LOG5[4184:4948]: stunnel 4.54 on x86-pc-msvc-1500
>>> platform
>>>
>>> 2012.11.16 22:25:53 LOG5[4184:4948]: Compiled/running with OpenSSL
>>> 1.0.1c-fips 10 May 2012
>>>
>>> 2012.11.16 22:25:53 LOG5[4184:4948]: Threading:WIN32
> SSL:+ENGINE+OCSP+FIPS
>>> Auth:none Sockets:SELECT+IPv6
>>>
>>> 2012.11.16 22:25:53 LOG5[4184:4948]: Reading configuration from file
>>> stunnel.conf
>>>
>>> 2012.11.16 22:25:53 LOG5[4184:4948]: FIPS mode is disabled
>>>
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: Compression not enabled
>>>
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: Snagged 64 random bytes from C:/.rnd
>>>
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: Wrote 1024 new random bytes to
> C:/.rnd
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: PRNG seeded successfully
>>>
>>> 2012.11.16 22:25:53 LOG6[4184:4948]: Initializing service [sender]
>>>
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: Certificate: stunnel.pem
>>>
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: Certificate loaded
>>>
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: Key file: stunnel.pem
>>>
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: Private key loaded
>>>
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: SSL options set: 0x01000004
>>>
>>> 2012.11.16 22:25:53 LOG5[4184:4948]: Configuration successful
>>>
>>> 2012.11.16 22:25:53 LOG7[4184:4948]: Service [sender] (FD=224) bound to
>>> 0.0.0.0:7999
>>>
>>>
>>>
>>> Running the Listener on the Server and Sender on the Client adds nothing
> to
>>> the log, and port sniffers on both machines show traffic between 7999 and
>>> 8000 (exactly the same as when stunnel is not running). No sign of the
> use
>>> of port 8001.
>>>
>>>
>>>
>>> I'd appreciate any input on this. I'm sure I must be doing something
> stupid,
>>> but I've watched hours of YouTube videos, read many hundreds of web
> pages,
>>> and been through the documentation quite a few times, to no avail.
>>>
>>>
>>>
>>> I have a Java based version, running in a JVM in the same Windows
> machines,
>>> that talks perfectly to the exchange using some inbuilt SSL capabilities
> of
>>> an included library, so that should probably eliminate any
> hardware/router
>>> issues?
>>>
>>>
>>>
>>> Regards, Hal
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> stunnel-users mailing list
>>> stunnel-users at stunnel.org
>>> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>>>
>>> _____
>>>
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.2221 / Virus Database: 2629/5400 - Release Date: 11/16/12
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> stunnel-users mailing list
>>> stunnel-users at stunnel.org
>>> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>>>
>> _______________________________________________
>> stunnel-users mailing list
>> stunnel-users at stunnel.org
>> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2221 / Virus Database: 2629/5400 - Release Date: 11/16/12
>
>
More information about the stunnel-users
mailing list