On Thu, Feb 14, 2019 at 03:13:00PM +0100, ashleybrown...@tutanota.com wrote:
> 
> 
> Hopefully one day they revert it back to how it was in 3.2. A very common 
> use-case for the firewall is likely to ensure things like DNS requests do not 
> happen through the normal means (and instead go over something like Tor or a 
> VPN). Unfortunately, the current config does not make it very obvious that 
> someone should block DNS ports. Making it very easy for someone to shoot 
> themselves in the foot because the interface is not intuitive (it says it 
> blocks all traffic other than what is specified and then later modifies this 
> saying "just kidding, we let DNS through")
> 
> Feb 14, 2019, 2:05 PM by ashleybrown...@tutanota.com:
> 
> > > The magic is in NAT rules (but I had to research this too.) See > 
> > > https://www.qubes-os.org/doc/networking 
> > > <https://www.qubes-os.org/doc/networking/>> , and "sudo iptables -t nat 
> > > -L" in sys-firewall and sys-net.
> >
> > I previously looked at IP tables and honestly I really do not understand 
> > it. Can you please explain a little how it works?
> >
> > Here is what my nat look like in sys-firewall:
> >
> > Chain PR-QBS (1 references)
> > target     prot opt source               destination        
> > DNAT       udp  --  anywhere             10.139.1.1           udp 
> > dpt:domain to:10.139.1.1
> > DNAT       tcp  --  anywhere             10.139.1.1           tcp 
> > dpt:domain to:10.139.1.1
> > DNAT       udp  --  anywhere             10.139.1.2           udp 
> > dpt:domain to:10.139.1.2
> > DNAT       tcp  --  anywhere             10.139.1.2           tcp 
> > dpt:domain to:10.139.1.2
> >
> > So, when I do ping google.com it needs to do a DNS request. Because my 
> > AppVm /etc/resolv.conf is set to 10.139.1.1 it creates a DNS request to 
> > send to 10.139.1.1. However, no VM on the network actually has this address.
> >
> > Is that packet modified? I am assuming what happens is the packet is 
> > forwarded to whoever the internet provider is (in this case sys-firewall). 
> > Sys-firewall then forwards it to sys-net. Sys-net then forwards it to the 
> > DNS server.
> >
> > I am assuming the IP-Header of each hop is rewritten. So, for example, 
> > sys-net will rewrite the IP header to be the external IP address for the 
> > computer and thus it will receive a response to that IP. Assuming this is 
> > correct how does the original AppVM get the correct response? I assume 
> > multiple AppVMs are all forwarding these UDP dns requests through 
> > sys-firewall and then sys-net. And then when sys-net gets a response how 
> > does it know to send which response to which specific AppVM?
> >
> > -- 
> > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
> > https://tutanota.com <https://tutanota.com>
> >
> >
> > Feb 14, 2019, 11:46 AM by > qubes-users@googlegroups.com 
> > <mailto:qubes-users@googlegroups.com>> :
> >
> >> ashleybrown...@tutanota.com <mailto:ashleybrown...@tutanota.com>>>  wrote 
> >> on 2/14/19 6:28 AM:
> >>
> >>> When I look at /etc/resolv.conf in the following VMs it says different 
> >>> things:
> >>>
> >>> 1) Normal AppVM:
> >>>
> >>> nameserver 10.139.1.1
> >>> nameserver 10.139.1.2
> >>>
> >>> 2) Sys-firewall VM:
> >>>
> >>> nameserver 10.139.1.1
> >>> nameserver 10.139.1.2
> >>>
> >>> 3) Sys-net VM:
> >>>
> >>> [actual resolvers]
> >>>
> >>> The chain for DNS packets is obviously AppVM -> Sys-firewall -> sys-net
> >>>
> >>> However, what I don't undersatnd is that 10.139.1.1 does not exist. That 
> >>> is not the IP address for any VM on the network. This can  be verified in 
> >>> Qubes Manager looking at the IP column. In addition, 10.139.1.1 refers to 
> >>> different VMs depending on the VM sending the packets. In AppVM it routes 
> >>> to sys-firewall. In sys-firewall it routes to sys-net.
> >>>
> >>> So, my question is how does all of this work? Where exactly does any 
> >>> request to 10.139.1.1 route to the actual connected VM. Looking at IP 
> >>> table rules I do not see where traffic sent to 10.139.1.1 goes to 
> >>> [sys-firewall IP here] for example. It appears to be doing it all 
> >>> magically, so where is the magic?
> >>>
> >>
> >> The magic is in NAT rules (but I had to research this too.) See >> 
> >> https://www.qubes-os.org/doc/networking 
> >> <https://www.qubes-os.org/doc/networking/>>> , and "sudo iptables -t nat 
> >> -L" in sys-firewall and sys-net.
> >>

Please don't top post. Take a minute to make it easier for other users.
As is clear in another thread, there is a clear warning about DNS on the
GUI firewall - I find it hard to believe that anyone could miss this.

-- 
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/20190214154222.gn7xbdfqc5fkzzya%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to