Can DNS be passed over a site to site PPTP VPN tunnel?

Yes, DNS queries can be routed across a VPN tunnel, of any type.

Are you sure DNS queries are being routed across the tunnel?

Do you have firewall rules allowing DNS queries?  Normal DNS queries use UDP, source port >1023 and dst. port eq 53.

dns could use tcp/udp port 53. Make sure your fw isnt blocking these.

also.. when you query your server through the tunnel, how are you doing this?

nslookup www.whatever.com dns_server

try doing that. That will query the dns_server whose IP is on the other side of the tunnel. If that works you know the queries are going through the tunnel. Then your problem could be the fact that the clients on the other side are not set to use the server that is through the tunnel

I am doing this "nslookup www.tsn.ca 10.0.0.2" with 10.0.0.2 being a server across the tunnel and it fails. The weird thing is that I have just found out it works the opposite way.

I have two networks

10.0.0.0/24 and 10.0.1/24

They are connected via gateway to gateway VPN using Linksys RV016 devices.

If I try "nslookup www.tsn.ca 10.0.0.2" from a system on the 10.0.1.0/24 network it won't work. (10.0.0.2 is a DNS server).

If I try "nslookup www.tsn.ca 10.0.1.2" from a system on the 10.0.0.0/24 network it does work. (10.0.1.2 is a DNS server).

So it definitely sounds like a firewall policy but when I look at the firewall policy on both ends of the VPN connection they are identical. Strange.

I even get the following in the system logs on my RV016:

Dec 30 18:41:14 2009          Connection Accepted          UDP 10.0.1.52:1277->10.0.0.2:53 on ixp2

Is your RV016 on "your side" or "the other side"?

If your side, what does the other side say?

Are you able/authorized to install a packet capture utility on 10.0.0.2?  I prefer Wireshark, but if this is a Windows server you can install MS NetMon if you would rather use MS software.  Just to make sure that 10.0.0.2 is getting the request and responding.

I own both sides so I control them both and they are setup identical. I have tried running wireshark on 10.0.0.2 and I don't even see the UDP packets arrive which is why I think it is the RV016 dropping it but I can't figure out why and with full logging on all it says is the Connection Accepted message. If I switch netcat to run on UDP port 52 or 54 then I can connect and everything is fine but if netcat is on 53 it gets blocked. Very strange.

yeah make sure your server on the other side is working okay. Maybe do the same nslookup from a host on the other side. This way we can make sure that the server isnt an issue.

that is very strange indeed.
im not familiar with RV016. it seems like it has some basic firewalling. can you make sure there isnt anything there that is blocking is.

Also, when you tried netcat, i presume your ran it on a host other than your dns server. this just rules that isnt something to do with that specific host but all hosts running port 53

Yes I ran it on 3 different hosts on port 53 with the same result. I just tried my DNS server to see if is working:

Windows IP Configuration


Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . : teksmed.local
        IP Address. . . . . . . . . . . . : 10.0.0.80
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 10.0.0.1

C:\temp\nc111nt>nslookup
Default Server:  borg.teksmed.local
Address:  10.0.0.2

> www.tsn.ca
Server:  borg.teksmed.local
Address:  10.0.0.2

Non-authoritative answer:
Name:    www.tsn.ca
Addresses:  199.246.67.211, 199.246.67.21

I even just tried updating the firmware on both of my RV016 (they were the same version to begin with) and now I am at the latest firmware with the same problem.

I also just tried disabling the firewall on my RV016 and got the same result. Called Linksys support and of course they gave me the standard line "Your device is no longer under warranty".

Is there a firewall on 10.0.0.2 that could be blocking traffic for IP hosts not on the 10.0.0.0/24 subnet?

I am going to assume not, because even if there was a firewall, Wireshark should have seen the packet coming in since it is operating at layer 2 and not layer 3.

Is there another firewall by chance between the RV016 and 10.0.0.2?

Yes, grasping at straws.

I run the entire network (it is relatively small) and I can't think of anything else that would be firewalling between the RV016 and 10.0.0.2. The weird thing is that it just seems to be UDP port 53. If I run netcat on any other UDP port it works fine and is only one direction. I do have a managed switch that the RV016 and 10.0.0.2 are connected to so I will see if maybe I can setup a mirror port to see if the traffic can be seen on the switch ports. Other than that I really don't know where to go.

Are your internal DNS being queired?
You would need to setup the internal DNS to synchronize the DNS data with the remote One.
I.e. allow the transfer of DNS zones from the remote to the local in both directions.

The issue is that your workstations do not know of the other DNS server all they seem to do is send the request to your local DNS.  The local DNS in turn either forwards the requests or does the work. Depending on the DNS server you are using, you might be able to setup a query specific forwarder/stub zone.
i.e.
myremotedomain.local { forwarder to remote_dns_IP}

O.K, I'm a bit confused, what does netcat have to do with this?

