Confused by generated rules



  • 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...



  • @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



  • 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.



  • @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


Locked