How does Qubes DNS resolving work?

[ashleyb...@tutanota.com]

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?

[awokd]

ashleyb...@tutanota.com wrote on 2/14/19 6:28 AM:

The magic is in NAT rules (but I had to research this too.) See
https://www.qubes-os.org/doc/networking/, and "sudo iptables -t nat -L"
in sys-firewall and sys-net.

[ashleyb...@tutanota.com]

> The magic is in NAT rules (but I had to research this too.) See 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

Feb 14, 2019, 11:46 AM by qubes...@googlegroups.com:

ashleyb...@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:

The magic is in NAT rules (but I had to research this too.) See https://www.qubes-os.org/doc/networking, and "sudo iptables -t nat -L" in sys-firewall and sys-net.

--

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...@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/42007cbd-b403-c239...@danwin1210.me.

For more options, visit https://groups.google.com/d/optout.

[ashleyb...@tutanota.com]

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 ashleyb...@tutanota.com:

> The magic is in NAT rules (but I had to research this too.) See 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

Feb 14, 2019, 11:46 AM by qubes...@googlegroups.com:

ashleyb...@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:

The magic is in NAT rules (but I had to research this too.) See https://www.qubes-os.org/doc/networking, and "sudo iptables -t nat -L" in sys-firewall and sys-net.

--

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...@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/42007cbd-b403-c239...@danwin1210.me.

For more options, visit https://groups.google.com/d/optout.

--

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...@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/LYgJrO0--3-1%40tutanota.com.

[unman]

On Thu, Feb 14, 2019 at 03:13:00PM +0100, ashleyb...@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 ashleyb...@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...@googlegroups.com <mailto:qubes...@googlegroups.com>> :
> >
> >> ashleyb...@tutanota.com <mailto:ashleyb...@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.

[unman]

On Thu, Feb 14, 2019 at 03:05:20PM +0100, ashleyb...@tutanota.com wrote:
> > 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?
>

Yes, you are spot on. The packet is sent upstream (routing table on
sys-firewall) and hits sys-net.
On sys-net, you'll see in the nat table (I'm assuming iptables on
Debian) rules that rewrite udp/tcp to 10.139.1.1 to use the DNS resolver
provided by the external network.
DNAT   udp  --  * * 0.0.0.0/0    10.139.1.1   udp dpt:domain to:X.X.X.X

These are stateful firewalls that keep track of the packets passing
through them. Sys-net returns the DNS result to sys-firewall and it's
there that the response is matched to the request and sent back to the
originating qube.

hth

unman

[ashleyb...@tutanota.com]

Feb 14, 2019, 3:42 PM by un...@thirdeyesecurity.org:

On Thu, Feb 14, 2019 at 03:13:00PM +0100, ashleyb...@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 ashleyb...@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.

>> 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.

I am new to mailing lists. What does top-post mean? Do you mean don't post the reply at the top of the message and instead at the bottom like this?

[awokd]

ashleyb...@tutanota.com wrote on 2/15/19 7:12 AM:

> I am new to mailing lists. What does top-post mean? Do you mean don't post the reply at the top of the message and instead at the bottom like this?
>

Much better, thank you. If you want to make sure there is no network
communication from an AppVM, don't connect it to a NetworkVM in the
first place. :) But like Unman said, there's a note at the bottom of the
GUI firewall tab regarding DNS and ICMP. Those can be fine tuned with
"qvm-firewall [qubename]" in a dom0 terminal.

[unman]

On Fri, Feb 15, 2019 at 08:12:35AM +0100, ashleyb...@tutanota.com wrote:
<snip>

> > 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.
> >
> I am new to mailing lists. What does top-post mean? Do you mean don't post the reply at the top of the message and instead at the bottom like this?
>

That's right, just like that.
It's also acceptable to interleave comments within the text:

> Can you give an example?
Of course, here is one.
> When would you want to do that?
When you want to comment on a number of distinct issues within the post.

It's also good to cut out extraneous material - as I have done here.
Some people cut *all* the previous posts, and that makes it very
difficult to follow what is going on.

Welcome to the lists.