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

    DNS not working from server in LAN

    Scheduled Pinned Locked Moved Virtualization
    9 Posts 2 Posters 1.8k 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.
    • S
      SeraSera
      last edited by

      Hey Guys,

      I was wondering if someone could help me out with the following:

      I have a Xen server set up, with a HVM Pfsense. Pfsense has two interfaces, WAN which has public ip (x.x.x.x) and LAN on 192.168.x.254/24

      Everything seems to work fine, if I go to diagnostics, then go to ping from LAN interface and type in google.com, this is the response I get:
      PING google.com (173.194.112.102) from 192.168.x.254: 56 data bytes
      64 bytes from 173.194.112.102: icmp_seq=0 ttl=56 time=5.782 ms
      64 bytes from 173.194.112.102: icmp_seq=1 ttl=56 time=6.451 ms
      64 bytes from 173.194.112.102: icmp_seq=2 ttl=56 time=5.728 ms

      However, on a server in the network, I can only ping the DNS servers, but when I do a ping to google.com, nothing happens. Adding a pass rule from the server 192.168.101.20 on port 53 outgoing, does show the traffic going through the logs, to the (external) DNS servers I have configured, but the the server gets no response, so it either seems the packet gets dropped or lost somewhere.

      I have disabled hardware checksum offloading and enabled Do not use the DNS Forwarder as a DNS server for the firewall.

      Does anyone have an idea of what's going on or what I can test to figure out what's happening?

      Thanks!

      Sera

      I

      1 Reply Last reply Reply Quote 0
      • D
        doktornotor Banned
        last edited by

        Kindly post the screenshot of your LAN firewall rules.

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

          Thanks for your quick response.

          LAN_interface_screenshot.jpg
          LAN_interface_screenshot.jpg_thumb

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by

            Well, the first rule is completely redundant with all traffic allowed. Certainly not a packet filter problem.

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

              First rule was just for the logging.

              I just found this in a capture when I opened it in wireshark: bad udp cksum 0xdcc7 -> 0x7cd5!, is there anything in Pfsense other then hardware checksum offloading, that could cause this?

              1 Reply Last reply Reply Quote 0
              • D
                doktornotor Banned
                last edited by

                Sounds like virtualization-specific shit.

                https://forum.pfsense.org/index.php?topic=88467.0

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

                  Thanks, seems to be the same issue. Will post how I resolved this issue.

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

                    Solved using:

                    $ sudo ethtool -K vifx.0 tx off
                    $ sudo ethtool -K vifx.1 tx off

                    If you experience this issue, please use the guide linked above by Doktornotor. (edit: Made by JohnKeates)

                    Thank you very much!

                    1 Reply Last reply Reply Quote 0
                    • D
                      doktornotor Banned
                      last edited by

                      The guide is not mine, I junk linked it ;)

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