OK perhaps I should explain where I am at now with this issue to clarify things. My initial thought was that it was only DNS queries that were being blocked across the VPN link but now it just appears as though it is anything destined for UDP port 53. To summarize here is my network configuration

RV016.1 <-> INTERNET <-> RV016.2

The LAN on the RV016.1 side is 10.0.0.0/24
The LAN on the RV016.2 side is 10.0.1.0/24

The DNS server is on the RV016.1 side and is 10.0.0.2. I am trying to modify the DNS configuration for workstation 10.0.1.50 to use this DNS server.

I have an IPSEC VPN tunnel established between the two RV016 devices. From workstations in either LAN I can PING workstations in the other. I can ping 10.0.0.2 from 10.0.1.50 without issues. However, when I setup 10.0.0.2 as the DNS server the requests fail:

root@mail:~# nslookup www.tsn.ca 10.0.0.2
;; connection timed out; no servers could be reached

So at first I thought that perhaps it is UDP being blocked over the VPN so I setup a netcat listener on 10.0.0.2 on UDP port 54 (because 53 was obviously in use) and I was able to send packets from 10.0.1.50 to UDP port 54 which showed that UDP was allowed. I then put netcat on another server that wasn't running the DNS service and started up a listened on UDP port 53. When I tried to send packets to this listener they never made it through. I then changed to other UDP ports to test them and they all worked. It was just UDP port 53 that wasn't working. I then changed the direction. I setup a netcat listener on UDP port 53 on 10.0.1.50 and was able to send packets to it from 10.0.0.2.

I just now tried an additional test that was interesting. I sent UDP packets from 10.0.0.2 to 10.0.1.50 on port 53 and everything was fine. I then forced the source port on 10.0.0.2 to be 53 and the destination port on 10.0.1.50 to be 53 (10.0.0.2:53 -> 10.0.1.50:53) and the words I type on 10.0.0.2 get sent to 10.0.1.50 however any response I type on 10.0.1.50 doesn't make it back to 10.0.0.2 which, in my opinion, eliminates any stateful firewall as being the cause because most stateful firewalls would consider these return packets as being part of the original UDP pseudo connection.

looks like you've covered everything. I cant think of anything that would block 53.

Just one other test. Can you try netcat on ports 139 and 445 and see if those work

I'll have to look at the RV016 to see how to configure the firewall.  However, its weird that it works in one direction and not the other if they are both setup the same.  Well I am assuming that some of the rules are "mirrors".

also.. one other thing to try. Are you passing DNS server information via PPTP to the other side? If not, can you try doing this? I'm wondering if the PPTP server has some kind of implicit deny if you are not passing DNS server information via PPTP

I tried one additional thing. The RV016 also acts as a DNS server for hosts connected to it so I tried using the RV016 on the other end (10.0.0.1) as the DNS server and it was successful which means the DNS query is getting through to the other side at least. But I still can't figure out why it won't pass the query on to other servers on the network.

As for firewall rules. Both sides of the connection are identical with no rules other than the default ones created by the device.

Just noticed something else very weird. My two RV016s are 10.0.0.1 and 10.0.1.1

If I try to do a reverse lookup for 10.0.0.2 on my two RV016s I get something strange:

nslookup 10.0.0.2 10.0.0.1

Name: FWDR-2.FWDR-0.FWDR-0.FWDR-10
Address: 10.0.0.2

nslookup 10.0.0.2 10.0.1.1
*** [10.0.1.1] can't find 10.0.0.2: Non-existent domain

Anyone have any idea what the FWDR-2.FWDR-0.FWDR-0.FWDR-10 would mean??

can you traceroute to 10.0.0.2 from the other side of the tunnel.

C:\Documents and Settings\Administrator.CARP-DC>tracert 10.0.0.2

Tracing route to BORG [10.0.0.2]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.0.1.1
  2     *        *        *     Request timed out.
  3   105 ms   105 ms   105 ms  BORG [10.0.0.2]

Trace complete.

What does tracert use to resolve 10.0.0.2 to BORG in this case?? It can't be DNS because here is what happens if I try to do a nslookup on 10.0.0.2 directly after:

C:\Documents and Settings\Administrator.CARP-DC>nslookup 10.0.0.2
DNS request timed out.
    timeout was 2 seconds.
*** Can't find server name for address 10.0.0.2: Timed out
Server:  UnKnown
Address:  10.0.0.2

DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

It looks like something is making up a PTR record for 10.0.0.2.

If you notice it has the IP address 10.0.0.2 in it backwards with "FWDR-" in front.  However I have no clue what could be generating this.

You could run a packet capture and see what IP address is returning that.

The problem is that your lookup is being forwarded out by your DnS server presumably to your providers DNS.  This is likely where you are getting this response.

10.0.0.0/8
172.16.0.0/12
192.168.0.0/24

publicly they are blackholed.
Use www.arin.net and lookup an IP in any of these ranges.

