Ken Bantoft wrote:
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
I can't see how it can be a a dnsmasq-specific thing: it has to be down
to the routing to 10.x.x.10. What happens to ICMP packets to that
address sent by "ping"?
Cheers,
Simon.
