[Dnsmasq-discuss] dnsmasq forwarding queries over VPN/IPSec

Ken Bantoft ken at netfunctional.ca
Mon Sep 28 16:34:36 BST 2009



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 at br-lan
>>>>> server=10.x.y.10 at 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:
>
> server=10.x.x.10 at 192.168.0.1, 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








More information about the Dnsmasq-discuss mailing list