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

    Marking packets

    Scheduled Pinned Locked Moved Firewalling
    7 Posts 4 Posters 5.0k 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.
    • K
      killerb81
      last edited by

      Hello there, I found this thread:  https://forum.pfsense.org/index.php?topic=55671.0

      Which is essentially the same question I have, but it was never answered.

      Can anyone explain the functionality of the, "You can mark a packet matching this rule and use this mark to match on other NAT/filter rules. It is called Policy filtering" and "You can match packet on a mark placed before on another rule." under the "Advanced" options of the Firewall Rules.

      Does it allow a packet to be marked with some custom tag that can later be looked at and used to filter/sort packets?

      Thanks.

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        I use it to get a specific shaping functionality.  I implemented an Openwireless.org SSID and on the Pass any any rule on my OPENWIRELESS interface, I did not set the shaping queues, but simply marked the packets with OW.

        Then there's a floating rule on WAN out that matches the OW mark and puts the traffic in the correct HFSC queues.

        When I set the queues on OPENWIRELESS in I wasn't getting the behavior desired.  Can't really remember the specifics.

        One reason to do this in other circumstances is if you match inbound traffic on, say, LAN, you either have to make a bunch of exclusions for traffic you don't want to limit/shape.  Say local traffic from LAN to DMZ.  If you just mark the traffic then match it on WAN out you can only shape WAN traffic and not local traffic.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • C
          charliem
          last edited by

          More tagging details are here: http://www.openbsd.org/faq/pf/tagging.html

          I've found Peter Hansteen's book to be a good, very readable, pf resource: http://www.nostarch.com/pf2.htm

          1 Reply Last reply Reply Quote 0
          • K
            killerb81
            last edited by

            Thanks. This is all great info.

            I had some ideas on how to continue to shape traffic as well as using a squid caching proxy and VPNs. I want this:

            1. LAN IN to pfsense
            2. LAN rules to choose which gateway to use and what queue to be placed in.
            3. SQUID proxy
            4. WAN OUT (depending on which gateway was chosen, this could be one of two VPNs or the unencrypted WAN connection).

            But it seems that SQUID picks the HTTP traffic off before it can get to the LAN rules. Now the LAN rules don't work and everything gets placed in the default queues.
            This is because I choose queues / gateways ONLY by host IP address, but after the traffic leaves SQUID it no longer has the original SOURCE IP address, the SOURCE is now the SQUID server.

            I need a way for traffic to hit LAN IN rules first, get placed in queues / gateways there and mark the HTTP traffic that will be going through SQUID as to which queue and gateway combo, then a NAT rule would send HTTP traffic to SQUID (turn off SQUID as a transparent proxy and do the routing myself), then have SQUID use pfsense as a parent proxy so that the marked traffic can still get out of the correct gateway.

            This might create a loop though… http traffic back and forth from SQUID to pfsense?

            It's been kicking around in my head the last few days on how to do this... thing is, I know just enough about pfSense to get myself into trouble, and don't have a complete understanding on the "order of operations."

            1 Reply Last reply Reply Quote 0
            • KOMK
              KOM
              last edited by

              I've found Peter Hansteen's book to be a good, very readable, pf resource

              Me too, and the new 3rd edition is just out:

              http://www.nostarch.com/pf3

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                I don't know if the pf marks will make it through squid.  Nor do I know if they won't. But if you have trouble that's something to check.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • C
                  charliem
                  last edited by

                  @KOM:

                  I've found Peter Hansteen's book to be a good, very readable, pf resource

                  Me too, and the new 3rd edition is just out:

                  http://www.nostarch.com/pf3

                  Careful.  I haven't looked at it yet, but I think he was updating it for OpenBSD 4.7 or later pf, which brings some changes in pf rules syntax.  I don't think any of that has made it back into FreeBSD yet, or pfSense, unless ESF has back-ported some of it with their non-disclosed in-house pf patches.  So, probably don't get the 3rd edition unless you also get the 2nd.

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