On 28-Sep-09, at 11:30 AM, Simon Kelley wrote:
Ken Bantoft wrote:
On 28-Sep-09, at 11:12 AM, Simon Kelley wrote:
Ken Bantoft wrote:
On 28-Sep-09, at 11:03 AM, Simon Kelley wrote:
Ken Bantoft wrote:
Hi,
I've run into a case where I'd like dnsmasq to forward queries
over an IPSec VPN tunnel to nameservers on the far side, but
this doesn't seem to work as expected.
I've got 2 Interfaces - br-lan (192.168.1.1) and ppp0 (PPPoE -
216.x.x.x). IPsec is terminated on the same machine, so it has
a tunnel from 192.168.0.0/24 to 10.0.0.0/8.
dnsmasq is set to forward all queries to 10.x.x.10 and 10.x.y.
10 nameservers, which are across the tunnel in the
datacenter. What I'm seeing with tcpdump is the requests
going out the ppp0 interface, with the 216.x.x.x IP address.
I've tried a variety of options (bind- interfaces, listen-
address), as I really want dnsmasq to bind only to the br-lan
interface, and use that address as the Source IP for the
forwarded queries, but no combination I've tried does the trick.
Any suggestions?
Stop dnsmasq from looking for servers in /etc/resolv.conf with
no-resolv
in /etc/dnsmasq.conf and then specify them using "server=" lines
in /etc/dnsmasq.conf like this
server=10.x.x.10@br-lan
server=10.x.y.10@br-lan
We've been here before....
That was my 1st step... so I do see it sending the requests to
10.x.x.10 and 10.x.y.10 as expected - just out the wrong
interface...
Ken
If this a routing problem? Dnsmasq can control the source address
of the packets, and the destination address is straightforward,
but it can't control how the kernel routes the packets: do you
have a route to 10.0.0.0/8 via the tunnel?
No route - it's Linux Kernel netkey IPsec stack, so no nice ipsec0
interface - it's all done with the ip xfrm policies... which might
be causing some grief, but it's difficult to tell. Any debugging
options for dnsmasq to have it printout the packets before it puts
them on a wire?
Oh, you're well outside my comfort zone now. No debugging options,
but strace might help - you can see the system calls that send the
packets. You can set the source address for packets with something
like:
[email protected], that might work where binding to an
interface doesn't.
Yea, I was trying that... and depending on the options I'd either see
the packet go out ppp0 with the External IP, or see no packet at all
(!). I'll keep digging and let you know what I find.... just
surprised no one else has run into this yet. My workaround to-date
has been to have dnsmasq issue the 10.x.x.10 IP via DHCP to the
clients, which is fine until the IPsec tunnel goes down and then none
of the clients have DNS service anymore :(
Ken
