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

    Dropped UDP Packets

    Scheduled Pinned Locked Moved Firewalling
    3 Posts 1 Posters 639 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.
    • D
      DEHAAS
      last edited by DEHAAS

      Hi,

      I am seeing a very strange issue.

      Traffic generally flows fine, ICMP and TCP traffic has no issues. However, UDP packets, at least some, are not being forwarded.

      LAN: 172.20.77.0./24
      Remote Network: 172.20.81.0/24

      The packets in question look like this:

      dd2554bf-edc6-4659-8e0e-237bbc492519-image.png

      afff92ec-eb6f-42ac-bcf9-90454448b955-image.png

      Or like this in the built in packet capture:

      82c00b1f-8754-42b7-9724-a8d01ce2c572-image.png

      They show up in FW states on the LAN interface.

      7c0cee9f-f7f4-4594-a1d5-2aee0324ca08-image.png

      But the packet is not forwarded. I can capture it on the incoming interface, but not the outgoing interface. I also cannot match the traffic on a FW rule. Even with a general rule on the LAN interface with just the source and destination IP, and any protocol will not match the traffic. Any idea what is happening here?

      I have tried to disable pf scrub on the routers, but it has not effect on the issue. The traffic still does not appear on the outgoing interface, and cannot be matching by a FW rule.

      The router is running pfSense 23.05.1

      D 2 Replies Last reply Reply Quote 0
      • D
        DEHAAS @DEHAAS
        last edited by

        @DEHAAS UPDATE: I can see the rule beeing hit once or twice while the router is booting. However, once it is fully booted, the traffic is no longer forwarded. I am still out of ideas, but maybe this information can help spark an idea somewhere

        1 Reply Last reply Reply Quote 0
        • D
          DEHAAS @DEHAAS
          last edited by DEHAAS

          @DEHAAS I believe I have found the problem to be routing related. A state is created for a wrong path as the correct path does not exist when seeing the first packet. The correct path is learned later via OSPF, but the old state is not cleared. I have created a separate thread in the FRR package section of the forum: https://forum.netgate.com/topic/181321/state-not-cleared-after-routing-change. It appeared as some UDP traffic being dropped, as this was the only traffic which had a state created before routes had converged.

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