On Fri, Feb 10, 2017 at 04:10:06AM -0800, Joe Ruether wrote: > On Thursday, February 9, 2017 at 10:21:26 AM UTC-5, Unman wrote: > > On Thu, Feb 09, 2017 at 04:32:12AM -0800, Joe Ruether wrote: > > > Hello! > > > > > > I am trying to set up a proxy vm that will redirect DNS requests to a > > > local DNS server, for the purposes of adblocking. > > > > > > Here is the setup: > > > > > > internet <-> sys-net <-> sys-firewall <-> MY_PROXYVM <-> > > > appvm_with_firefox > > > > > > I have created a proxyvm based on a debian-8 template, and have installed > > > PiHole (https://pi-hole.net/) as an adblocker. PiHole works by starting a > > > DNS server (dnsmasq) and rejecting any dns queries to domains that serve > > > ads. > > > > > > If (in the proxyvm) I set the contents of /etc/resolv.conf to 127.0.0.1 > > > and open firefox (in the proxyvm), I can verify that the adblocker is > > > working correctly. > > > > > > The issue I am having is when I used the proxyvm as the netvm for another > > > appvm. Without any other changes, my appvm's firefox has internet access, > > > but the adblocker has no effect. Of course, some additional setup is > > > needed, but I'm not exactly sure how to do that. > > > > > > I'm not very good with iptables, and every attempt I have made to > > > redirect DNS to 127.0.0.1 in the proxyvm has failed (and caused both the > > > proxyvm and the appvm to lose the ability to browse). Here are the > > > commands I ran (in the proxyvm): > > > > > > #!/bin/bash > > > DNS=127.0.0.1 > > > NS1=10.137.4.1 > > > NS2=10.137.4.254 > > > iptables -t nat -A PR-QBS -d $NS1 -p udp --dport 53 -j DNAT --to $DNS > > > iptables -t nat -A PR-QBS -d $NS1 -p tcp --dport 53 -j DNAT --to $DNS > > > iptables -t nat -A PR-QBS -d $NS2 -p udp --dport 53 -j DNAT --to $DNS > > > iptables -t nat -A PR-QBS -d $NS2 -p tcp --dport 53 -j DNAT --to $DNS > > > > > > --- > > > > > > I pieced this together from what I could find from the VPN documentation > > > on the qubes website as well as the contents of > > > /usr/lib/qubes/qubes-setup-dnat-to-ns > > > > > > Running the qubes-setup-dnat-to-dns script by itself after changing > > > /etc/resolv.conf (all this on the proxyvm) didn't seem to have any impact. > > > > > > So! My question is, am I going about this correctly? I think I need to > > > modify the iptables in the proxyvm to redirect any incoming (from the > > > appvm) DNS queries to 127.0.0.1, while still allowing outgoing (to the > > > internet, from the proxyvm) DNS queries to get out. Along with this, I > > > think I need to ensure that there are rules that allow all other traffic > > > to pass through unhindered. > > > > > > Or is there a different, qubes-specific way of handling DNS that I should > > > be using? After inspecting the sys-firewall ipconfig and iptables, it is > > > clear that something behind-the-scenes is happening where an additional > > > NIC is created for each attached appvm, and the iptables are being > > > populated automatically somehow. I'm not sure how the proxyvm is supposed > > > to get the addresses of the appvm and sys-firewall (my script above had > > > addresses hardcoded). > > > > > > Thank you for any help! If I get all this working, I'm planning on making > > > a Salt file that can create the adblocking proxyvm. > > > > > > > I don't see any reason why this shouldn't work. > > I wouldn't be so specific in the nat rules but that's your call. Just > > protocol and post would suffice. > > > > One obvious point is that you are ADDING those rules to the end of the > > PR-QBS chain without flushing it first. If you already have redirect > > rules there they will trigger first. > > What does your nat table look like after you run that script? > > > > Another point may be that you don't have an incoming rule in the INPUT > > chain allowing inbound traffic to the DNS ports. Unless you've changed > > this the default rule will block inbound traffic from any vif interface. > > So you need to ensure you are allowing that traffic with an: > > iptables -I INPUT -i vif+ -p udp --dport 53 -j ALLOW > > > > Finally, you need to consider the effects of the qubes-firewall and > > qubes-netwatcher services. > > If you want to retain these you can use > > /rw/config/qubes-firewall-user-script to override the automatic Qubes > > configuration and insert your own iptables rules. > > You can also use rc.local to set initial iptables rules. > > Remember to make those files executable if you want to use them. > > > > Most of this is in the docs, although not easy to find. > > > > Hope this helps > > > > unman > > Thank you for your help, I have more information about my configuration > below. I am confident that I have an iptables issue, but I can't seem to > figure out which rules need to be added. > > ifconfig: > > eth0 Link encap:Ethernet HWaddr 00:16:3e:5e:6c:01 > inet addr:10.137.2.3 Bcast:10.255.255.255 Mask:255.255.255.255 > inet6 addr: fe80::216:3eff:fe5e:6c01/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:6830 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6436 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:4972238 (4.7 MiB) TX bytes:1381735 (1.3 MiB) > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:65536 Metric:1 > RX packets:241350 errors:0 dropped:0 overruns:0 frame:0 > TX packets:241350 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1 > RX bytes:17164926 (16.3 MiB) TX bytes:17164926 (16.3 MiB) > > vif99.0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff > inet addr:10.137.4.1 Bcast:0.0.0.0 Mask:255.255.255.255 > inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:27475 errors:0 dropped:0 overruns:0 frame:0 > TX packets:4201 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:32 > RX bytes:1838038 (1.7 MiB) TX bytes:3767962 (3.5 MiB) > > Here is my script with the modifications you suggested: > > #!/bin/bash > > DNS=127.0.0.1 > NS1=10.137.4.1 > NS2=10.137.4.254 > > iptables -t nat -F PR-QBS > > iptables -t nat -A PR-QBS -d $NS1 -p udp --dport 53 -j DNAT --to $DNS > iptables -t nat -A PR-QBS -d $NS1 -p tcp --dport 53 -j DNAT --to $DNS > > iptables -t nat -A PR-QBS -d $NS2 -p udp --dport 53 -j DNAT --to $DNS > iptables -t nat -A PR-QBS -d $NS2 -p tcp --dport 53 -j DNAT --to $DNS > > iptables -I INPUT -i vif+ -p udp --dport 53 -j ACCEPT > iptables -I INPUT -i vif+ -p tcp --dport 53 -j ACCEPT > > # Show the table > iptables -t nat -L -v -n > > # Is this needed? > # echo 1 > /proc/sys/net/ipv4/ip_forward > > --- > > Here are the results of iptables -L -v -n after running the script: > > Chain INPUT (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT tcp -- vif+ * 0.0.0.0/0 0.0.0.0/0 > tcp dpt:53 > 0 0 ACCEPT udp -- vif+ * 0.0.0.0/0 0.0.0.0/0 > udp dpt:53 > 0 0 DROP udp -- vif+ * 0.0.0.0/0 0.0.0.0/0 > udp dpt:68 > 94520 8805K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 > ctstate RELATED,ESTABLISHED > 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 > > 52952 2754K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 > > 37 4454 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 > reject-with icmp-host-prohibited > > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > 4884 3798K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 > ctstate RELATED,ESTABLISHED > 0 0 ACCEPT all -- vif0.0 * 0.0.0.0/0 0.0.0.0/0 > > 0 0 DROP all -- vif+ vif+ 0.0.0.0/0 0.0.0.0/0 > > 80 5672 ACCEPT udp -- * * 10.137.4.11 > 10.137.2.1 udp dpt:53 > 0 0 ACCEPT udp -- * * 10.137.4.11 > 10.137.2.254 udp dpt:53 > 0 0 ACCEPT tcp -- * * 10.137.4.11 > 10.137.2.1 tcp dpt:53 > 0 0 ACCEPT tcp -- * * 10.137.4.11 > 10.137.2.254 tcp dpt:53 > 0 0 ACCEPT icmp -- * * 10.137.4.11 0.0.0.0/0 > > 0 0 DROP tcp -- * * 10.137.4.11 > 10.137.255.254 tcp dpt:8082 > 39 2556 ACCEPT all -- * * 10.137.4.11 0.0.0.0/0 > > > Chain OUTPUT (policy ACCEPT 1613 packets, 120K bytes) > pkts bytes target prot opt in out source > destination > > --- > > And finally, here is netstat -pan | grep 53 to show the DNS server running: > > tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN > 681/dnsmasq > tcp6 0 0 :::53 :::* LISTEN > 681/dnsmasq > udp 0 0 0.0.0.0:5353 0.0.0.0:* > 628/avahi-daemon: r > udp 0 0 0.0.0.0:53 0.0.0.0:* > 681/dnsmasq > udp6 0 0 :::5353 :::* > 628/avahi-daemon: r > udp6 0 0 :::53 :::* > 681/dnsmasq > unix 2 [ ACC ] STREAM LISTENING 15533 > 1274/qrexec-fork-se /var/run/qubes/qrexec-server.user.sock > unix 3 [ ] STREAM CONNECTED 11905 653/meminfo-writer > > unix 3 [ ] STREAM CONNECTED 14533 1233/nm-applet > > unix 3 [ ] STREAM CONNECTED 14534 883/Xorg > @/tmp/.X11-unix/X0 >
You dont need to reset forwardijng as it is already enabled - check the value of /proc/sys/net/ipv4/ip_forward What I would really like to see would be the output AFTER you attempt a client conenction. use iptables -L with the -Z option to zero the counters, then attempt a connection and look at the output of the nat and filter tables. I suspect you will immediately see what the problem is. -- 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/20170210232148.GD9080%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
