Has anyone gotten dnsmasq or samba to work?

[crane...@gmail.com]

I've gotten lighttpd to work and used the same principles (with the iptables) with dnsmasq but cannot get it to work. Neither can I get samba to work.

Is there any documents on either of these?

[Alex Dubois]

> On 29 Nov 2014, at 03:34, crane...@gmail.com wrote:
>
> I've gotten lighttpd to work and used the same principles (with the iptables) with dnsmasq but cannot get it to work. Neither can I get samba to work.

I've done a blog post on unbound+DNSCrypt (caching+resolver)
http://bowabos.blogspot.co.uk/2013/11/how-to-set-up-dnscrypt-proxy-on-qubes-os.html?m=1

Same principles can be applied to your daemons.

>
> Is there any documents on either of these?
>

> --
> 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/2ef5db56-45fe-4387-a77b-a918725cc3dd%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[crane...@gmail.com]

On Saturday, November 29, 2014 3:00:48 AM UTC-5, Alex Dubois wrote:
> I've done a blog post on unbound+DNSCrypt (caching+resolver)
> http://bowabos.blogspot.co.uk/2013/11/how-to-set-up-dnscrypt-proxy-on-qubes-os.html?m=1
>
> Same principles can be applied to your daemons.

I read through your blog and am a little confused. It seems most of what you did was in your appvm - I used dnsmasq already installed in fedora-20-x86-web (being a clone of the original and only used as a template to webvm). I tested my dnsmasq.conf via term in webvm nslookup.

nslookup desktop
Server: 10.137.2.1
Address: 10.137.2.1#53
Name: desktop
Address: 192.168.15.46

Which is all correct.
In netvm rc.local after
/sbin/iptables -t nat -A PREROUTING -i enp0s0 -p tcp --dport 80 -d 192.168.15.146 -j DNAT --to-destination 10.137.2.16
Which works for lighttpd, I added this
/sbin/iptables -t nat -A PREROUTING -i enp0s0 -p tcp --dport 53 -d 192.168.15.146 -j DNAT --to-destination 10.137.2.16
And
/sbin/iptables -t nat -A PREROUTING -i enp0s0 -p udp --dport 53 -d 192.168.15.146 -j DNAT --to-destination 10.137.2.16

And similar in firewallvm, and webvm.

I did sudo iptables -t nat -L -n -v --line-number and sudo iptables -L -n -v --line-number in netvm and firewallvm and the counters did go up.
In netvm it started with 10pkts and after nslookup from another computer went to 13pkts
In firewallvm it started with 3pkts and after was 6pkts.
In WebVM it started with 16pkts and after was 19pkts.

So that part is working, but I'm sure dnsmasq sends out it's answer via other ports and that's why the other computer isn't getting any answers. Can you help me out here?

[Alex Dubois]

> On 29 Nov 2014, at 20:27, crane...@gmail.com wrote:
>
>> On Saturday, November 29, 2014 3:00:48 AM UTC-5, Alex Dubois wrote:
>> I've done a blog post on unbound+DNSCrypt (caching+resolver)
>> http://bowabos.blogspot.co.uk/2013/11/how-to-set-up-dnscrypt-proxy-on-qubes-os.html?m=1
>>
>> Same principles can be applied to your daemons.
>
>
> I read through your blog and am a little confused. It seems most of what you did was in your appvm - I used dnsmasq already installed in fedora-20-x86-web (being a clone of the original and only used as a template to webvm). I tested my dnsmasq.conf via term in webvm nslookup.

OK, yes this is a good alternative (remember to patch your cloned template).

>
> nslookup desktop
> Server: 10.137.2.1
> Address: 10.137.2.1#53
> Name: desktop
> Address: 192.168.15.46

Maybe I miss understood something but this test is not testing dnsmasq but the normal DNS in QubesOS.
You are going to have to use a /rw/config/rc.local script to copy a /rw/config/resolv.conf to /etc/resolv.conf on start up of your webvm with
nameserver 10.137.2.x in it.
You could set in the template the IP of your webVM but you'll break the capability to update your template as DNS would be broken for it.

>
> Which is all correct.
> In netvm rc.local after
> /sbin/iptables -t nat -A PREROUTING -i enp0s0 -p tcp --dport 80 -d 192.168.15.146 -j DNAT --to-destination 10.137.2.16
> Which works for lighttpd, I added this
> /sbin/iptables -t nat -A PREROUTING -i enp0s0 -p tcp --dport 53 -d 192.168.15.146 -j DNAT --to-destination 10.137.2.16
> And
> /sbin/iptables -t nat -A PREROUTING -i enp0s0 -p udp --dport 53 -d 192.168.15.146 -j DNAT --to-destination 10.137.2.16
>
> And similar in firewallvm, and webvm.
>
> I did sudo iptables -t nat -L -n -v --line-number and sudo iptables -L -n -v --line-number in netvm and firewallvm and the counters did go up.
> In netvm it started with 10pkts and after nslookup from another computer went to 13pkts
> In firewallvm it started with 3pkts and after was 6pkts.
> In WebVM it started with 16pkts and after was 19pkts.

OK sounds good (FORWARD policy too?) as I understand yes.

>
> So that part is working, but I'm sure dnsmasq sends out it's answer via other ports and that's why the other computer isn't getting any answers. Can you help me out here?

Answers are traveling back using connection tracking (rule with ESTABLISHED, RELATED)...
However your dnsmasq process is also a DNS client requesting on behalf of the clients who requested to him. This imply that you need to make sure traffic from webvm can go out to do DNS queries. Care must be taken to ensure the policies to allow the 2 flows do not interfere with one and another and preceed QubesOS 's one.

Maybe some visibility in your dnsmasq conf would shine some light on what you are trying to achieve and what is missing. which resolver dnsmasq points to?

What you've done so far seems good. Check also your dnsmasq logs...

>
> --
> 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/96307bcf-3508-4048-8aaa-9c2d2685f5aa%40googlegroups.com.

[crane...@gmail.com]

On Saturday, November 29, 2014 6:11:26 PM UTC-5, Alex Dubois wrote:

>
> OK, yes this is a good alternative (remember to patch your cloned template).

My dnsmasq.conf was done in the cloned template.

> Maybe I miss understood something but this test is not testing dnsmasq but the normal DNS in QubesOS.

I doubled checked, and you're right, it got 2 right answers out of a dozen "wrong" answers.

Dnsmasq is not running. It errors out due to dnat (or something) is already using port 53...

> You are going to have to use a /rw/config/rc.local script to copy a /rw/config/resolv.conf to /etc/resolv.conf on start up of your webvm with
> nameserver 10.137.2.x in it.
> You could set in the template the IP of your webVM but you'll break the capability to update your template as DNS would be broken for it.

I'll have to remember that...

> Answers are traveling back using connection tracking (rule with ESTABLISHED, RELATED)...
> However your dnsmasq process is also a DNS client requesting on behalf of the clients who requested to him. This imply that you need to make sure traffic from webvm can go out to do DNS queries. Care must be taken to ensure the policies to allow the 2 flows do not interfere with one and another and preceed QubesOS 's one.
>
> Maybe some visibility in your dnsmasq conf would shine some light on what you are trying to achieve and what is missing. which resolver dnsmasq points to?
>

I had to have dnsmasq use port 110.
In my dnsmasq.conf file, it contains a list of "bad sites" and for their ipaddresses, it point back to itself so that lighttpd can answer the call.

It now works.