PF for crosing an rdomain with dnsmasq

[tsombi digitale]

I have a router running OpenBSD-current via snapshots. It has dnsmasq from ports set up and working within one rdomain. That mostly works as expected, but when it needs to make its own outbound queries, it stays limited to that same rdomain. I would like to figure out what to put in pf.conf so that dnsmasq may also reach out via the egress port, which lies on a different rdomain.

(                        PF                       )
if01---+-----rdomain010---=---rdomain022-----egress-----Internet
       |     (dnsmasq)
if02---+
       |
if03---+
       |
if04---+

In dnsmasq I can set the outbound query port so that outbound DNS queries use it as the source port. Thus the outgoing TCP and UDP packets would go aimed at port 53 to the Internet via rdomain22 above. Yet they would be coming from a specific, but arbitrarily chosen, port such as 4567 on rdomain010. I've tried a lot of combinations but not figured out how to do that in PF.

What kind of match or pass rule would I write for pf.conf to add the ability for packets to move like that? The following is quite wrong and does not allow even local DNS queries in dnsmasq:

pass in on rdomain 010 proto {udp,tcp} from 192.168.1.10 \
        to any port 53 set prio (2, 5) rtable 0

[jggimi]

If the dnsmasq daemon is running on the same system as PF, then you can filter by user _dnsmasq.

If it's running on a different system, you could use PF on the source system to identify and then route the packets uniquely, such as through a tunnel between the two systems.

[tsombi digitale]

Thanks. It's running on the same system. Again, the interfaces, and dnsmasq, are in one rdomain and the egress is in another. So what I have currently when it tries to reach the egress is dropped packets when a client makes query that must go to external DNS:

# tcpdump -lnpqi vether1 'port 4567 or port 53'
tcpdump: listening on vether1, link-type EN10MB
15:33:26.552266 192.168.1.12.57934 > 192.168.1.1.53: udp 28
15:33:26.553200 192.168.1.1.4567 > 203.0.113.209.53: udp 28
15:33:31.551477 192.168.1.12.57934 > 192.168.1.1.53: udp 28
15:33:36.559579 192.168.1.1.4567 > 203.0.113.209.53: udp 28
^C
41 packets received by filter
0 packets dropped by kernel

While at the same time on the egress:

# tcpdump -lnpqi vr0 'port 4567 or port 53' 
tcpdump: listening on vr0, link-type EN10MB
^C
35 packets received by filter
0 packets dropped by kernel

The following is syntactically correct but doesn't get the packets from dnsmasq on rdomain 010 out to the net via egress on rdomain 022

pass out on rdomain 010 proto {udp,tcp} from vether1 user { _dnsmasq } rtable 022

[jggimi]

It is my understanding that transiting traffic between rdomains requires the use of pair(4).

[tsombi digitale]

If that is true then maybe I am misunderstanding the position of the DNS cache daemon in all this. I'm not sure this works the way I think it does, but these two seem to be responsible for allowing clients on the LAN to reach the outside:

. . .
match out on $ext inet from vether1:network to ! vether1:network nat-to ($ext)
. . .
pass in quick on rdomain 010 from <ten> to any set prio (2, 5) rtable 022
. . .

So I am guessing there is a corresponding way of having a daemon from rdomain 010 reach the outside too.

[jggimi]

Good questions to ask on misc@