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

Simon Kelley simon at thekelleys.org.uk
Mon Sep 28 16:41:01 BST 2009


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 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
> 

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.





More information about the Dnsmasq-discuss mailing list