Hi. On Tue, Jul 16, 2019 at 11:48:55AM -0700, pe...@easthope.ca wrote: > An attempt to open a page via HTTPS gives this report in the log. > Jul 16 11:25:16 joule stunnel: LOG5[4]: Service [https] accepted connection > from 127.0.0.1:36140 > Jul 16 11:25:16 joule stunnel: LOG3[4]: getsockopt SO_ORIGINAL_DST: Protocol > not available (92) > Jul 16 11:25:16 joule stunnel: LOG5[4]: Connection reset: 0 byte(s) sent to > TLS, 0 byte(s) sent to socket > > Appears the client application here has sent the request to port 36140 > and stunnel doesn't have a configuration for that.
No, you're incorrect. A client application has connected to localhost:443 using source IP 127.0.0.1 and a destination port 36140. A transparent proxy is called that because a client application should not connect to a proxy directly (as proxy won't understand where to forward application's request), it should try to connect whenever it usually does. stunnel(1) mentions helpfully that you're required to have a certain netfilter setup (mainly involving DNAT in your case), and judging from getsockopt(2) error message you don't have one. To be more specific, check if ip_conntrack kernel module is loaded. > Any ideas before I dig in the client software? Depends on what you're trying to achieve. If you need to wrap plain HTTP requests to a single host in TLS - that stunnel setup can be fixed. If you need to transform outbound HTTP requests to HTTPS to multiple hosts - you'll probably need squid/haproxy/nginx/whatever. If you need to perform MITM on unsuspecting application - it's called mitmproxy. In short, appears to be a classical A/B problem so far. Reco