If you do HTTP to the server port of an stunnel instance:
client <--- TCP ---> stunnel <--- TCP ---> server
<--- TLS --->
<------------- HTTP -------------->
For the rest of your question, you need to figure out exactly what's going on with the "firewall" or "proxy" that you're using; there are a number of different techniques it may be using to handle the connection that will allow or prevent certain techniques when you use it.
1. Direct TCP Connection
If you're making a TCP connection that terminates at the remote host (diagram above), even if it's modified in some way (e.g., addresses changed via NAT), and you set up a TLS connection on that TCP connection, intermediate routers will not be able to see any of the traffic beyond the amount of it, the IP addresses and TCP ports, and the fact that it's TLS. An IP level firewall might be configured to disallow connections to ports other than 443 or drop connections to 443 if it sees that they're not TLS. It might even connect to the port itself first to see if the server appears to be running HTTP/TLS on that port.
2. HTTP Proxy
If you're going though an HTTP proxy using the CONNECT verb, as Proxytunnel does, there are two TCP connections involved but you do one TLS connection over them:
client <---- TCP 1 ----> proxy <---- TCP 2 ----> server
<------------------ TLS ---------------->
You are still negotiating TLS with the real server at the other end, and the situation is pretty much the same as #1 above. You don't need to do TLS over the TCP connections, actually; you could simply
CONNECT server.mydom.com:22 and start talking SSH over that connection if the proxy doesn't reject that request. Some people have SSH servers listening on port 443 for exactly this purpose. If the proxy is sophisticated enough to check the protocol in use, though, it may disconnect you if it see you didn't do a standard TLS setup, even though once TLS is up it can't see exactly what's going on in that connection.
Some organizations do man-in-the-middle attacks on HTTPS connections (sometimes more politely called "SSL interception"). When you attempt to connect to the remote server, via either a direct TCP connection or a proxy as in either of the cases above, a network device pretends that it's the remote server.
client <---- TCP 1 ----> MITM <---- TCP 2 ----> server
<---- TLS 1 ----> <---- TLS 2 ---->
<---------------- HTTP ---------------->
Your web browser than attempts the TLS setup, checking the certificate, and will validate it not because it's the real cert but because the device generated a cert with signed by a private CA (certificate authority) and the IT department has also modified cert list in the browser or OS to trust that CA. (You can often tell this is happening by trying the same connection with another program that uses a different cert list without that cert, such as Firefox if you download it independently.) You have a secure connection to the MITM device, but it's decrypting everything and re-encrypting it for another, separate secure connection to the server when it forwards data.
In this case, though you think you're talking to the remote server, you're actually talking securely only to the proxy which has full access to all data on the connection and can see and modify it as it wishes.