Dns Forwarder Issues
-
Currently trying to get DNS to forwards over a specific interface.
The following is a packet capture from the interface in question. Using Pfsense own dns resolver tool, the first one works, the second one doesn't even though the capture shows two valid (and identical) replies.
Works ----- 10.232.100.63.33903 > 10.232.100.27.53: [udp sum ok] 21904+ A? portal.cpn.vwg. (32) 10.232.100.27.53 > 10.232.100.63.33903: [udp sum ok] 21904 q: A? portal.cpn.vwg. 1/0/0 portal.cpn.vwg. A 10.112.198.242 (48) Doesnt ------ 10.232.100.63.33090 > 10.232.3.131.53: [udp sum ok] 36518+ A? portal.cpn.vwg. (32) 10.232.3.131.53 > 10.232.100.63.33090: [udp sum ok] 36518 q: A? portal.cpn.vwg. 1/0/0 portal.cpn.vwg. A 10.112.198.242 (48)
Any ideas?
-
How do you know it doesn't work? The output of both queries looks identical.
-
portal.cpn.vwg doesn't resolve when the DNS is set to 10.232.3.131
-
Your first DNS is on the same subnet as the client; the second is not. You're allowing UDP traffic on port 53 between 10.232.100.0 and 10.232.3.0? What's the netmask set to on both the DNS and the client?
-
The pfsense server is 10.233.105.10/26
The interface I have to use for the dns query is 10.232.100.63/25
There is a static route for 10.232.0.0/16 routed over the gateway 10.232.100.1
I have Bypass firewall rules for traffic on the same interface and Disable DNS Rebinding Checks selected under system->advanced.
-
huh??
"portal.cpn.vwg doesn't resolve when the DNS is set to 10.232.3.131"
Sure looks like it resolves to me from this snip
Doesnt
–----
10.232.100.63.33090 > 10.232.3.131.53: [udp sum ok] 36518+ A? portal.cpn.vwg. (32)
10.232.3.131.53 > 10.232.100.63.33090: [udp sum ok] 36518 q: A? portal.cpn.vwg. 1/0/0 portal.cpn.vwg. A 10.112.198.242 (48)Clearly that is 10.232.3.131 sending answer to 10.232.100.63
Where was that sniff taken? And what are you thinking doesn't resolve it?
-
Sniffed on the pfsense server (10.232.100.63), I understand the its resolving on a packet level, but then why is pfsense completely ignoring the response from 10.232.3.131?
Once the DNS is changed to 10.232.3.131 under general, all resolution for the .vwg fails, it only returns when 10.232.100.27 is used.
-
Could this be due to pfsense not being able to handle overlapping netblocks correctly? Is there likely to be a fix? I realise this is a very specific situation.
Dig performed on the pfsense box:
$ dig @10.232.3.132 portal.cpn.vwg any ; <<>> DiG 9.6.-ESV-R5-P1 <<>> @10.232.3.132 portal.cpn.vwg any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56559 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;portal.cpn.vwg. IN ANY ;; ANSWER SECTION: portal.cpn.vwg. 771 IN A 10.112.198.242 ;; Query time: 70 msec ;; SERVER: 10.232.3.132#53(10.232.3.132) ;; WHEN: Tue Jan 13 19:41:02 2015 ;; MSG SIZE rcvd: 48
-
Could this be due to pfsense not being able to handle overlapping netblocks correctly?
Presume you're referring to the /16 static route you have. That's fine, the most specific route always wins.
There should be something in the resolver log if it's not accepting a reply for any reason.
What are you doing to forward those queries with the DNS forwarder?
-
There's nothing in the resolver log relating to not accepting the response.
I'm currently testing on the pfsense box itself using the dns lookup tool.
I need to use the forwarder as pfsense doesn't do the dhcp for the network, a windows server handles AD/Exchange so the DNS has to go to that first, the server then forwards the DNS requests on to pfsense.
I've tried BIND and Unbound as the forwarder and I get the same problem so it looks like its pfsense rather than the DNS module causing the issue.
-
BIND wouldn't resolve a non-public TLD unless you configure some forwarding for that domain. Unbound the same unless it's in forwarder mode and you only have internal name servers configured for forwarding.
Check the destination MAC on the reply packets as shown in your first post, just because it shows up doesn't mean it's targeted to the correct MAC.
-
I will check this tomorrow and report back.
-
09:03:10.717062 00:30:f1:12:fe:7e > f0:f7:55:b3:7b:e0, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 5320, offset 0, flags [none], proto UDP (17), length 60) 10.232.100.63.1433 > 10.232.3.131.53: [udp sum ok] 59738+ A? portal.cpn.vwg. (32) 09:03:10.717105 00:30:f1:12:fe:7e > f0:f7:55:b3:7b:e0, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 18571, offset 0, flags [none], proto UDP (17), length 60) 10.232.100.63.31497 > 10.232.3.132.53: [udp sum ok] 59738+ A? portal.cpn.vwg. (32) 09:03:10.789723 f0:f7:55:b3:7b:e0 > 00:30:f1:12:fe:7e, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 43, id 48181, offset 0, flags [none], proto UDP (17), length 76) 10.232.3.132.53 > 10.232.100.63.31497: [udp sum ok] 59738 q: A? portal.cpn.vwg. 1/0/0 portal.cpn.vwg. A 10.112.198.242 (48) 09:03:10.802999 f0:f7:55:b3:7b:e0 > 00:30:f1:12:fe:7e, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 41, id 11316, offset 0, flags [none], proto UDP (17), length 76) 10.232.3.131.53 > 10.232.100.63.1433: [udp sum ok] 59738 q: A? portal.cpn.vwg. 1/0/0 portal.cpn.vwg. A 10.112.198.242 (48)
00:30:f1:12:fe:7e is the correct interface.
-
Is there any more detail I can give you cmb to try and figure this out?
-
Is any further help available on this?
-
Still at a loss to understand what you think is not working.. Clearly from your last sniff you posted the query for portal.cpn.vwg is getting answered. What else do you want the dns forwarder to do?
-
I don't know how I can put it any clearer.
Yes on a packet level it's working fine but pfsense is completely ignoring the response from the DNS server so portal.cpn.vwg does NOT resolve. If I point pfsense at the Windows server on the same range, which has the very same DNS servers configured, it doesn't ignore the response (which on the packet capture, is 100% identical) so it then resolves portal.cpn.vwg successfully.
pfsense is ignoring a completely valid response from the vwg DNS server for reasons I cannot understand and nobody can answer. The only way it works is if another forwarded is placed between pfsense and the vwg DNS servers.
The only difference is the IP range that the requests are coming from.
I can't dig down and get low level logs so I can't supply any more information, theres nothing of any use on the webgui logging, I would love to get to the bottom of this.
-
So show me in pfsense it not working.. Lets see your host command to the IP and the query..
Lets see the actual capture in wireshark to see if there is a problem with the packet..
So your saying I do a host record server like this to that IP it fails
[2.2-RC][root@pfSense.local.lan]/root: host www.google.com 4.2.2.2
Using domain server:
Name: 4.2.2.2
Address: 4.2.2.2#53
Aliases:www.google.com has address 64.233.181.147
www.google.com has address 64.233.181.106
www.google.com has address 64.233.181.99
www.google.com has address 64.233.181.103
www.google.com has address 64.233.181.105
www.google.com has address 64.233.181.104
www.google.com has IPv6 address 2607:f8b0:4001:c08::67So when you do to one server it works, and other server it fails even though clearly from the sniff the query returned traffic.
-
So when you do to one server it works, and other server it fails even though clearly from the sniff the query returned traffic.
Exactly, I will work on getting a wireshark output later this week and post back here.
-
you can just download the capture you do on pfsense diag, it opens in wireshark just fine.