Qubes networking problem / question ( Qubes 4.1 , vif / eth IP address assignment problem)

User Support General
, , ,
1

Okay, so long story short I’m configuring some stuff in a custom VPN Qube.
90% of stuff works but I need dnscrypt to be listening on localhost and eth0

Normally I’d do something like

listen_addresses = [‘127.0.0.1:53’, ‘eth0IP:4444’]

in the dnscrypt config (that’s how I did the tricks back in Qubes 3.x days

Now porting my setup to 4.1 (it’s been a while since I needed that particular VPN setup) I notice that Vif and eth0 now seem to have same IP

sudo ifconfig in the Qube gives stuff like

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.137.0.30 netmask 255.255.255.255 broadcast 0.0.0.0
inet6 fe80::2ee:eeff:fe5d:6c10 prefixlen 64 scopeid 0x20
ether 00:ee:ee:5d:6c:10 txqueuelen 1000 (Ethernet)
RX packets 189 bytes 61227 (59.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 197 bytes 23684 (23.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 34 bytes 3415 (3.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 34 bytes 3415 (3.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

vif59.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.137.0.30 netmask 255.255.255.255 broadcast 0.0.0.0
inet6 fe80::fcff:ffff:feff:ffff prefixlen 64 scopeid 0x20
ether fe:ff:ff:ff:ff:ff txqueuelen 1000 (Ethernet)
RX packets 16 bytes 1020 (1020.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 576 (576.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I presume this is made possible by namespaces

However, dnscrypt doesn’t quite “roll easily” with network namespaces (well, not without some dire messing with the systemd unit that starts it up, which is a PITA)

Qubes’s own networking documentation is fairly frugal Networking | Qubes OS

Where can I find out more about new “IP assignment situation” in qubes, the way network namespaces are set up, etc so I can try and sort out how to adjust my dnscrypt shenanigans to the “new normal” ?

2

There are no multiple namespaces in a VM’s networking setup. On Linux, you can set an IP on two or three network interfaces, no problem. This is a standard feature of vanilla Linux.

What is dnscrypt’s problem with this?

3

Okay wait a second. in all of my qubes both vif and eth0 have same ip (v4)

How can that work out without namespaces ?

(The networking works)

I included ifconfig output in the original post

4

Hello,

maybe I didn’t understand your problem already, but dnscrypt runs fine on 4.1.

I used it on a standalone with pihole.

My dnscrypt is listen on 127.0.0.1:530 and iptables does the rest.

#!/bin/bash

# Flush the PR-QBS chain
iptables -t nat -F PR-QBS

# Add a rule that redirects all the DNS traffic to localhost:53
iptables -t nat -I PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to-destination 127.0.0.1

# Enable the traffic coming from the virtual interfaces
# to be forwarded to the loopback interface
# enabling the route_localnet flag on them
find /proc/sys/net/ipv4/conf -name "vif*" -exec bash -c 'echo 1 | sudo tee {}/route_localnet' \;

So if the dns-qube is a network qube, it NATs all passing-through DNS traffic to localhost.


#!/bin/sh

# This script is called at AppVM boot if this AppVM has the qubes-firewall
# service enabled. It is executed after the empty chains for the Qubes firewall
# are created, but before rules for attached qubes are processed and inserted.
#
# It is a good place for custom rules and actions that should occur when the
# firewall service is started.
# 
# Executable scripts located in /rw/config/qubes-firewall.d are executed
# immediately before this qubes-firewall-user-script.

# Allow access to Pihole WebGUI from AppVMs
iptables -I INPUT -s 10.137.0.0/24 -j ACCEPT
# Allow access to Pihole WebGUI from DispableVMs
iptables -I INPUT -s 10.138.0.0/16 -j ACCEPT

# Add a rule that accepts the traffic coming to localhost
# from XEN's virtual interfaces on port 53
iptables -I INPUT -i vif+ -p udp --dport 53 -d 127.0.0.1 -j ACCEPT

Edit: So flow is: any dns traffic (e.g. 10.139.1.1 or 1.1.1.1. or whatever) wanna flow through on UDP:53, but gets NATed to pihole (127.0.0.1:53) pihole calls his upstream (dnscrypt @ 127.0.0.1:530) and does the resolve.

5

You see, for a number of reasons that have to do with various aspects of my setup I want dnscrypt to listen on eth0’s IP on a different port (long story)

It was extremely trivial to achieve when I came up with this setyp many years ago.

That ipv4 is same between vif and eth0 makes it harder

Also I’d like more understanding of how it works now

6

It isnt that unusual to have the same IP on different NIC Why does it
make it harder?

It might help if you made it clear what you dont understand.
Look at the routing, and you’ll see that it’s done by device - does
that make it clearer?

7

It works like the vif is downstream (to connected qubes) and eth0 is upstream (to internet).

So why can’t your dnscrypt not just listen on 127.0.0.1 and you use iptables NAT to foward eth0:4444 to 127.0.0.1 too, if dnscrypt really can’t handle the listen configuration for eth0?

8

Why wouldn’t that work according to your theories?

What made you assume an IP address can only be assigned to a single iface?

9

[irrelevant comment retracted]