[stunnel-users] Odd complication between VM clients, same host

[afpteam at sbcglobal.net]

Hi,

Much appreciation to Stunnel and OpenSSL for a long, successful provision.

I can't be sure yet if the concern below is Stunnel or OpenSSL related.
I've surfed Google and found nothing similar.

Stunnel package with integral OpenSSL is current release.

I recently had to secure and connect two public facing client machines on the same Citrix Xen 6.2 release, running Server 2003 x 64 bit.

I typically use Stunnel with self generated Pem, for securing short term TightVNC sessions.
The config is always fairly generic, loopback allowed, securing across 127.0.0.1
Typically I don't make name references in the .conf profile, just accept / connect on related ports.

This is the first time I recall ever pointing two VM's at each other.
I have tried both service and gui on both Stunnel and VNC.
Tried both application listing and discrete port listing in the server's windows firewall.
I have tried updating security to the Admin account as owner or Administrators, in general.
I have tried launching either or both as Administrator.

When VNC client viewer calls to Server, Stunnel sees the connect, succeeds the Pem and stops.
If I restart the stunnel service at the server, the viewer auth dialog suddenly succeeds.
I question if this remains secured but clearly isn't practical for application.

Both VM's are connected to me via RDP at the time, if this might relate to an Auth violation.

I tried multiple VMs to eliminate anything related to a bungled VM config.
I'm guessing there is some kind of circular routing restriction possibly.
Citrix does use an X-window console to each VM on the control path, but in other instances there's never been any conflict.

Not sure how to determine if the issue is config, Stunnel or OpenSSL or how to resolve it.
Any suggestions would be appreciated.

Regards and thank you again,

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20140824/050f68ac/attachment.html>