wfg / docker-openvpn-client

OpenVPN client with killswitch and proxy servers; built on Alpine
MIT License
353 stars 107 forks source link

Security question #99

Closed telnetdoogie closed 1 year ago

telnetdoogie commented 1 year ago

I am using this image to allow an unbound container to access root servers and bypass my ISP's DNS interception. So far so good. I have this set up like so (all docker containers)

[pihole] --> [unbound] --> [openvpn-client]

my unbound config specifies network_mode: service:openvpn-client and everything looks like it's working, a DNS spoofing test shows that I'm sending DNS requests from my VPN public IP.

Everything is working well, however I notice when doing some research that using this setup makes my unbound container publicly accessible from the internet, using the VPN's public IP. If I use a third party service to port scan port 53 of my VPN public IP, it shows as open and responding to requests.

Is there some config I can use for openvpn where it doesn't allow all traffic inbound? It appears that all inbound traffic is sent to the unbound container and unbound responds accordingly... and my preference would be to NOT effectively be hosting a public DNS server on my host.

I thought that the ALLOWED_SUBNETS environment variable would effectively limit traffic to the host to only docker containers (I have it set right now to 172.17.0.0/16 which is the network being used by my docker containers, but that doesn't seem to limit anything...

I thought perhaps it might be solvable by something like

[pihole] --> [unbound] --> [some firewall container] --> [openvpn-client]

...but now it's getting really complex and I'm worried about stability and dependencies. (say the vpn client needs to restart)

Any help / advice appreciated!

telnetdoogie commented 1 year ago

Well, I discovered that by changing a setting on my account with my VPN provider, I'm able to alleviate the issue by enabling NAT firewall on my VPN connections, so it looks like the container is no longer responding to pings or DNS requests from the public IP... Super good.

I can close this, but I am wondering what the general guidance is for this particular concern.

wfg commented 1 year ago

If I use a third party service to port scan port 53 of my VPN public IP, it shows as open and responding to requests.

Port 53 may be open and responsive, but are you sure that it's your DNS server that's responding? I'm not so sure your VPN provider would be port forwarding 53 on their IP to your Unbound instance (especially not automatically). For instance, with Mullvad, you have to explicitly and manually request a port forward and even then it's a random ephemeral port.

telnetdoogie commented 1 year ago

yeah 100%... it was responding to DNS queries... I guess this depends on your VPN provider, but mine by default was NOT NATing my client... Changing that setting at the VPN account level fixed it, so it's not an exposure now... and the more I think about it, this is behaving the same as any VPN client used on a computer... for example if I used a windows-based VPN client, and turned off my firewall, my machine would be sitting unprotected on a public IP... So I don't think this is necessarily an issue with this particular image... Perhaps there's an openvpn option to disable traffic, but again, that's an openvpn question versus this particular image. It's just something to be wary of, I think.

telnetdoogie commented 1 year ago

FYI my provider is VyprVPN

wfg commented 1 year ago

VyprVPN

https://support.vyprvpn.com/hc/en-us/articles/360039668472-Does-VyprVPN-support-Port-Forwarding- You're exactly right. It says it's enabled by default, so you must've disabled it at some point. I haven't seen a setup like that before. Completely closed or completely open with no in-between is kind of strange to me.

if I used a windows-based VPN client, and turned off my firewall, my machine would be sitting unprotected on a public IP

It sounds that way given their support article.

telnetdoogie commented 1 year ago

Closing since this isn’t an issue with this container. My question turns out to just be a very specific problem with VPN clients where no NAT / security is present.