<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="monospace">On 4/19/24 00:29, Geert Stappers wrote:<br>
</font>
<blockquote type="cite" cite="mid:ZiHzJ4TpMBrMGXFb@gpm.stappers.nl">
<pre class="moz-quote-pre" wrap="">On Fri, Apr 19, 2024 at 06:20:03AM +0200, Geert Stappers wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Thu, Apr 18, 2024 at 10:07:04PM -0400, Christopher Hill wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi,
I have a question regarding if upstream DNS forwarding can be based on the
source interface? Reading the manual I don't believe it is possible..?
The scenario I have is two VLANs that can talk to each other and both use
dnsmasqfor local name resolution - this works fine. Each VLAN is configured
at the gateway to default route traffic to different VPNs, e.g. VLAN1 out to
VPN1, and VLAN2 to VPN2 respectively, and I would like dnsmasq to forward
requests originating on VLAN1 to the DNS on VPN1, and the same for VLAN2
forwarding to VPN2.
To illustrate:
tun1 VPN1 VPN2 tun2
10.0.1.1 | | 10.0.2.1
+---+---+
|
WAN
|
+-------+--------+
| eth0 |
VLAN 1 <-+-eth1 eth2-+-> VLAN 2
192.168.1.0/24 | (gateway) | 192.168.2.0/24
+----------------+
I would like to do something like the following in the dnsmasq configuration
on the gateway:
server=eth1,10.0.1.1@tun1
server=eth2,10.0.2.1@tun2
i.e. queries arriving on eth1 get sent to 10.0.1.1 via tun1, and queries
arriving on eth2 get sent to 10.0.2.1 via tun 2.
I have considered running two instances (one bound to eth1 and another
to eth2) but that duplicates setup and makes local queries across VLANs more
complicated.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Read the dnsmasq manual and reread the dnsmasq manual.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
--server=[/[<domain>]/[domain/]][<server>[#<port>]][@<interface>][@<source-ip>[#<port>]]
</pre>
</blockquote>
<font face="monospace"><br>
I have tried the below (with and without the interface part)<br>
<br>
--server=10.0.1.1@eth1@192.168.1.1<br>
</font><font face="monospace"> --server=10.0.2.1@eth2@192.168.2.1<br>
</font><br>
<font face="monospace">This results in queries originating from
either VLAN being routed to *both* 10.0.1.1 and 10.0.2.1, it
doesn't "pin" incoming queries to their respective upstream VPN.<br>
<br>
Debug logs show:<br>
<br>
dnsmasq: started, version 2.89 cache disabled<br>
dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus i18n
IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth
cryptohash DNSSEC loop-detect inotify dumpfile<br>
dnsmasq: using nameserver 10.0.1.1#53(via eth1)<br>
dnsmasq: using nameserver 10.0.2.1#53(via eth2)<br>
dnsmasq: read /etc/hosts - 8 names<br>
<br>
Then servicing a query:<br>
<br>
dnsmasq: query[A] google.com from 192.168.1.15 <--
client is on vlan1<br>
dnsmasq: forwarded google.com to </font><font face="monospace">10.0.2.1
<-- sent to vpn2</font><br>
<font face="monospace"> dnsmasq: reply google.com is 172.217.1.110<br>
dnsmasq: query[AAAA] google.com from </font><font
face="monospace">192.168.1.</font><font face="monospace">15<br>
dnsmasq: forwarded google.com to </font><font face="monospace">10.0.2.1</font><br>
<font face="monospace"> dnsmasq: reply google.com is
2607:<a class="moz-txt-link-freetext" href="f8b0:4009:801::200e">f8b0:4009:801::200e</a><br>
<br>
Notice the query came in on VLAN 1 but went to VPN2. :-(<br>
<br>
</font>
</body>
</html>