I'm having issues with dnsmasq being unable to contact an overridden
nameserver because they're not being sourced from an interface that
has an ipsec policy. For example, I have the following config:
Main Office Router A:
LAN address: 192.168.1.1/24
WAN address: 24.1.2.3
Remote Office Router B:
LAN address: 192.168.2.1/24
WAN address: 64.1.2.3
The two sites are connected by an ipsec tunnel. My internal
nameserver serving the domain "company.local" is at 192.168.1.10.
Since the remote office is on the other side of the world, I want to
use the ISP nameservers for internet resolution, but send all
resolutions for company.local through the tunnel to 192.168.1.10.
When dnsmasq sends the packet to 192.168.1.10, however, it uses the
default route and sends the packet out of the WAN interface and not
through the tunnel. My first thought was to instruct dnsmasq to use
the LAN interface as its source address, such as:
/usr/local/sbin/dnsmasq -l /var/dhcpd/var/db/dhcpd.leases -s
remote.company.local --server=/company.local/[email protected]
Indeed that works, but web UI doesn't allow for that sort of syntax,
afaik.
Failing that, I tried adding a bogus route on Router B in hopes that
the packet will be redirected through the ipsec tunnel before actually
being transmitted on the LAN interface. I added a static route for
192.168.1.10/32 to the (non-existent) gateway 192.168.1.2. This
appears to work, so my problem is resolved for now. It doesn't seem
to be a particularly elegant solution, however.
I thought I'd share this experience with the list in case I missed
something obvious or a solution more apt. My understanding is that
2.0 will support GRE, which would seem to be the right answer. That
or adding support for choosing the source interface in a dnsmasq
domain override.
Any thoughts?
-lee
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Commercial support available - https://portal.pfsense.org
