Sorry, I forgot to add my startup command:

PROXY="socks://127.0.0.1:1080"
PROXYCMD="--proxy-server=http=$PROXY;https=$PROXY"

GTK2_RC_FILES=$HOME/.gtk2chrome \
dbus-launch $HOME/bin/chrome-linux/chrome-wrapper \
  --enable-compact-navigation \
  --enable-plugins \
  $PROXYCMD \
  "$@"

Note that browsing still works with that setting, so the proxy is working. It's just /some/ of the connections are attemped directly.

It's probably useful to have the full iptables listing that shows my output rules:

└# iptables -nv -L OUTPUT                                                                                  (viins)
Chain OUTPUT (policy DROP 278 packets, 31110 bytes)
 pkts bytes target     prot opt in     out     source               destination
4069K 1931M ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            192.168.122.0/24
  43M   55G ACCEPT     all  --  *      *       0.0.0.0/0            192.168.1.0/24
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 220
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 206
    0     0 ACCEPT     udp  --  *      *       192.168.1.10         0.0.0.0/0
    0     0 ACCEPT     udp  --  *      *       192.168.1.10         0.0.0.0/0
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner GID match 999
  536 40736 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:123
 409K  148M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 220
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 206
  128  5120 ACCEPT     tcp  --  *      *       192.168.1.10         0.0.0.0/0
    0     0 ACCEPT     tcp  --  *      *       192.168.1.10         0.0.0.0/0
 173K   29M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner GID match 999
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9418
  746  148K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
  273 22457 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22000
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:873
  210 10423 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 3 LOG flags 0 level 7 prefix "TCP OUTPUT packet killed: "
 2215 99131 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
   41  7344 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 3 LOG flags 8 level 7 prefix "UDP OUTPUT packet killed: "
   81  9960 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

I changed the proxy flag to:

PROXYCMD="--proxy-server=http=$PROXY;https=$PROXY;socks=$PROXY;socks5=$PROXY"

I couldn't find which of socks or socks5 was correct so I used them both. I also tried using the fox proxy addon.

I'm still seeing rejected packets, and also the chromium process is outputting this:

[29986:30040:0704/173303.805436:ERROR:ssl_client_socket_impl.cc(999)] handshake failed; returned -1, SSL error code 1, net_error -100
[29986:30040:0704/173304.051241:ERROR:ssl_client_socket_impl.cc(999)] handshake failed; returned -1, SSL error code 1, net_error -100

Yet another test with:

PROXY="socks5://127.0.0.1:1080"
PROXYCMD="--proxy-server=$PROXY"

Same results with the speedtest page.

Reflagging this because it is describing a potential privacy problem, moreso than a security bug.

The issue seems to be out of TE-scope as it is related to socks5 proxy set up and iptables. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!

The correct flag is:

--proxy-server="socks5://127.0.0.1:1080"

When you launch Chrome, verify what the proxy settings (for the main profile) show at:

chrome://net-internals/#proxy

To debug further, capture a NetLog that includes the traffic not being sent through proxy:

https://www.chromium.org/for-testers/providing-network-details

Generally the problem is users not configuring the correct proxy settings.

As there is an appalling number of ways to configure proxy settings
 * Can be controlled by the system
 * Can be overridden via Chrome policy for the device
 * Can be overridden by extensions (on a per-profile basis)
 * Can be overridden by command line flags
 * Can be influenced by environment variables
 * Can be specified on a per-interface basis (for some platforms)
 * Can vary per platform for 32 vs 64 bit binaries


Generally for this sort of use case, the issue is around expectations of what Proxy settings mean. IIRC some predictive features like "Use a prediction service to load pages more quickly" may result in DNS requests being made, and those not being http[s]:// requests do not go through a proxy.

To some degree you can reduce that by launching Chrome with:

--proxy-server="socks5://myproxy:8080"
--host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE myproxy"

However it is not a guarantee that every packet sent by the system will necessarily go through your SOCKS proxy. For that level of fidelity use a VPN.

Sorry, I didn't get a notification email until just now. I'll check those points.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I made a few Netlogs and the last one that I've attached with these settings in Chromium:

I turned off all extensions.
I turned off most settings like web-prediction etc. that looked like they may need any networking features.

This is how things are set up on my system:

I'm using fluxbox WM so the only proxy settings are made via env vars like $http_proxy etc, which I made sure were unset for this test. Previously they were set to 127.0.0.1:8118 which is privoxy. Privoxy is set to route through Tor by default, or the socks5 proxy provided by 3proxy on port 1080 for a few sites.
I'm running a local DNS server provided by Tor on port 53, and /etc/resolv.conf points to 127.0.0.1
I logged out of fluxbox and the launching console then relogged in again before doing the test.
No other applications that require network access were running.

