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

    I need some clarity with regard to how floating rules should match traffic for use with limiters

    Scheduled Pinned Locked Moved Traffic Shaping
    4 Posts 2 Posters 1.1k 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
      swinster
      last edited by swinster

      Hi All,

      pfSense: 2.4.4-RELEASE-p2

      I'm looking to use some limiters to simulate packet loss to/from a specific host on a LAN network (lets say 192.168.0.50) communicating with any host on the WAN network (WAN is NAT'ed), specifically for UDP traffic.

      To this end, I have two limiters,

      • one defined to use a /32 Source address, and packet loss set to 0.1 (name: PacketLoss_10_LAN_UP)
      • and another for a /32 destination address, and packet loss set to 0.1 (name: PacketLoss_10_LAN_Down)

      For the floating rules, I also have two defined:

      • One set to MATCH use the source IP address of the internal host, LAN interface, IPv4/UDP, direction IN, and with the Advanced option In/Out pipe set to PacketLoss_10_LAN_UP
      • the other set to MATCH use the destination IP address of the internal host, LAN interface, IPv4/UDP, direction OUT, and with the Advanced option In/Out pipe set to PacketLoss_10_LAN_DOWN

      The Inbound (UP) rule seems to work, although the state details on the rule show very little matching packets. As a side note, if I create the same rule on the LAN interface set to Pass, I get the same result, but the state details show the expected traffic flow.

      The outbound (DOWN) rule I simply can not seem to get working. It shows no traffic being matched, but I can't see why. PCAP reveals that traffic is definitely going through the LAN interface with the destination address of the host.

      So the questions are:

      1. Why are the state details for the matching IN bound rule apparently lying even though the rule/limiter is working just fine?
      2. What I am doing wrong on the outbound rule match? I'm obviously doing something wrong, but I'm buggered if I can see what.
      1 Reply Last reply Reply Quote 0
      • S
        swinster
        last edited by swinster

        Hmm, what ever I do, I can't seem to get the rule to match on traffic out of the LAN NIC to the LAN hosts.

        To make it easier, here are the filter rules (and yes, I know they are disabled at the moment):

        78ff2552-c76c-4512-b6be-ec18722a8461-image.png

        The "Packet Loss to Dell 10% Down" simply never matches anything (but obviously packets are flowing).

        The "Packet Loss from Dell 10% Up" rule shows one or two packets filtered (when there should be thousands and MB of data), but bizarrely the limiter is causing 10 % packet loss as expected.

        I'm bringing to suspect this might be a bug?

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

          I wonder if anyone had any thoughts on this? It either seem like I'm fundamentally misunderstanding how a rule should filter traffic or this is a bug. Perhaps it should be posed into a different forum?

          1 Reply Last reply Reply Quote 0
          • F
            fsr
            last edited by fsr

            Why not just define the IN and OUT pipes in the first rule? I have traffic shaping defined in floating rules with "direction: in", and they seem to work just fine for downloads too. I suppose that as the firewall is stateful, you only need to match it when the LAN PC connects to the WAN, as that's when the state is created. Then, as long as the state remains, any download and upload traffic is going to the correct pipe as defined in the rule.

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