Allow connections to DNS servers outside the private IP range of the VPN the user connects to
opened this issue · comments
My system is arch linux. I incorporated vpnfailsafe into openvpn but I can't ping or drill after I connect with openvpn:
[alp@archlinux ~]$ ping -v -c 1 -n google.com
ping: socket: Permission denied, attempting raw socket...
ping: socket: Permission denied, attempting raw socket...
ping: google.com: Name or service not known
[alp@archlinux ~]$ drill
Error: error sending query: Could not send or receive, because of network error
Traffic to vpn's dns server is routed through tun0 but I can't ping nameserver also:
[alp@archlinux ~]$ resolvconf -l
# resolv.conf from tun0
nameserver [ip]
[alp@archlinux ~]$ ip route get [ip]
[ip] via [ip1] dev tun0 src [ip2] uid 1000
cache
I know that the problem is related to vpnfailsafe because I can ping successfully if I remove vpnfailsafe and connect.
Hey @alphancioglu. Sorry it took me so long to reply.
It seems the problem you're having is not with pings, but with name resolution (ping: google.com: Name or service not known). I assume the [ip] is one you expected and the routing appears to be correct.
Given all that, I'd say this is probably the same, or a similar problem to #24.
Please send me the output from the following commands:
ip routeiptables -Scat /etc/resolv.conf
If you'd rather not publish the information here, you can send it to wmknapik at gmail com. My PGP key signature is in my profile description, if you'd like to encrypt your message.
If we confirm that this is indeed a duplicate of #24, you can open an issue with your VPN provider. I'd be happy to help with that.
Hello @wknapik,
Thanks for the reply. I have sent you an email with the commands you requested. I am using ExpressVpn.
Hi @alphancioglu,
Thanks for the email. I see what the problem is. Your VPN provider pushes a DNS server that lies outside of the private network you join when you connect. Normally, I'd say that's misconfiguration on the VPN provider's end, but ExpressVPN, from my own experience, also push an additional route to the DNS server, which is enough to make this work, but vpnfailsafe doesn't currently white-list hosts on the firewall based on such extra routes.
That will be a good improvement to make. That said, I will not be able to start working on this in the next 12 days, sorry.
I will comment here and update the README, once it's done.
PS. I forgot to ask about the output/log from OpenVPN and/or your vpn config, so I don't know for sure, but I'm guessing you're using the route-noexec option in your OpenVPN config ?
As a temporary workaround, you could remove route-noexec from your config and manually run iptables -I VPNFAILSAFE_INPUT -s <dns_server_ip> -p udp --sport 53 -i tun0 -j ACCEPT after connecting. It will get things to work, but it's a lousy manual hack.
Sorry I don't have a better answer at the moment.
I was using route-noexec option but it didn't help.
I planned using vpnfailsafe to be able to use the DNS server of the vpn. Then I discovered update-resolv-conf and it did the trick. I will use vpnfailsafe after you add the feature. I can email you any command output if you need. Thanks for the help.
update-resolv-conf will set the dns server for you, yes, but be aware, that it is not IP leak protection. For instance, If you get disconnected from the VPN, your connection to the internet will be active and your IP may be revealed to whoever you consider your adversary. If you're facing any serious risks, you need to be aware of that. I'm not sure if ExpressVPN offers their own IP leak protection software, but most VPN providers do, so if you want to be safe, I'd suggest using that, at least until I can make the changes in vpnfailsafe to allow you to use it without issues.
I added iptables command you suggested to the vpnfailsafe script and dns server works now. I will continue to use vpnfailsafe. You are right about not to expose my IP. Always better to be safe.
Changed the title of the issue, so users can easily see that the problem is known and an issue remains open.
I've been away for a while, but I'm back now. Will take a first look at this this weekend.
Ok, so a preliminary version of the improvement this issue is about is available on the additional_routes branch. If anyone wants to test, here's the script https://github.com/wknapik/vpnfailsafe/blob/additional_routes/vpnfailsafe.sh. If no one reports any problems with the update and I don't find any myself, I will push that change to master in a few days, triggering a new vpnfailsafe-git release for Arch Linux.
(The change involves adding/removing additional routes pushed by the server and creating firewall exceptions for each)
@alphancioglu, @elimpnick - this is fixed.
Tested with several providers, seems to be working fine. The changes are on master now. If you're using the AUR package, you can update to get the latest changes.
Can you increment the PKGREL or a new PKGVER so we can get the update in the AUR? I'll try it out right away after. Thanks!
This is a -git package - there's no need to increment anything. The changes in the git repo are enough.
Different package managers handle updating -git packages differently.
When I want to update all of them, I use pacaur -Syu --devel, but I would expect pacaur -S vpnfailsafe-git to work as well.
If you're using a different tool, that's ok, but you might need to check the man page for any -git package specific handling.
I use pacaur as well. I happen to be a package manager of a few packages in the AUR including some from git repos, so I know how this works.
I would have updated the PKGBUILD for a fix such as this, if you don't want to, fine by me, there's at least 3 people that know this is fixed I guess.
Thanks again.