[qubes-users] Torsocks and dnf no longer work in Fedora 29 -- Any Ideas?

[ashleybrown480]

I utilize torsocks dnf to perform updates over tor inside of HVM linux installs 
(so not in templates obviously which would use qubes normal update mechanism).

Since upgrading to Fedora 29 torsocks is not working with DNF. It throws an 
exception message. This is not directly related to qubes, but I imagine others 
have had this issue. Does anyone know how to use torsocks with dnf now. For 
example:

sudo torsocks --isolate dnf update


Running the above used to work perfectly. Now, it will work until it reaches a 
random error which is unrelated to networking. It is the following:

terminate called after throwing an instance of 'libdnf::File::CloseException'
  what():  Cannot close file: /var/cache/dnf/fedora-modular-[random 
letters]/repodata/[random letters]]-modules.yaml.gz
Aborted

So, it seems related to closing a file and for some reason this causes a 
termination, but only when using torsocks. When not using torsocks it works 
normally. I have run dnf clean all and all of that.

-- 
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/Lakw7aL--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix Yes or No

[ashleybrown480]

> Personally, I don't trust Whonix. The decision to not trust Whonix is
> not based on the sysadmin/aussie issue that came up recently on the
> list. I'm simply not convinced that they are capable of designing and
> writing secure software. Furthermore, there is no reason to use whonix
> in the first place, especially when you are using Qubes. Creating a tor
> netvm is rather straight forward (and a dispvm that includes the Tor
> Browser if you like to use that as well). If there is enough interest, I
> can also write up a summary on how to do that in Qubes.
>
> Regards
>

Please, it would be greatly appreciated. Especially on how to ensure no clear 
traffic happens and that it only goes over tor.

-- 
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/LZ5VKmW--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How does Qubes DNS resolving work?

[ashleybrown480]

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

> 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 
>> > >>  > 
>> > qubes-users@googlegroups.com >> >> :
>> >
>> >> >> ashleybrown...@tutanota.com >>  
>> >> >> > 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 
>> >> >>  <>> 

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[ashleybrown480]

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")

-- 
 Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
 https://tutanota.com


Feb 14, 2019, 11:59 AM by simon.new...@gmail.com:

> On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon@gmail.com wrote:
>
>> On Thursday, February 14, 2019 at 3:54:04 AM UTC, Marek Marczykowski-Górecki 
>> wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA256
>> > 
>> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, >> simon.new...@gmail.com 
>> > >>  wrote:
>> > > In 3, if i clicked on "block connections" in the Qubes manager firewall 
>> > > section, there was (if memory serves me) an option to block DNS and 
>> > > ICMP. 
>> > > 
>> > > That is not present in R4 (though docs say you can disable DNS and ICMP 
>> > > manually)
>> > > 
>> > > I'm just wondering what the logic behind the removal was? I would have 
>> > > thought that a general user who clicks "block connections" on Qube would 
>> > > not expect the qube to be able to actually send out and receive network 
>> > > packets such as DNS or ICMP. This presents information leakage scenarios 
>> > > (default DNS lookups of given qube) and also potential egress vectors if 
>> > > a qube is ever compromised (DNS tunnelling, ICMP tunnelling). 
>> > 
>> > Let me quote full text you can find on firewall tab there:
>> > 
>> > NOTE: To block all network access, set Networking to (none) on the
>> > Basic settings tab. This tab provides a very simplified firewall
>> > configuration. All DNS requests and ICMP (pings) will be allowed. For
>> > more granular control, use the command line tool qvm-firewall.
>> > 
>> > There is clear message what to do if you want to cut the qube from the
>> > network.
>> > 
>> > - -- 
>> > Best Regards,
>> > Marek Marczykowski-Górecki
>> > Invisible Things Lab
>> > A: Because it messes up the order in which people normally read text.
>> > Q: Why is top-posting such a bad thing?
>> > -BEGIN PGP SIGNATURE-
>> > 
>> > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxk5lQACgkQ24/THMrX
>> > 1yzyBQf+ID5V7ema8i77kmTCnsWfNeSPUQnlTjuQbF1oNZJFNeAwAaqp3FLO+Ljt
>> > Slj7e9KjbPYrxxuW40LIL05G78Yqs/MpZ1mA6/Yfy6J2tvoluucTFvatiHqiodO3
>> > HLqyRSehMXqqzKTHNrLrfLWWyz6ykbP/MmIw1zsxjcXj8RCNuEMc5F4qC6npluWN
>> > cahMNcZLELo4PsrjzhqTrSr0BmlVLDQ5QLwoJGi8wSDGMEIDX3qvwq56wh6O0MgR
>> > J780J043BcrIiAfZorrG+WfpLebkU9uSjmOENxcZQQwz2JmEdod9dU1vUEPSdBY1
>> > EKOq9FhCjMI6De6nNgiMf63Y47CxuQ==
>> > =9dvG
>> > -END PGP SIGNATURE-
>>
>> As I said, I understand the documentation is correct. thats not my question. 
>> My question is why was it removed as an option when the firewall box itself 
>> in network manager says "Deny network access except..." 
>>
>> My point is it is counter intuitive. If it says "deny network access 
>> exccept..." then there is an expectation that it will deny network access 
>> except for what is specified. There used to be tick buttons (allow 
>> updates/allow ICMP/allow DNS), which made it clear on the granular control 
>> there - but were removed in R4. The underlying subsytems you can still do 
>> that, sure. 
>>
>> Can I suggest that the wording "deny network access except..." is changed to 
>> "Deny TCP and UDP access except ..." for the avoidance of any doubt.
>>
>
>
> https://github.com/QubesOS/qubes-manager/pull/153 
> 
>
> -- 
> 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/39615092-155b-4f93-a418-95f7ff95c...@googlegroups.com
>  
> >
>  .
> 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+unsubscr...@googlegroups.com.
To post to this group, 

