Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Dns Forwarder Issues

    Scheduled Pinned Locked Moved DHCP and DNS
    29 Posts 4 Posters 8.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • KOMK
      KOM
      last edited by

      How do you know it doesn't work?  The output of both queries looks identical.

      1 Reply Last reply Reply Quote 0
      • S
        spies
        last edited by

        portal.cpn.vwg doesn't resolve when the DNS is set to 10.232.3.131

        1 Reply Last reply Reply Quote 0
        • KOMK
          KOM
          last edited by

          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?

          1 Reply Last reply Reply Quote 0
          • S
            spies
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • johnpozJ
              johnpoz LAYER 8 Global Moderator
              last edited by

              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?

              An intelligent man is sometimes forced to be drunk to spend time with his fools
              If you get confused: Listen to the Music Play
              Please don't Chat/PM me for help, unless mod related
              SG-4860 24.11 | Lab VMs 2.8, 24.11

              1 Reply Last reply Reply Quote 0
              • S
                spies
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • S
                  spies
                  last edited by

                  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
                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    @spies:

                    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?

                    1 Reply Last reply Reply Quote 0
                    • S
                      spies
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • C
                        cmb
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • S
                          spies
                          last edited by

                          I will check this tomorrow and report back.

                          1 Reply Last reply Reply Quote 0
                          • S
                            spies
                            last edited by 

                            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.

                            1 Reply Last reply Reply Quote 0
                            • S
                              spies
                              last edited by

                              Is there any more detail I can give you cmb to try and figure this out?

                              1 Reply Last reply Reply Quote 0
                              • S
                                spies
                                last edited by

                                Is any further help available on this?

                                1 Reply Last reply Reply Quote 0
                                • johnpozJ
                                  johnpoz LAYER 8 Global Moderator
                                  last edited by

                                  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?

                                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                                  If you get confused: Listen to the Music Play
                                  Please don't Chat/PM me for help, unless mod related
                                  SG-4860 24.11 | Lab VMs 2.8, 24.11

                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    spies
                                    last edited by

                                    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.

                                    1 Reply Last reply Reply Quote 0
                                    • johnpozJ
                                      johnpoz LAYER 8 Global Moderator
                                      last edited by

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

                                      So when you do to one server it works, and other server it fails even though clearly from the sniff the query returned traffic.

                                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                                      If you get confused: Listen to the Music Play
                                      Please don't Chat/PM me for help, unless mod related
                                      SG-4860 24.11 | Lab VMs 2.8, 24.11

                                      1 Reply Last reply Reply Quote 0
                                      • S
                                        spies
                                        last edited by

                                        @johnpoz:

                                        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.

                                        1 Reply Last reply Reply Quote 0
                                        • johnpozJ
                                          johnpoz LAYER 8 Global Moderator
                                          last edited by

                                          you can just download the capture you do on pfsense diag, it opens in wireshark just fine.

                                          An intelligent man is sometimes forced to be drunk to spend time with his fools
                                          If you get confused: Listen to the Music Play
                                          Please don't Chat/PM me for help, unless mod related
                                          SG-4860 24.11 | Lab VMs 2.8, 24.11

                                          1 Reply Last reply Reply Quote 0
                                          • S
                                            spies
                                            last edited by

                                            In the packet capture after the failed nslookup, it actually shows a standard query response.

                                            When I capture the LAN interface it is responding with 0x0005 no such name.

                                            Still non the wiser as to why pfsense isn't passing the result on.

                                            putty.png
                                            putty.png_thumb
                                            nslookup.png
                                            nslookup.png_thumb

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.