Navigation

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

    Confused by generated rules

    Traffic Shaping
    3
    4
    3348
    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.
    • M
      msamblanet last edited by

      Using 0.99 - Trying to shape my BitTorrent traffic.  I have my BitTorrent isolated to one IP address used only for Torrent and one inbound port.  I defined my rules as follows:

      Shaping Rules:
        LAN * 10.11.12.17 to * qP2PUp/qP2PDown
        WAN * * TO *:30127 qP2PDown/qP2PUp

      In trying to understand how the shaping was working and ensure it was generated right, I was reviewing the generated rules which were:
        (LAN on rl1, WAN on rl0)
        pass in on  rl1 from 10.11.12.17 to any  keep state tagged unshaped tag qP2PDown
        pass out on  rl0 from any to any  keep state tagged unshaped tag qP2PUp
        pass in on  rl0 from any to any port 30127  keep state tagged unshaped tag qP2PUp
        pass out on  rl1 from any to any port 30127  keep state tagged unshaped tag qP2PDown

      What is confusing me is the 2nd line - I would have expected it to mirror the first line instead…
        pass out on  rl0 from 10.11.12.17 to any  keep state tagged unshaped tag qP2PUp

      Is this an error or am I missing something?  I would think the rule it generated would route any traffic out from rl0 to the qP2PUp which would not have the desired effect...

      1 Reply Last reply Reply Quote 0
      • B
        billm last edited by

        @msamblanet:

        Using 0.99 - Trying to shape my BitTorrent traffic.  I have my BitTorrent isolated to one IP address used only for Torrent and one inbound port.  I defined my rules as follows:

        Shaping Rules:
          LAN * 10.11.12.17 to * qP2PUp/qP2PDown
          WAN * * TO *:30127 qP2PDown/qP2PUp

        In trying to understand how the shaping was working and ensure it was generated right, I was reviewing the generated rules which were:
          (LAN on rl1, WAN on rl0)
          pass in on  rl1 from 10.11.12.17 to any  keep state tagged unshaped tag qP2PDown
          pass out on  rl0 from any to any  keep state tagged unshaped tag qP2PUp
          pass in on  rl0 from any to any port 30127  keep state tagged unshaped tag qP2PUp
          pass out on  rl1 from any to any port 30127  keep state tagged unshaped tag qP2PDown

        What is confusing me is the 2nd line - I would have expected it to mirror the first line instead…
          pass out on  rl0 from 10.11.12.17 to any  keep state tagged unshaped tag qP2PUp

        Is this an error or am I missing something?  I would think the rule it generated would route any traffic out from rl0 to the qP2PUp which would not have the desired effect...

        We create a few extra rules that make no sense - it won't kill anything.  But the pass out any to any has to do with NAT, by the time the filter policy sees it, it's NAT'd, we no longer know where it came from.  However, most of the pass outs shouldn't match (they won't be tagged as unshaped - although I think I may have just found a bug there now that I think about how that code works, oops).

        –Bill

        1 Reply Last reply Reply Quote 0
        • L
          Leoandru last edited by

          Well Its killing my upload shaping see thread: http://forum.pfsense.org/index.php?topic=630.0

          I understand that when the packet is nat'd u no longer know where its from.. But doesn't the filter policy sort that out, I mean once the packet comes in on lan its tagged and the filter policy will take care of the queuing. so the any -> any rule wouldn't be needed.

          when I get time I gonna manually modify /tmp/rules.debug and test that theory. I really need to get upload shaping working by ip addresses.

          1 Reply Last reply Reply Quote 0
          • B
            billm last edited by

            @Leoandru:

            Well Its killing my upload shaping see thread: http://forum.pfsense.org/index.php?topic=630.0

            I understand that when the packet is nat'd u no longer know where its from.. But doesn't the filter policy sort that out, I mean once the packet comes in on lan its tagged and the filter policy will take care of the queuing. so the any -> any rule wouldn't be needed.

            when I get time I gonna manually modify /tmp/rules.debug and test that theory. I really need to get upload shaping working by ip addresses.

            Actually, you may be on to something, I'll have to think about it a little more.  We might not need the "pass out" rules at all as tags are sticky.  Looks like a case of overthinking.  I'll ponder removing that and if it makes sense (and works) this might see an MFC to 1.0.

            –Bill

            1 Reply Last reply Reply Quote 0
            • First post
              Last post

            Products

            • Platform Overview
            • TNSR
            • pfSense Plus
            • Appliances

            Services

            • Training
            • Professional Services

            Support

            • Subscription Plans
            • Contact Support
            • Product Lifecycle
            • Documentation

            News

            • Media Coverage
            • Press
            • Events

            Resources

            • Blog
            • FAQ
            • Find a Partner
            • Resource Library
            • Security Information

            Company

            • About Us
            • Careers
            • Partners
            • Contact Us
            • Legal
            Our Mission

            We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

            Subscribe to our Newsletter

            Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

            © 2021 Rubicon Communications, LLC | Privacy Policy