where ‘supports’ only means it is allows you to enter DNS name instead of the IP, but the warning is on the documentation states what I described:
Note that if you specify a rule by DNS name it will be resolved to IP(s) at the moment of applying the rules , and not on the fly for each new connection. This means it will not work for servers using load balancing, and traffic to complex web sites which draw from many servers will be difficult to control.
Indeed, this is exactly the reason having a redundant-firewallVM makes sense whenever one uses a URL rule in the appVM. Without the redundancy, the qubes-firewall service could enter a failed state in the vpnVM.
In 4.1 Qubes exports the resolved DNS entries so that you can theoretically pin the entries to the IPs that they were originally resolved to. That should then fix all the loadbalancing, cloud etc. issues.
Curiously, how do you prevent VPN leaks? I have firewall rules set up in my VPN proxy VM (primarily blocking IPs that are not associated with the VPN servers).
Qubes documentation seems to warn against running network services (ex. VPN) in VMs that run the Qubes firewall service (ex. sys-firewall). Not surprisingly, they suggest compartmentalizing the two functions. They also seem to recommend a second firewall be used between the client (appVM) and proxy (VPN) for other reasons.
Or perhaps I am misunderstanding something? The term “firewall” is used loosely at times. Either way, even if the potential benefit is a toss up, it seems that firewalls based on a minimal templates don’t impact resources too much to worry about it…
Ohh, yeah.
I just don’t think that a leak proof VPN ever exists. VPN is just not designed for such thing.
Moreover in my use cases most of my VPNs are not even providing a default route, so those are needs the ‘leaked’ by purpose.
Sure, there is a guide by community effort called Qubes VPN, but that is trying to provide features that a pure VPN solution does not have at all.
I surely not really understand that warning - maybe because of the ‘too smart’ vpn clients that are messing up with your packetfilter… but that’s simply not apply for my use cases.
My vpn’s are only addig routes, and do not messing up the packetfilter I have set up.
Even it’s not match with my threat model and use case, but at least now I understand the reasons, thanks.
I do not understand for many years, why do people trust VPN?
Are you really sure that Admin in this VPN company really does not see your traffic ?
Stupid people.
If your ISP provider opens one extra “daughter” company and call it: Dark VPN.
Would you buy it ?
But you do not know that.
People are blind trusting third companies just because there are some keywords for everybody on their website.
There is a difference between VPN and a VPN provider. Many people here seem to be able to setup their own VPN servers and be independent of third parties.
Calling everybody stupid who uses VPN only shows your intellect and adds nothing to the discussion. BTW, Blockchain is a buzzword, too just as VPN or cloud, and you are using it, obviously without understanding the principe (as ppc pointed out).
But yeah, I get your point.
I use the basic qubes 4.0 configuration without any VPN or Proxy, only whonix/tor. It is sufficient for most cases.
I’d do this for very, very specific cases that most probably wouldn’t include browsing the clear net nor tor, otherwise it could easily be turned out that I hide myself behind - myself.