Re: [qubes-users] How does Qubes DNS resolving work?

[ashleybrown480]

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 
> > > , 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-users@googlegroups.com 
> > :
>
>> 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 
>> >> , 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+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/42007cbd-b403-c239-25cc-78f1d7ac3...@danwin1210.me
>>  
>> >>
>>  .
>> For more options, visit >> https://groups.google.com/d/optout 
>> >> .
>>
>
>
>
>
> --
>  

Re: [qubes-users] why was DNS/ICMP removed from Qubes manager/firewall in R4?

[ashleybrown480]

There is an issue that talks about the change: 
https://github.com/QubesOS/qubes-issues/issues/4141 


They are willing to port it back to how it should be if someone does the 
interface to re-add those options.

-- 
 Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
 https://tutanota.com


Feb 14, 2019, 11:59 AM by simon.new...@gmail.com:

> On Thursday, February 14, 2019 at 11:54:28 AM UTC, simon@gmail.com wrote:
>
>> On Thursday, February 14, 2019 at 3:54:04 AM UTC, Marek Marczykowski-Górecki 
>> wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA256
>> > 
>> > On Wed, Feb 13, 2019 at 08:42:10AM -0800, >> simon.new...@gmail.com 
>> > >>  wrote:
>> > > In 3, if i clicked on "block connections" in the Qubes manager firewall 
>> > > section, there was (if memory serves me) an option to block DNS and 
>> > > ICMP. 
>> > > 
>> > > That is not present in R4 (though docs say you can disable DNS and ICMP 
>> > > manually)
>> > > 
>> > > I'm just wondering what the logic behind the removal was? I would have 
>> > > thought that a general user who clicks "block connections" on Qube would 
>> > > not expect the qube to be able to actually send out and receive network 
>> > > packets such as DNS or ICMP. This presents information leakage scenarios 
>> > > (default DNS lookups of given qube) and also potential egress vectors if 
>> > > a qube is ever compromised (DNS tunnelling, ICMP tunnelling). 
>> > 
>> > Let me quote full text you can find on firewall tab there:
>> > 
>> > NOTE: To block all network access, set Networking to (none) on the
>> > Basic settings tab. This tab provides a very simplified firewall
>> > configuration. All DNS requests and ICMP (pings) will be allowed. For
>> > more granular control, use the command line tool qvm-firewall.
>> > 
>> > There is clear message what to do if you want to cut the qube from the
>> > network.
>> > 
>> > - -- 
>> > Best Regards,
>> > Marek Marczykowski-Górecki
>> > Invisible Things Lab
>> > A: Because it messes up the order in which people normally read text.
>> > Q: Why is top-posting such a bad thing?
>> > -BEGIN PGP SIGNATURE-
>> > 
>> > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxk5lQACgkQ24/THMrX
>> > 1yzyBQf+ID5V7ema8i77kmTCnsWfNeSPUQnlTjuQbF1oNZJFNeAwAaqp3FLO+Ljt
>> > Slj7e9KjbPYrxxuW40LIL05G78Yqs/MpZ1mA6/Yfy6J2tvoluucTFvatiHqiodO3
>> > HLqyRSehMXqqzKTHNrLrfLWWyz6ykbP/MmIw1zsxjcXj8RCNuEMc5F4qC6npluWN
>> > cahMNcZLELo4PsrjzhqTrSr0BmlVLDQ5QLwoJGi8wSDGMEIDX3qvwq56wh6O0MgR
>> > J780J043BcrIiAfZorrG+WfpLebkU9uSjmOENxcZQQwz2JmEdod9dU1vUEPSdBY1
>> > EKOq9FhCjMI6De6nNgiMf63Y47CxuQ==
>> > =9dvG
>> > -END PGP SIGNATURE-
>>
>> As I said, I understand the documentation is correct. thats not my question. 
>> My question is why was it removed as an option when the firewall box itself 
>> in network manager says "Deny network access except..." 
>>
>> My point is it is counter intuitive. If it says "deny network access 
>> exccept..." then there is an expectation that it will deny network access 
>> except for what is specified. There used to be tick buttons (allow 
>> updates/allow ICMP/allow DNS), which made it clear on the granular control 
>> there - but were removed in R4. The underlying subsytems you can still do 
>> that, sure. 
>>
>> Can I suggest that the wording "deny network access except..." is changed to 
>> "Deny TCP and UDP access except ..." for the avoidance of any doubt.
>>
>
>
> https://github.com/QubesOS/qubes-manager/pull/153 
> 
>
> -- 
> 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/39615092-155b-4f93-a418-95f7ff95c...@googlegroups.com
>  
> >
>  .
> 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+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/LYgKWnl--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How does Qubes DNS resolving work?

[ashleybrown480]

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

> 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 
> > , 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+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/42007cbd-b403-c239-25cc-78f1d7ac3...@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+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/LYgJrO0--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How does Qubes DNS resolving work?

[ashleybrown480]

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?

-- 
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/LYegJve--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.