Why does my iptables configuration allow non-TOR traffic?

Question

What on earth is going on here? I have the following rules set:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             127.0.0.0/8         
ACCEPT     all  --  anywhere             anywhere             owner UID match debian-tor
ACCEPT     all  --  anywhere             anywhere             state ESTABLISHED
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

And these on nat:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             owner UID match debian-tor
REDIRECT   udp  --  anywhere             anywhere             udp dpt:domain redir ports 53
RETURN     all  --  anywhere             127.0.0.0/9         
REDIRECT   tcp  --  anywhere             anywhere             redir ports 9051
REDIRECT   udp  --  anywhere             anywhere             redir ports 9051

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

As you can see, all outgoing traffic is blocked, except for tor traffic and traffic already estabilished (?) with tor. WHY do I still have active Tcp connections to, for ex. Stack Exchange?

ESTAB      0      0      192.168.1.107:53532                151.101.193.69:https                
ESTAB      0      0      192.168.1.107:56648                151.101.1.69:https                
ESTAB      0      0      192.168.1.107:59170                198.252.206.25:https                
ESTAB      0      0      192.168.1.107:36078                151.101.12.133:https                
ESTAB      0      0      192.168.1.107:45418                172.217.19.238:https                
ESTAB      0      0      192.168.1.107:35364                172.217.21.106:https                
ESTAB      0      0      192.168.1.107:56650                151.101.1.69:https   

whois 198.252.206.25

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#


#
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=198.252.206.25?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#

NetRange:       198.252.206.0 - 198.252.206.255
CIDR:           198.252.206.0/24
NetName:        SE-NET01
NetHandle:      NET-198-252-206-0-1
Parent:         NET198 (NET-198-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       AS25791
Organization:   Stack Exchange, Inc. (SE-111)
RegDate:        2012-10-17
Updated:        2012-10-17
Comment:        http://stackexchange.com
Ref:            https://whois.arin.net/rest/net/NET-198-252-206-0-1


OrgName:        Stack Exchange, Inc.
OrgId:          SE-111
Address:        110 William St.
Address:        Floor 28
City:           New York
StateProv:      NY
PostalCode:     10038
Country:        US
RegDate:        2012-09-14
Updated:        2014-09-16
Ref:            https://whois.arin.net/rest/org/SE-111


OrgAbuseHandle: SYSAD101-ARIN
OrgAbuseName:   Sysadmin Team
OrgAbusePhone:  +1-212-232-8280 
OrgAbuseEmail:  sysadmin-team@stackexchange.com
OrgAbuseRef:    https://whois.arin.net/rest/poc/SYSAD101-ARIN

OrgTechHandle: SYSAD101-ARIN
OrgTechName:   Sysadmin Team
OrgTechPhone:  +1-212-232-8280 
OrgTechEmail:  sysadmin-team@stackexchange.com
OrgTechRef:    https://whois.arin.net/rest/poc/SYSAD101-ARIN


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

What is going on here? I get the impression, from day to day, that iptables is horribly broken.

Answer 1

add a -J LOG rule at the end of OUTPUT so you know which packets are going by the rest of the rules. Also adding -v to iptables -L helps since you can see more details, including the number of packets hitting each rule.

For example:

iptables -A OUTPUT -j LOG --log-prefix "firewall:ACCEPT:" --log-level 6

Also, I would do it this way if privacy was a high priority... I would not trust anyone to write perfect rules for this purpose. I would instead make a separate machine that is the client, that has no way of using any internet connections except through tor. That way, even if your machine got malware that sends out packets through the clearnet to give away your identity, it would just fail to connect. If you do it your way, then failure just goes over clearnet instead of being blocked, as you have already seen.