I'm 99.9% sure its not my firewalls that are the culprits because while I was testing I had the client pc running behind the same firewall/router that I shipped along with the client pc. So that puts the client side firewall out of the equation. Now for the server side, I tested that by setting my home pc as the client and connecting to my work server. That worked perfectly. So that takes the server side firewall out of the equation too. What's left is the client side ISP (Direcway satellite service), which is the only option available in the client location.
What I know about Direcway:
* They are not VPN friendly (they state that on their website). I do not consider an SSL tunnel as a VPN but... * If you do run a VPN, your connection speed drops by 50% (unless you buy some extra hardware from them), but it should still work even if you do not invest in the extra hardware * The latency on that connection is mortal. Just try SSH on you will know (between 0.6 and 2.5 seconds per keystroke)
Also, I played around with the timeout counters on boths sides but that did not help. Specifically, TIMEOUTconnect and TIMEOUTclose. One setup that did work, curiously enough, was switching roles between server and client. When I turned the client pc into the server and vice versa, it worked flawlessly.
I'm fresh out of ideas.
John Hartnup1 wrote:
stunnel-users-bounces@mirt.net wrote on 26-09-2005 19:17:55:
Hello,
I'm having problems using stunnel. I would be glad to provide further information upon request. The funny thing is that it was working before I shipped the client pc to the remote location. Nothing has changed
since.
They symptoms appear to me to be consistent with a firewall between the client and the server terminating the connection when it sees traffic that doesn't fit its view of what the protocol it expects on port 465 to be.
I see this all the time because I work with FTP/TLS, which goes on port 21 like normal FTP, but some common firewall configurations sever the connection when it switches to SSL and the firewall starts seeing non-ASCII bytes, or long strings of bytes without CRLFs.
However, port 465 is designated for SMTP over TLS, so this wouldn't seem likely to be a common firewall configuration. The fact that it worked when the client was on a different network supports the theory that it's firewall related.