On 12/15/2017 11:44 PM, vel...@tutamail.com wrote:
I have scenario #1 working...I checked DNS leak and was able to get different results depending on the VM I was on. Is this just likely to break due to the bug you reference?
The bug only pertains to "Deny except" setting on appVMs causing the VPN to block DNS. Bug isn't triggered if you use "Deny except" on the VPN VM itself.
Scenario 2 was supposed to depict 3 separate sys-net, not running at the same time. clarified as follows: Clarrified Scenario #2 a) VMa------sys-vpn------sys-firewall---sys-net(Wireless and ethernet) b) VMb-------------------sys-firewall---sys-net(Wireless and ethernet) c) VMc-------------------sys-firewall---sys-net(Wireless and ethernet) If I want to get on VMa(VPN)...I would need to close all VMs in b) and c), if I wanted to get on VMb, I would need to close all VMs in a) and c), etc...pain in the but! But is this more secure due to multiple seperated sys-net?
Qubes treats sys-net as untrusted. IMO here you're not gaining much (if any) security for the extra hassle.
Scenario #3 clarified a) VMa----------sys-vpn---------sys-net(Wireless and ethernet) b) VMb----------sys-firewall----sys-net(Ethernet only) c) VMc----------sys-firewall----sys-net(Wireless only) #3 Scenario is insipired by this post(multiple sys-net's): Multiple sys-net: http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html ...is the only benefit of this configuration that I can use VMb and VMc at the same time? or is there better isolation with this config having multiple sys-net's? This assumes all VMs in a) and b) would need to be closed to get on VMa(VPN)
There is some merit to separating wifi and ethernet like this as it could help protect an ethernet LAN from malware acquired over wifi, for example. But in this case combining them sometimes in one sys-net with a) may not be a good idea. Instead, if you need to sometimes use the VPN over wifi and sometimes over ethernet, you could easily switch the netvm setting on the VPN VM; then your wifi and ethernet controllers stay in separate VMs.
Regarding the firewall rules in sys-vpn: Unfortunately (or fortunately?) my VPN provides a domain name instead of IPs e.g. VPNprovider.Canada.com, the VPN provider requires port 1194(UDP only), with user name/password and a local cert(all set up in the OpenVPN client in sys-vpn). In the sys-vpn VM firewall, I would "allow DNS queries" and "deny network access except": 1) put a rule that allows "*"(Which I believe allows "Any" domain/IP to pass, although it is limited to VPNprovider.Canada.com i.e. the Gateway in OpenVPN client )for "address", 2) port 1195 for "service" and 3) a protocol of "UDP". Wouldn't this block port 80, 443 and all other ports and only allow VPNprovider.Canada.com on port 1195 via UDP only?
Only if you're certain that other addresses won't be accessed by sys-vpn.
Therefor if VPN goes down all other ports 80, 443 would not be allowed? i.e. a kill switch?...similar to whats on the Qubes instructions except GUI configured?
But if no other addresses besides VPNprovider.Canada.com are accessed, why would other _ports_ be accessed? IOW, yes this nails down the ports (because numbers are used for those) but whatever might access other ports might access other addresses.
Using the VPN doc or Qubes-vpn-support such access attempts wouldn't succeed. If you look at the firewall script, it restricts output solely to the VPN client (i.e. openvpn) using a special group 'qvpn'. This prevents incidental net access by other programs.
And again, putting domain names on the firewall settings tab tends to be an unreliable, weak measure; its not good advice if DNS returns a random selection from a pool of IPs. Its also weak if MITM is in the threat model, allowing an attacker to easily spoof their own addresses and port numbers ...and your worries about sys-net seem to indicate that such a threat applies.
So all said and done, its not necessary to add firewall rules if your VPN provider uses a cert and the sys-vpn config isolates the tunnel traffic as VPN doc and Qubes-vpn-support do.
-- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/694442b1-61ff-21c4-93f0-02ba50d356f3%40posteo.net. For more options, visit https://groups.google.com/d/optout.
