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

    Significant amount of incoming UDP traffic being blocked?

    Scheduled Pinned Locked Moved Firewalling
    3 Posts 2 Posters 2.9k 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
      Tomasu
      last edited by

      I'm seeing a large amount of incoming UDP traffic being blocked on my pfsense firewall. I'm currently assuming its DHT BitTorrent traffic.

      I've written a (possibly wrong) script to try and correlate the block logs against the actual traffic as captured from tcpdump. It seems to show that something behind my firewall is sending out a UDP packet at a given port, and a response comes later, sent to that port, which is blocked by the default block all rule.

      I personally would not have expected that behavior from BitTorrent clients as I have correctly set my DHT port to something that is forwarded to the machine running my BitTorrent client. I can't explain why I'm getting a large amount of UDP traffic, which just gets blocked.

      I actually have two WANs, but have a dedicated pfsense install for each, and only the pfsense that has a bittorrent client behind it has this issue (which is why I'm assuming its BT traffic), both sit behind the same cable modem, and 100mb ethernet switch.

      Is it just buggy bittorrent clients sending data to the wrong port? Is there anything I can do to resolve this?

      1 Reply Last reply Reply Quote 0
      • P
        pdxer
        last edited by

        If your seeing 'Blocked Log Spam'(high frequency of blocked addresses or ports) an easy way I found to keep it from filling the logs is to write a rule on the destination port in WAN. And since LAN is Default 'All Pass' I will put 'Reject' rules on Ports I know I wont use on the LAN interface, one rule for the source and one for destination. At the bottom of the rule:edit page is a tab for writing logs on that rule, make sure logging for that rule is disabled. This will keep you from getting frequent block logs on your 'System Logs'. To keep your rule page from becoming very long, make an alias for ports(Labeled:BlockPorts) and one for addresses(BlockAddress) that you are wanting to block. So later on when you want to add another port or address, all you have to do is edit the alias attached to the specific block rule.

        pFsense - Buy The Book!
        I spent 40$ to get the 'pFsense: The Definitive Guide' and I no long have a problem misunderstanding pFsense.

        pFsense 1.2.2
        AMD Winchester 2.2GHz 939skt
        MSI/Via K8M890m2-v
        1GB Kingston PC3200
        Maxtor 40GB PATA
        x2 Intel PRO100s
        Netgear FS605 switch
        5160 Surfboard

        1 Reply Last reply Reply Quote 0
        • T
          Tomasu
          last edited by

          @pdxer:

          If your seeing 'Blocked Log Spam'(high frequency of blocked addresses or ports) an easy way I found to keep it from filling the logs is to write a rule on the destination port in WAN. And since LAN is Default 'All Pass' I will put 'Reject' rules on Ports I know I wont use on the LAN interface, one rule for the source and one for destination. At the bottom of the rule:edit page is a tab for writing logs on that rule, make sure logging for that rule is disabled. This will keep you from getting frequent block logs on your 'System Logs'. To keep your rule page from becoming very long, make an alias for ports(Labeled:BlockPorts) and one for addresses(BlockAddress) that you are wanting to block. So later on when you want to add another port or address, all you have to do is edit the alias attached to the specific block rule.

          What it looks like is DHT traffic. I'd really rather not ignore it, but somehow get it to actually reach my BitTorrent client.

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