iptables log for this test:

Jul  9 23:15:34 raven kernel: [3889190.421718] TCP OUTPUT packet killed: IN= OUT=eth0 SRC=192.168.1.3 DST=104.102.52.104 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=56529 DF PROTO=TCP SPT=44711 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
Jul  9 23:15:34 raven kernel: [3889190.421763] TCP OUTPUT packet killed: IN= OUT=eth0 SRC=192.168.1.3 DST=104.102.52.104 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=56530 DF PROTO=TCP SPT=44711 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
Jul  9 23:15:34 raven kernel: [3889190.423846] TCP OUTPUT packet killed: IN= OUT=eth0 SRC=192.168.1.3 DST=151.101.194.219 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=54407 DF PROTO=TCP SPT=58097 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
Jul  9 23:16:00 raven kernel: [3889216.954196] TCP OUTPUT packet killed: IN= OUT=eth0 SRC=192.168.1.3 DST=81.96.224.177 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=30377 DF PROTO=TCP SPT=58455 DPT=8080 WINDOW=0 RES=0x00 RST URGP=0 
Jul  9 23:16:15 raven kernel: [3889232.200179] TCP OUTPUT packet killed: IN= OUT=eth0 SRC=192.168.1.3 DST=81.96.224.177 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=42013 DF PROTO=TCP SPT=41189 DPT=8080 WINDOW=0 RES=0x00 RST URGP=0 
Jul  9 23:16:35 raven kernel: [3889251.840808] TCP OUTPUT packet killed: IN= OUT=eth0 SRC=192.168.1.3 DST=81.96.224.177 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=51925 DF PROTO=TCP SPT=48605 DPT=8080 WINDOW=0 RES=0x00 RST URGP=0 
Jul  9 23:16:50 raven kernel: [3889266.284109] UDP OUTPUT packet killed: IN= OUT=eth0 SRC=192.168.1.3 DST=239.255.255.250 LEN=193 TOS=0x00 PREC=0x00 TTL=1 ID=61650 DF PROTO=UDP SPT=43972 DPT=1900 LEN=173 UID=1000 GID=100 
Jul  9 23:17:57 raven kernel: [3889333.973848] TCP OUTPUT packet killed: IN= OUT=eth0 SRC=192.168.1.3 DST=92.122.174.213 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=3079 DF PROTO=TCP SPT=44313 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
Jul  9 23:17:57 raven kernel: [3889333.983521] TCP OUTPUT packet killed: IN= OUT=eth0 SRC=192.168.1.3 DST=92.122.174.213 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=3085 DF PROTO=TCP SPT=44313 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
Jul  9 23:17:57 raven kernel: [3889333.983547] TCP OUTPUT packet killed: IN= OUT=eth0 SRC=192.168.1.3 DST=92.122.174.213 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=3086 DF PROTO=TCP SPT=44313 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 

Thanks

Deleted: chrome-net-export-log-4.json 15.5 MB

chrome-net-export-log-4.json 15.5 MB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Looks to me like every socket in that log is using 127.0.0.1:1080 as a socks5 proxy.  Direct socket pools are also all empty.  It's possible there are other things making connections in Chrome, but doesn't look like the issue is for normal HTTP/HTTPS requests that go through the network stack proper.

I renamed my ~/.config/chromium directory and that seems to have had a big effect. Now I don't have messages for outgoing packets killed, but invalid incoming packets being dropped instead, from a different rule:

Jul 10 21:08:05 raven kernel: [3967939.313976] New not syn: IN=eth0 OUT= MAC=xxx SRC=91.198.174.208 DST=192.168.1.3 LEN=95 TOS=0x00 PREC=0x00 TTL=53 ID=14358 DF PROTO=TCP SPT=443 DPT=41535 WINDOW=59 RES=0x00 ACK PSH URGP=0

This was while browsing wikipedia and resolves to upload-lb.esams.wikimedia.org. I had similar packets from the speed test site.

So this is a huge improvement, and I would say fixes the issue. At least it seems to as far as I can see, but I will keep an eye on the logs during the next few days and see how things go. Thanks for all the assistance so far.

I was looking in the wrong log.

After removing the chromium dir nothing has changed.

Do you still need more information on this?

Nothing has changed - it still hits the firewall even with ~/.config/chromium removed, so no extenstions.