The information for these IPs comes from "local" DNS server your own or your upstream providers.  It all depends on how the DNS service on the RV016 router works.  I.e. it gets a DHCP/static IP from the provider and possibly gets or you've entered the IP of the DNS servers.  The dns service on the RV is likely a forwarder i.e. when it gets a request  it forwards it along.

Do you have servers that have local DNS services running?

Arnold, the server in question 10.0.0.2 is my DNS server and is local.

what happens if you do:

     nslookup - 10.0.0.2

On your tracert there was a timeout on the second hop.  Should the device on the 2nd hop have responded?

Are you 100% sure that traffic for the 10.0.0.0/24 subnet is being sent over the VPN tunnel?

The reason I am asking is that some ISP's use private IP addresses within their own network and it is possible that they have things incorrectly setup and the 10.0.0.2 that is responding is not your 10.0.0.2, but your ISP's.

Yes I am 100% sure that traffic for 10.0.0.0/24 is being sent over the tunnel. If I setup a netcat listern on the same server (10.0.0.2) on UDP port 52 or 54 I can "connect" to it from 10.0.1.0/24 over the VPN tunnel. The only thing that doesn't seem to get through is UDP port 53 and that only happens in one direction. If I setup a netcat listener on any machine on 10.0.1.0/24 on UDP port 53 then I can "connect" to it from 10.0.0.2 as long as I don't use a source port of 53 on the 10.0.0.0/24 side.

The only thing I can think of is to run a packet capture to see what IP is returning turning the weird host names (BORG and FWDR-2.FWDR-0.FWDR-0.FWDR-10).

By chance could do you do any port forwarding on either of the routers?

The problem is that the local DNS server has no way to resolve 10.x.x.x IP unless the local DNS server has the zone defined as a replica from the other DNS server or as a master with configured data. Or if you have configured a forwarder zone.  I.e. requests for 0.0.10.in-addr.arpa should be referred/forwarded to 10.0.0.2 and similarly on the other end 1.0.10.in-addr.arpa should be referred/forwarded to 10.0.1.2.
This way as long as the tunnel is up, a response to nslookup 10.0.1.2 will be provided based on the DNS records on 10.0.1.2.
Check whether you have your DNS server query limited. Do you have a windows or a linux based name server? (allow-query setting)

Sorry, maybe I should have been more clear. BORG is the correct server name. What I can't figure out is why tracert is able to resolve 10.0.0.2 back to BORG but nslookup can't??

I do have port forwarding enabled on the routers but nothing for UDP 53, actually I have no UDP ports forwarded at all. Just a couple of TCP ports.

Well I just check and nslookup and tracert both use UDP, I was thinking that maybe nslookup used TCP 53 for it name resolution.

Again, a quick packet capture will tell you where they are getting the resolution from.

Now, one thing I do know is that tracert will do "normal" name resolution, that is it will look at the local host file and nslookup will not look at the local host file.

So could the PC you are doing this from have "10.0.0.2 BORG" in its host file?

OK I just did a packet capture of the traceroute and I figured out why it is able to resolve 10.0.0.2 back to BORG. Traceroute will actually use a NetBIOS Name Service query to the host which will return its name and I allow NetBIOS over the VPN link.

Looks like I am still stuck.

What firmware level are you running on the RV016s?

O.K, just to make sure, you setup the site-to-site VPN basically like it is done here:

     http://www.cisco.com/en/US/products/ps9923/products_qanda_item09186a0080a36527.shtml

Each location has its own name server or are they each using the RV016 as the name server?

You need to setup a forwarding for the specific zones or setup master/slave zone.  i.e. the server 10.0.0.2 that is the master of 10.0.0 zone, will be deriving the zone of 10.0.1 from the 10.0.1.2 server.  The same in reverse.
Because 10.0.0.2 has a route to get to 10.0.1.2, it does not mean that when you ask the dns service on 10.0.0.2 for the name associated with 10.0.1.2 that it can direct the query to the correct source.
A lookup for 10.0.1.2 sent to 10.0.0.2 is not routed through the VPN to 10.0.1.2.  The dns on 10.0.0.2 is referred to the root servers or to the ISP if DNS forwarding was setup.

Thank you! It was the protocol bindings that was the problem. The WAN1 interface had no bindings and when I took a look at the WAN2 interface (which is the one that the VPN is using) I noticed there was a protocol binding for UDP 53. Finally this looksl to be resolved. Thank you for your patience and help.

Wow.  To tell the truth I never even knew that this type of option existed.  Just stumbled across the doc on Cisco's site.

I fairly sure that the RV016 uses Linux so I going to need to figure out how they do this.  I'm not sure if it is some custom code, or maybe something with iptables.  I guess it is iptable, because I have seen iptables setup to intercept port 80 and forward to a different port and to a fixed IP address so that you can implement transparent proxy.

Well it was enough to point me in the right direction. :-) I just completed all the testing and it is working 100%. Thanks again.