Open ReneHollander opened 2 years ago
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.
I really wish i had found this before I did all this >>https://github.com/binhex/arch-qbittorrentvpn/issues/203
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?
@binhex any thoughts on making the adjustments mentioned here?
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
updating here for other users watching, We seem to have found a solution https://github.com/binhex/arch-qbittorrentvpn/issues/203 (comment)
My specific involves two docker networks:
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).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.Thoughts on that?