Internet < SIEM ← VPN ← everything to connect through here < branch out to infrastructure labs, pentest lab and a personal VM to play in
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.
unfortunately zenmap has not yet been ported to python3, and python2 is EOL. It’s no longer in the debian repos as of debian 11 (bullseye), for example. Zenmap and Ndiff are python2 only · Issue #1176 · nmap/nmap · GitHub
whereas nmap is a recommended package in the minimal templates doc…
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…
[source: Firewall | Qubes OS]
Another discussion about this topic:
I mean a GUI network mapper.
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.
1 Like
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.
We need better technology
Blockchain based
Would you trust this?
you correct
not necessary blockchain based, it just need to be decentralized (just discover dvpn)
not bad, though, i see suspicious thing like apple device everywhere, a raspberry pi rack would do the same (possibly even better)
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.
1 Like
AppVM → VPN (CH) → Sys Firewall → Sys Net → Internet [For most of my browsing]
AppVM → Sys Firewall → Sys Net → Internet [For one Qube that needs to be able to hit a local network and the firewall messes with that]
DispVM → Sys Firewall → Sys Net → Internet [For watching videos / streaming that don’t like when a VPN is used]
VPN is ProtonVPN. Those guys seem trusty. They can read my mail, so seeing my traffic isn’t that much extra.
1 Like
Ain’t your appVM traffic will be in Switzerland to browse things, such as far-right papers or commie papers?
Yes, that is correct. The appVM traffic will be routed via Switzerland.
Yes, I just can’t get enough of those far right commie papers.
2 Likes
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.
Absolutely!
Is it necessarily “stupid”? Maybe they realize that the same risks apply to ISP providers who routinely expose user information to websites that are visited and are notorious for violating user privacy.
There do seem to be a few VPN providers who at least make an effort to inform users about many aspects of online privacy that are not shared by 99% of other ISP and VPN providers (ex.guides provided by iVPN and Mullvad). These same providers also offer payment methods (ex. cash with no personal details required) that make it more difficult to identify users even if they are bad actors. I don’t know of any ISP that offers such options.
That’s not to say they couldn’t be bad actors, but when all factors are considered, a VPN does seem to offer the user at least some additional potential for increasing online privacy - if for no other reason than it distributes risk beyond a single ISP.
2 Likes
Details on this???