Le lundi 22 août 2016 03:18:07 UTC+2, Andrew David Wong a écrit :
> Hash: SHA512
> On 2016-08-21 16:43, nishiwak...@gmail.com wrote:
> > Le dimanche 21 août 2016 21:28:13 UTC+2, Andrew David Wong a écrit : On 
> > 2016-08-21 04:02, nishiwak...@gmail.com wrote:
> >>>> Any help to configure sys-firewall would be also really appreciated.
> >>>> I got this annoying pop-up when I click on "Firewall rules" tab under
> >>>> the sys-firewall proxyVM settings :
> >>>> 
> >>>> "The 'sys-firewall' AppVM is not network connected to a FirewallVM!
> >>>> 
> >>>> You may edit the 'sys-firewall' VM firewall rules, but these will
> >>>> not take any effect until you connect it to a working Firewall VM."
> >>>> 
> >>>> Only subject related to this problem I found is this message from
> >>>> Unman on Qubes-users group :
> >>>> 
> >>>> "When you configure the firewall rules for a vm those rules are
> >>>> applied ON THE FIREWALL to which the vm is attached. So the error
> >>>> message you get is entirely accurate - your firewall is not attached
> >>>> to a firewall and so the rules cannot be applied. Of course you COULD
> >>>> configure a firewall between the fw and the netvm but the same
> >>>> consideration would apply to THAT fw. There's no reason why you cant
> >>>> configure the fw iptables by hand if you want to: you can use 
> >>>> /rw/config/qubes-firewall-user-script to have these rules applied 
> >>>> automatically."
> >>>> 
> >>>> Ok so here's what I understand from this message : this proxyVM 
> >>>> Firewall is probably working but rules don't apply because it is 
> >>>> attached to a NetVM, which don't have any firewall policies by 
> >>>> default.
> >>>> 
> >>>> https://www.qubes-os.org/doc/qubes-firewall/ Official documentation 
> >>>> says : "Every VM in Qubes is connected to the network via a
> >>>> FirewallVM, which is used to enforce network-level policies. By
> >>>> default there is one default Firewall VM, but the user is free to
> >>>> create more, if needed."
> >>>> 
> >>>> And then you got explanations on how to edit rules in a specific VM
> >>>> for a given domain.
> >>>> 
> >>>> So I understand you have to edit rules on a AppVM to open up ports 
> >>>> there, but I mean not everyone running Qubes OS is highly graduated
> >>>> in IT and network routing.
> >>>> 
> >>>> I find quite disappointing that the official documentation don't 
> >>>> mention more clearly how to set up the default sys-firewall proxyVM, 
> >>>> like if you are supposed to check either "Deny network access
> >>>> except" or "Allow network access except" button or if that doesn't
> >>>> matter, if those policies won't apply anyway because of this
> >>>> pop-up...
> >>>> 
> > 
> > Just ignore the "Firewall rules" tab of sys-firewall. Pretend it's not even
> >  there.
> > 
> > Suppose you have an AppVM in which you want to enforce specific firewall 
> > rules. You should go into the VM settings for *that VM*, then the "Firewall
> >  rules" tab, then configure your firewall rules there. These firewall
> > rules are then *enforced by* sys-firewall under the hood. Enforcing these
> > rules for other VMs is sys-firewall's raison d'être.
> > 
> > By default, there is only one VM with this job: sys-firewall. Therefore, 
> > there is no other VM that can perform this job *for* sys-firewall. But
> > that's not a problem, because there's usually no reason to specify firewall
> > rules for sys-firewall itself anyway. (Besides, you're free to create as
> > many ProxyVMs as you like an chain them together.)
> > 
> > 
> > Ok, thank you very much for your help. Unfortunately I still have great 
> > difficulties to open up port 443 or 80 on an AppVM.
> > 
> > I have read this comment on another thread from Alex Dubois saying :
> > 
> > "A diagram in the wiki would help people understand.
> > 
> > For now: A packet comming from the outside has a sourceIP of the
> > workstation on the LAN that issued it or the router that routed the packet
> > into your LAN and a destinationIP of your netVM externalIP (probably
> > 192.168.0.x). The NetVM iptables rules are going to transform it to a
> > packet with a destinationIP of your firewallVM ( The firewallVM
> > iptables rule are going to transform it to a packet with a desktinationIP
> > of your AppVM ("
> > 
> > I completely agree with him, a diagram would really help. I don't get why 
> > documentation don't address the routing basics stuff that isn't really
> > basic for newbies, for random people.
> The documentation is largely a volunteer effort. I'm afraid we simply don't
> have the workforce to make all necessary and desirable improvements to the
> documentation. We would love it if someone would submit a pull request adding
> such a diagram or, in general, improving that page.
> > I like a lot Qubes, this is an awesome OS, but far too complicated for
> > mister everyone. I am at the point right now where frustration becomes
> > overwhelming. I don't think I am not curious, trying to improve or
> > understand better the way this OS works... I'm just going mad tonight,
> > lol.
> > 
> > So let me try to sum up this comment in a visual way to understand better
> > how routing works on Qubes.
> > 
> > Outside IP packet (source : AppVM or router, like on some http request) => 
> > sys-net VM (destination) => firewall VM (new destination routed from
> > sys-net VM with iptables) => AppVM (new destination routed from sys-net VM
> > with iptables).
> > 
> > So let's say if I deny all traffic in an AppVM and want to make exclusions
> > to open only standard http(80) or https(443) protocols, am I supposed to
> > enter new rules in dom0 for the AppVM's Firewall and also configure
> > iptables as well, or only AppVM's Firewall exceptions are going to be
> > enough please ?
> > 
> > https://www.qubes-os.org/doc/dom0-tools/qvm-firewall/ I tried to connect 
> > Firefox on an AppVM with this rule, launching an https site, but it failed 
> > :( "qvm-firewall AppVMname -a localadressofsysnet(192.168.x.x) any 443 -P 
> > allow"
> > 
> > I also added a rule with vifX.X interface adress (I guess it is the bridge
> > to redirect traffic to the LAN network, but this is just assumption from
> > me, I didn't read about it), but still no success. Well, I might need a
> > rope instead ~
> > 
> > Anyway I probably have to deal again with this documentation 
> > https://www.qubes-os.org/doc/qubes-firewall/ and copy the automatic
> > scripts executing on one of the folders that don't reset data automatically
> > at reboot (/rw/config/), but I already did that to make 2 VM communicate
> > each others (client/server) and anyway this doesn't matter if I can't
> > communicate with the outside.
> > 
> > Indeed, I don't understand 1 thing on the "Port forwarding to a VM from
> > the outside world" part of the documentation : on the iptables scripts, do
> > you have to replace "MY-HTTPS" with the name of your service please ? Like
> > for hosting a server, with "apache2" service ?
> > 
> Sorry, this is beyond my knowledge. My own use of Qubes (as a regular user)
> has never occasioned the need to port forward to a VM from the outside world.
> Perhaps it's worth appreciating that what you're attempting to do is somewhat
> advanced, and therefore you should not expect it to be extremely simple. In
> any case, I hope someone knowledgeable about networking will chime in to help
> you with this.
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 2d24pqwjw9f/rX3ep36qHN1Y4iSSP/la/ze9dgoWPnyXakrB8R7olqasV2o4Z9+v
> ZyLqSOKF6R2KPUSyl1vE6Tc4F6l068wOcQnNphq+tmZEHX8VFprYgkzchXCMj9fp
> sVsU7Xk0prNXs/FWqxzPTJzbC7lPRuJ0OBTHdj8uvatJ6eeb6QxRI3hKWu2nXpCM
> 7ugxLc8Lvy5Ntjp40DoQOMidSDU2WmNyUBAfrlUGjIXVxu7mzk45P67cPG5Zuvo9
> KchQgu44N4bgm2tdkHg248iyB/GzolsObs3BQCzadMz7E2jv8YVU8u0rAD41OGON
> rDTqnDp5VEdo72iNijyZkXh+in/cmtAG9FY1JisTgeZhxTXJmMlzduDIaB2+QjBH
> UBeU9DxeeXtthmYIlmoq40gbLUnEW4KkMfyky99vWZcUHnCzdVd9l12+PDJkIAF5
> N2la7fqnAh5ElsdT3nBzECb7C5CYtW3zFB/oEDrmsObinIF5E0ohPdwWnXn++jCF
> kwurhgtReWPCxfd+JeIJTi3bQxE24pnPkTT4KYPcOloE9RHwGd5EsAIxkvbPb/po
> aUn1edDzVtnoyrXa/FVODd0IxW9TjFq1RGk8d9mXPSb01fKrKIOUQXnhyfwiY5gK
> sW6MaE08rTguFWY2Ng9q
> =E9Mf

I would love as well to be able to host a website to share my interest for 
Qubes OS with the world, or at least with people of my country sharing my own 
language if you don't mind, because Qubes OS documentation looks like imo being 
written mostly by native english users that don't seem to care much for 
non-native english users being lost. I would this way really like to 
participate to some translation effort, as I don't necessarily think you can 
enter easily those quite complicated notions with your non-native language.
Qubes documentation being largely a volonteer effort doesn't make it immune to 
the critics, and mine is that people spending this valuable time to share their 
knowledge to make people enter quite long and complicated procedures should 
consider that :
1) Explaining how to do port forwarding without adressing or refering to basic 
knowledge upon this concept leads to frustration, as you necessarily need to 
understand a bit what's going on in order to adapt the procedures.
2) Even if I think people mostly appreciate and are thankful to the Qubes 
community developpment for the incredible security improvement Qubes OS brings 
to everyone and that makes Qubes OS probably the best OS I know so far, when 
security isolation somehow puts you in cage where you encounter difficulties to 
communicate with rest of the world, well that's not the goal per se :p

But no problem, thank you for your help. I hope someone might give me some 
advices on this problem, but I am already trying to learn on iptables, as it 
looks like you can't unblock ports using only Qubes firewall, you have to 
understand these iptables scripts ^^

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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to