Multiple docker networks cause issues with allowing traffic to applications

[ReneHollander]

My specific involves two docker networks:

• A shared one for use in a docker network for a reverse proxy
• A specific one for all services communicating with deluge (sonarr, radarr)

The issue is that iptable.sh uses the default route to figure out which the docker interface is and uses it to allow traffic to the application running in the VPN container (in this case Deluge on port 8112).

[root@94d9e466609a /]# iptables -L -v
Chain INPUT (policy DROP 107 packets, 5298 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   62  9226 ACCEPT     all  --  any    any     172.19.0.0/16        172.19.0.0/16       
29030 5394K ACCEPT     all  --  eth0   any     swiss.privacy.network  anywhere            
    0     0 ACCEPT     all  --  eth0   any     unn-156-146-62-213.cdn77.com  anywhere            
    0     0 ACCEPT     all  --  eth0   any     unn-212-102-37-2.cdn77.com  anywhere            
    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:8112
    0     0 ACCEPT     udp  --  eth0   any     anywhere             anywhere             udp dpt:8112
    0     0 ACCEPT     tcp  --  eth0   any     172.16.0.0/12        172.19.0.0/16        tcp dpt:58846
    1    84 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp echo-reply
  110 32135 ACCEPT     all  --  lo     any     anywhere             anywhere            
29008 3519K ACCEPT     all  --  wg0    any     anywhere             anywhere            

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 6 packets, 416 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   61  9276 ACCEPT     all  --  any    any     172.19.0.0/16        172.19.0.0/16       
30024 5060K ACCEPT     all  --  any    eth0    anywhere             swiss.privacy.network 
    0     0 ACCEPT     all  --  any    eth0    anywhere             unn-156-146-62-213.cdn77.com 
    0     0 ACCEPT     all  --  any    eth0    anywhere             unn-212-102-37-2.cdn77.com 
    0     0 ACCEPT     tcp  --  any    eth0    anywhere             anywhere             tcp spt:8112
    0     0 ACCEPT     udp  --  any    eth0    anywhere             anywhere             udp spt:8112
    0     0 ACCEPT     tcp  --  any    eth0    172.19.0.0/16        172.16.0.0/12        tcp spt:58846
    1    84 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp echo-request
  112 32215 ACCEPT     all  --  any    lo      anywhere             anywhere            
30015 3088K ACCEPT     all  --  any    wg0     anywhere             anywhere            
[root@94d9e466609a /]# ip route
default via 172.19.0.1 dev eth0 
172.16.0.0/12 via 172.19.0.1 dev eth0 
172.19.0.0/16 dev eth0 proto kernel scope link src 172.19.0.3 
172.25.0.0/16 dev eth1 proto kernel scope link src 172.25.0.4 

A possible solution for the container being part of multile networks would be using a filter on interface like !wg0 (or whatever the VPN interface would be) to only dissalow access through the wireguard tunnel to Deluge.

Chain INPUT (policy DROP 107 packets, 5298 bytes)
...
    0     0 ACCEPT     tcp  --  !wg0   any     anywhere             anywhere             tcp dpt:8112
    0     0 ACCEPT     udp  --  !wg0   any     anywhere             anywhere             udp dpt:8112
...
Chain OUTPUT (policy DROP 6 packets, 416 bytes)
 pkts bytes target     prot opt in     out     source               destination         
...
    0     0 ACCEPT     tcp  --  any    !wg0    anywhere             anywhere             tcp spt:8112
    0     0 ACCEPT     udp  --  any    !wg0    anywhere             anywhere             udp spt:8112
...

Thoughts on that?

[Grygon]

Seconding this issue--unfortunately only found it after determining it was the cause of my problem.

I've worked backwards and added my reverse proxy to my VPN'ed container's network, which means that they're all speaking via that default interface, but it's not ideal.

For now I'm just adding ip rules for all my docker containers (all under 172.0.0.0/8) with a Dockerfile on top of the binhex one, but I'd love something standard to handle it instead.

[maxfield-allison]

I really wish i had found this before I did all this >>https://github.com/binhex/arch-qbittorrentvpn/issues/203

[maxfield-allison]

Seconding this issue... For now I'm just adding ip rules for all my docker containers (all under 172.0.0.0/8) with a Dockerfile on top of the binhex one, but I'd love something standard to handle it instead.

@Grygon Are you still using the customized docker file? Would you mind sharing if so and if not, what are you doing now?

[maxfield-allison]

@binhex any thoughts on making the adjustments mentioned here?

[binhex]

commented on your original issue, as although the code change is here, the actual image you want is built from this:- https://github.com/binhex/arch-qbittorrentvpn/issues/203#issuecomment-1779116157

edit - if you want to see the work that went into this then take a look at https://github.com/binhex/arch-int-vpn/compare/master...multi_adapter

[maxfield-allison]

updating here for other users watching, We seem to have found a solution https://github.com/binhex/arch-qbittorrentvpn/issues/203 (comment)