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

    How to drop corrupted packages on pfSense?

    Scheduled Pinned Locked Moved Firewalling
    12 Posts 4 Posters 1.3k 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.
    • H
      h3llghost
      last edited by

      Hello,

      I have created a rule to allow UDP traffic and noticed multiple times in the linux kernel log entries "UDP: bad checksum".

      Is it possible to drop any corrupted packages at pfSense and don't let them pass to the client?
      I have tried to find something like that in the documentation and via Google without success (or I am blind).

      1 Reply Last reply Reply Quote 0
      • JKnottJ
        JKnott
        last edited by

        Where are those bad packets coming from?  At which layer are they corrupted?  If Ethernet, then they shouldn't be passed by anything.

        PfSense running on Qotom mini PC
        i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
        UniFi AC-Lite access point

        I haven't lost my mind. It's around here...somewhere...

        1 Reply Last reply Reply Quote 0
        • H
          h3llghost
          last edited by

          I think they are send by purpose.

          
          Apr  6 18:21:44 debian kernel: [522750.011183] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33
          Apr  6 18:21:44 debian kernel: [522750.088737] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33
          Apr  6 18:21:46 debian kernel: [522752.090057] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33
          Apr  6 18:21:46 debian kernel: [522752.090065] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33
          Apr  6 18:21:46 debian kernel: [522752.543712] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33
          Apr  6 18:21:46 debian kernel: [522752.572293] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33
          Apr  6 18:21:46 debian kernel: [522752.574443] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33
          
          
          1 Reply Last reply Reply Quote 0
          • P
            pfBasic Banned
            last edited by

            What kind of NIC are you using?

            1 Reply Last reply Reply Quote 0
            • P
              pfBasic Banned
              last edited by

              System / Advanced / Networking > Network Interfaces

              Several types of checksum offloading can be turned off there. You might want to give that a try, some packages and configurations don't work well with checksum offloading even if using a well supported NIC.

              Checking this option will disable hardware checksum offloading.
              Checksum offloading is broken in some hardware, particularly some Realtek cards. Rarely, drivers may have problems with checksum offloading and some specific NICs. This will take effect after a machine reboot or re-configure of each interface.

              That said if the problem doesn't lie there and you are using Intel NICs and don't have a reason to turn those off, then leave them on as they will save you CPU cycles.

              1 Reply Last reply Reply Quote 0
              • H
                h3llghost
                last edited by

                I am using an Intel NIC.

                Is there no option just do drop such packages without thinking about it? As far as I know they are used to kill some game servers.

                1 Reply Last reply Reply Quote 0
                • jimpJ
                  jimp Rebel Alliance Developer Netgate
                  last edited by

                  If the packets had a bad checksum when they reached pfSense, they would already be blocked/dropped. It would appear they are being corrupted at or just before they reach the Linux system.

                  Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                  Need help fast? Netgate Global Support!

                  Do not Chat/PM for help!

                  1 Reply Last reply Reply Quote 0
                  • H
                    h3llghost
                    last edited by

                    Hum interesting, but why does the package reach my client if you say pfsense drops them?

                    1 Reply Last reply Reply Quote 0
                    • jimpJ
                      jimp Rebel Alliance Developer Netgate
                      last edited by

                      How do you know it's corrupt when it enters the firewall?

                      The usual answer is: It's being corrupted at or just before the linux box (e.g. bad cable, switchport, etc)

                      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                      Need help fast? Netgate Global Support!

                      Do not Chat/PM for help!

                      1 Reply Last reply Reply Quote 0
                      • JKnottJ
                        JKnott
                        last edited by

                        How do you know it's corrupt when it enters the firewall?

                        In fact, it probably isn't.  Ethernet frames have a checksum, as do IPv4 packets as well as TCP.  UDP often has a CRC on IPv4 and always on IPv6, so there are many checks along the way to stop a damaged packet from being passed by a switch or router.  So, you have to determine at what layer it's corrupt.  Only UDP or TCP content that's been corrupted at source is likely to make it all the way to your network.  Bad IP packets or Ethernet frames are likely to be dropped enroute.  Also, if it's the Ethernet frame that's corrupt, the problem can only be at your end, as Ethernet frame are created & discarded on every hop.  As for corrupted at the UDP level, is it only one source that they're coming from?

                        PfSense running on Qotom mini PC
                        i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                        UniFi AC-Lite access point

                        I haven't lost my mind. It's around here...somewhere...

                        1 Reply Last reply Reply Quote 0
                        • H
                          h3llghost
                          last edited by

                          @jimp:

                          How do you know it's corrupt when it enters the firewall?

                          I assume it. How I said before it is a known attack for the game server to cause a crash with such defect packages.
                          They are iterating about all instances of my server (about 10). So I can say that is no normal client and I want to drop these packages.

                          I think the topic is misleading. It is just about how to drop packages to a specific destination which are not valid.

                          @JKnott:

                          As for corrupted at the UDP level, is it only one source that they're coming from?

                          They are coming from different IPs. They are iterating over the ports to hit every running instance.

                          
                          Apr  9 22:40:18 debian kernel: [797866.671229] UDP: bad checksum. From sameattackerip:65535 to myserverip:11116 ulen 33
                          Apr  9 22:40:22 debian kernel: [797870.598135] UDP: bad checksum. From sameattackerip:65535 to myserverip:11115 ulen 33
                          Apr  9 22:40:24 debian kernel: [797872.684341] UDP: bad checksum. From sameattackerip:65535 to myserverip:11122 ulen 33
                          Apr  9 22:40:24 debian kernel: [797872.686461] UDP: bad checksum. From sameattackerip:65535 to myserverip:11121 ulen 33
                          Apr  9 22:40:24 debian kernel: [797872.704227] UDP: bad checksum. From sameattackerip:65535 to myserverip:11119 ulen 33
                          Apr  9 22:51:05 debian kernel: [798514.350548] UDP: bad checksum. From sameattackerip:65535 to myserverip:11117 ulen 33
                          Apr  9 22:51:05 debian kernel: [798514.575728] UDP: bad checksum. From sameattackerip:65535 to myserverip:11120 ulen 33
                          Apr  9 22:51:46 debian kernel: [798555.452463] UDP: bad checksum. From sameattackerip:65535 to myserverip:11116 ulen 33
                          Apr  9 22:51:50 debian kernel: [798559.479862] UDP: bad checksum. From sameattackerip:65535 to myserverip:11115 ulen 33
                          Apr  9 22:51:52 debian kernel: [798561.488506] UDP: bad checksum. From sameattackerip:65535 to myserverip:11122 ulen 33
                          Apr  9 22:51:52 debian kernel: [798561.490455] UDP: bad checksum. From sameattackerip:65535 to myserverip:11121 ulen 33
                          Apr  9 22:51:52 debian kernel: [798561.490509] UDP: bad checksum. From sameattackerip:65535 to myserverip:11119 ulen 33
                          
                          
                          1 Reply Last reply Reply Quote 0
                          • P
                            pfBasic Banned
                            last edited by

                            @h3llghost:

                            They are iterating about all instances of the server (about 10 servers) from the same ip.
                            So I can say that is no normal client and I want to drop these packages.

                            They are coming from different IPs. They are iterating over the ports to hit every running instance.

                            This is a little confusing, what is coming from one IP and what is coming from multiple IPs?

                            Either way, if it's one type of attack then implement suricata and write a custom rule that searches for that type of attack and drops the packet.

                            If you post a packet capture or something of the traffic you are having trouble with then I'm sure the community can help you write a rule or two to drop it.

                            Also, it looks like you are trying to keep the IP of your attacker private in the post above? Don't protect a known attacker, if they are attacking you then publicize their IP. That could also be useful information in helping you defeat the attack.

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