Closed arunppsg closed 3 years ago
I guess you run the Firefox on the same machine you run the SSLproxy instance, right? If so, it is expected that the connection SSLproxy receives is not in the NAT table of the system. I suggest that you use a Firefox on another machine, so the connections from that Firefox show up in the NAT table.
I tried using Firefox from a different machine. In this setup, the sslproxy runs in a machine and the firefox browser from another machine directs traffic to the sslproxy. But the same error raises - Error from getsockopt(SO_ORIGINAL_DST): Protocol not available, connection not found in NAT state table, aborting connection. From my understanding, there are two parts of this error:
You also say that you have "added manual proxy configuration" to Firefox. That's not how traffic should be redirected to sslproxy, do not use any proxy configuration on Firefox. Please read the NAT ENGINES section in the sslproxy man page, and search for the word "redirect" in the man page to see your options.
iptables -t nat -A PREROUTING -s 192.0.2.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 10080
iptables -t nat -A PREROUTING -s 192.0.2.0/24 -p tcp --dport 443 -j REDIRECT --to-ports 10443
Running these two commands solved the problem. Thanks. If I am not wrong, the application forwards connections to destination ports 80, 443 via port 10080, 10443.
I suppose sslproxy listens on ports 10080 and/or 10443, instead of the one in your first post. And I suppose your local network where the Firefox connects from has the network address 192.0.2.0/24. If so, I think all looks fine now.
Thanks for your help.
Hello @sonertari!
However, if it were necessary to use iptables on the same computer as SSLProxy, to redirect all localhost requests from one port to another (443 -> 8443, for example), would that be feasible?
Honestly, I don't know if such a redirect rule would make such connections show up on the NAT table.
For bug reports, please supply:
Output of
sslproxy -V
SSLproxy v0.8.3 (built 2021-04-27) Copyright (c) 2017-2021, Soner Tari sonertari@gmail.com https://github.com/sonertari/SSLproxy Copyright (c) 2009-2019, Daniel Roethlisberger daniel@roe.ch https://www.roe.ch/SSLsplit Build info: V:GIT Features: -DHAVE_NETFILTER NAT engines: netfilter* tproxy netfilter: IP_TRANSPARENT IP6T_SO_ORIGINAL_DST Local process info support: no compiled against OpenSSL 1.1.1f 31 Mar 2020 (1010106f) rtlinked against OpenSSL 1.1.1f 31 Mar 2020 (1010106f) OpenSSL has support for TLS extensions TLS Server Name Indication (SNI) supported OpenSSL is thread-safe with THREADID OpenSSL has engine support Using SSL_MODE_RELEASE_BUFFERS SSL/TLS protocol availability: tls10 tls11 tls12 tls13 SSL/TLS algorithm availability: !SHA0 RSA DSA ECDSA DH ECDH EC OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG compiled against libevent 2.1.11-stable rtlinked against libevent 2.1.11-stable compiled against libnet 1.1.6 rtlinked against libnet 1.1.6 compiled against libpcap n/a rtlinked against libpcap 1.9.1 (with TPACKET_V3) compiled against sqlite 3.31.1 rtlinked against sqlite 3.31.1 4 CPU cores detectedOutput of
uname -a
Linux buddy 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/LinuxExact command line arguments used to run
sslproxy
sslproxy https 0.0.0.0 8443 up:8080 -k private_key.pem -c session.crtRelevant part of debug mode (-D) output, if applicable Error from getsockopt(SO_ORIGINAL_DST): Protocol not available Connection not found in NAT state table, aborting connection
I use sslproxy for analysing https packet. I use firefox browser and added manual proxy configuration with https proxy 127.0.0.1 8443. I use a python program to listen for connections in port 8080. But once I enter an url in the browser, the ssl proxy is not redirecting packet to the python script.
Any help on why the python script listening on port 8080 is not able t gather the packets will be useful. Thanks.