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

    DNS-Server from additional networks not reachable

    Scheduled Pinned Locked Moved DHCP and DNS
    4 Posts 3 Posters 3.7k 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.
    • T Offline
      tps800
      last edited by

      Hi!

      I've configured six network cards for pfSense:

      • WAN  (Dynamic)

      • LAN    (192.168.216.2)

      • OPT1  (192.168.218.2)

      • OPT2  (192.168.220.2)

      • OPT3  (192.168.222.2)

      • OPT4  (192.168.224.2)

      With WAN and LAN all is fine. I can reach the running DNS server on LAN.
      With OPT1 to OPT4 there are some problems: DNS is not reachable.
      As far as I can tell DNS is running, but not answering any queries arriving from OPT1 to OPT4.

      I have set OPT1 to:

      • Address: 192.168.218.2

      • Gateway: none (does it mean using the above address?)

      • Block private networks: off

      • Block bogon networks: off

      The DNS server is configured to listen to:

      • LAN, OPT1 to OPT4

      The Proxy (Squid) is configured to listen to:

      • LAN, OPT1 to OPT4

      I've added a rule

        • OPT1 net * * * * none   Default allow OPT1 to any rule

      to OPT1 to OPT4. For LAN this rule was generated automatically.

      All is working for LAN, but not for OPT1 to OPT4.

      The version of pfSense I'm using: 2.0.1

      Any ideas why this doesn't work??

      1 Reply Last reply Reply Quote 0
      • W Offline
        wallabybob
        last edited by

        Which DNS server are you talking about? You have enabled pfSense DNS forwarder?

        Did you reset firewall states after adding the rules? See Diagnostics -> States and click on the Reset States tab.

        The OPTx clients are configured to use the appropriate pfSense IP address for the DNS server?

        The DNS access attempts show up in the firewall log (Diagnostics -> System Logs, click on Firewall tab)

        1 Reply Last reply Reply Quote 0
        • N Offline
          Nachtfalke
          last edited by

          Hopefully you setup the correct firewall rules for OPT1 - OPT4 ?

          1 Reply Last reply Reply Quote 0
          • T Offline
            tps800
            last edited by

            @wallabybob:

            Which DNS server are you talking about? You have enabled pfSense DNS forwarder?

            The build in one: dnsmasq DNS forwarder.

            Did you reset firewall states after adding the rules? See Diagnostics -> States and click on the Reset States tab.

            I've rebooted. But this way would be a lot shorter ;-)

            The OPTx clients are configured to use the appropriate pfSense IP address for the DNS server?

            Client?? Subnet. Or even better: Interface.

            The DNS access attempts show up in the firewall log (Diagnostics -> System Logs, click on Firewall tab)

            Hmmmmm.

            WLAN:
            em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    inet XXX.XX.XX.199 netmask 0xfffffe00 broadcast XXX.XX.XX.255

            LAN:
            em1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    inet 192.168.181.199 netmask 0xfffffe00 broadcast 192.168.181.255

            OPT1:
            em2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    inet 192.168.218.2 netmask 0xffffff00 broadcast 192.168.218.255

            OPT2:
            em3: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    inet 192.168.220.2 netmask 0xffffff00 broadcast 192.168.220.255

            OPT3:
            em4: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    inet 192.168.222.0 netmask 0xffffff00 broadcast 192.168.222.255

            OPT4:
            em5: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    inet 192.168.224.0 netmask 0xffffff00 broadcast 192.168.224.255

            OPT5:
            em6: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    inet 192.168.226.0 netmask 0xffffff00 broadcast 192.168.226.255

            OPT6:
            em7: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    inet 192.168.216.2 netmask 0xffffff00 broadcast 192.168.216.255

            Now pinging the local interfaces:

            LAN:
            [2.0.1-RELEASE][root@fw.localdomain]/root(39): ping -c2 192.168.181.199
            PING 192.168.181.199 (192.168.181.199): 56 data bytes
            64 bytes from 192.168.181.199: icmp_seq=0 ttl=64 time=0.100 ms
            64 bytes from 192.168.181.199: icmp_seq=1 ttl=64 time=0.074 ms

            –- 192.168.181.199 ping statistics ---
            2 packets transmitted, 2 packets received, 0.0% packet loss
            round-trip min/avg/max/stddev = 0.074/0.087/0.100/0.013 ms

            OPT6:
            [2.0.1-RELEASE][root@fw.localdomain]/root(40): ping -c2 192.168.216.2
            PING 192.168.216.2 (192.168.216.2): 56 data bytes
            64 bytes from 192.168.216.2: icmp_seq=0 ttl=64 time=0.096 ms
            64 bytes from 192.168.216.2: icmp_seq=1 ttl=64 time=0.053 ms

            –- 192.168.216.2 ping statistics ---
            2 packets transmitted, 2 packets received, 0.0% packet loss
            round-trip min/avg/max/stddev = 0.053/0.074/0.096/0.022 ms

            OPT1:
            [2.0.1-RELEASE][root@fw.localdomain]/root(41): ping -c2 192.168.218.2
            PING 192.168.218.2 (192.168.218.2): 56 data bytes
            64 bytes from 192.168.218.2: icmp_seq=0 ttl=64 time=0.096 ms
            64 bytes from 192.168.218.2: icmp_seq=1 ttl=64 time=0.063 ms

            –- 192.168.218.2 ping statistics ---
            2 packets transmitted, 2 packets received, 0.0% packet loss
            round-trip min/avg/max/stddev = 0.063/0.080/0.096/0.016 ms

            OPT2:
            [2.0.1-RELEASE][root@fw.localdomain]/root(42): ping -c2 192.168.220.2
            PING 192.168.220.2 (192.168.220.2): 56 data bytes
            64 bytes from 192.168.220.2: icmp_seq=0 ttl=64 time=0.090 ms
            64 bytes from 192.168.220.2: icmp_seq=1 ttl=64 time=0.073 ms

            –- 192.168.220.2 ping statistics ---
            2 packets transmitted, 2 packets received, 0.0% packet loss
            round-trip min/avg/max/stddev = 0.073/0.081/0.090/0.009 ms

            OPT3:
            [2.0.1-RELEASE][root@fw.localdomain]/root(43): ping -c2 192.168.222.2
            PING 192.168.222.2 (192.168.222.2): 56 data bytes

            –- 192.168.222.2 ping statistics ---
            2 packets transmitted, 0 packets received, 100.0% packet loss

            OPT4:
            [2.0.1-RELEASE][root@fw.localdomain]/root(44): ping -c2 192.168.224.2
            PING 192.168.224.2 (192.168.224.2): 56 data bytes

            –- 192.168.224.2 ping statistics ---
            2 packets transmitted, 0 packets received, 100.0% packet loss

            OPT5:
            [2.0.1-RELEASE][root@fw.localdomain]/root(45): ping -c2 192.168.226.2
            PING 192.168.226.2 (192.168.226.2): 56 data bytes

            –- 192.168.226.2 ping statistics ---
            2 packets transmitted, 0 packets received, 100.0% packet loss

            Only LAN, OPT6, OPT1 are working. OPT2, OPT3, OPT4, OPT5 are dead, even if defined??
            Since this is complete local (pinging it's own IP) it is expected to work!
            Shall I suppose it to be a bug?</up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast>

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