Shape Traffic Marked with tcp_outgoing_tos Directive



  • Hi,

    I successfully marked traffic using the tcp_outgoing_tos configuration directive of squid.

    tcpdump shows:

    22:08:47.987643 IP (tos 0x30, ttl 64, id 31564, offset 0, flags [DF], proto TCP (6), length 1500)
    22:08:48.103600 IP (tos 0x30, ttl 64, id 48239, offset 0, flags [DF], proto TCP (6), length 1500)

    I tried creating Firewall Rules to try to match and shape these traffic using Diffserv Code Point in the Advanced feature. But I am unsuccessful, what am I missing?

    PF version is 2.0.3
    Squid version 2.7

    Edit:

    With tos 0x30, I tried af12 and also tried editing webguiconfig to add the 0x30 value. Still no go.

    Kind regards,



  • Anyone with idea regarding this is very much appreciated.



  • Can you show your rules for matching and assigning and which interface they're on.



  • @Harvy66:

    Can you show your rules for matching and assigning and which interface they're on.

    Hi!

    Below is a simple rule just to match the marked traffic. Below this rule are rules that limit each IP on LAN. The goal is to pass TOS marked traffic without limits.

    ![Rule Pass TOS1.png](/public/imported_attachments/1/Rule Pass TOS1.png)
    ![Rule Pass TOS.png](/public/imported_attachments/1/Rule Pass TOS.png)
    ![Tos marked packets.png](/public/imported_attachments/1/Tos marked packets.png)
    ![Rule Pass TOS1.png_thumb](/public/imported_attachments/1/Rule Pass TOS1.png_thumb)
    ![Rule Pass TOS.png_thumb](/public/imported_attachments/1/Rule Pass TOS.png_thumb)
    ![Tos marked packets.png_thumb](/public/imported_attachments/1/Tos marked packets.png_thumb)


  • Netgate

    PF version is 2.0.3

    What is that?  At least 8 updates behind?


  • Netgate

    That said, what are you trying to shape?

    If squid is setting the DSCP, that means the traffic is already in pfSense so a rule on LAN is going to do you no good.

    The traffic has already come into pfSense presumably via LAN.



  • @Derelict:

    PF version is 2.0.3

    What is that?  At least 8 updates behind?

    Yes, I am always thinking on upgrading.

    But I still have to read if newer versions has the solution of what I need, otherwise I'll keep the "if it ain't broke, don't fix it" saying.



  • @Derelict:

    That said, what are you trying to shape?

    If squid is setting the DSCP, that means the traffic is already in pfSense so a rule on LAN is going to do you no good.

    The traffic has already come into pfSense presumably via LAN.

    Forgive me for not totally grasping this. But I thought this is the order of traffic precedence:

    Squid (mark cache hit objects) –> PfSense (read marked traffic and shape it according to the firewall rules) --> LAN Client

    Or I am wrong. :(


  • Netgate

    Sorry.  You have a separate squid node?


  • Netgate

    @Derelict:

    Sorry.  You have a separate squid node?

    Sorry.  I see now.  Yes, but you need to make a floating rule on LAN out that matches the DSCP and sets the proper queue.

    Firewall rules on the interface tabs only match traffic coming into the subject interface.

    the rule should probably look something like this:

    Match on interface LAN direction out source any dest LAN net

    With advanced settings to match DSCP and set the proper queues.

    Sorry, but I don't mess with squid much.  I have no idea if the state in question is already established or not.  You have to match traffic and set queues at the point of state creation.  Some other squiddly diddly might know more.



  • @Derelict:

    @Derelict:

    Sorry.  You have a separate squid node?

    You have to match traffic and set queues at the point of state creation.  Some other squiddly diddly might know more.

    Thanks! The squid is a package added to PfSense. But I guess that won't really matter in this case, will it?

    I'm pretty sure I tried it on the floating rule, but I will do it again with your suggestion.



  • @dpa:

    @Derelict:

    PF version is 2.0.3

    What is that?  At least 8 updates behind?

    Yes, I am always thinking on upgrading.

    But I still have to read if newer versions has the solution of what I need, otherwise I'll keep the "if it ain't broke, don't fix it" saying.

    "Working" doesn't mean it isn't broken. Security fixes.



  • @Harvy66:

    "Working" doesn't mean it isn't broken. Security fixes.

    Yes, I see there are many important fixes.

    Btw, I tried creating the floating rules. It still not shaping accordingly.

    Pass on quick interface Lan
    Destination - Out
    Proto - TCP/UDP
    Source - any
    Port - any
    Destination - Lan net
    Port - any
    Gateway - default

    Advanced
    Diffserv Code Points - 0x30
    In/Out - 128kb/512kb (just for testing)



  • @dpa:

    @Harvy66:

    "Working" doesn't mean it isn't broken. Security fixes.

    Yes, I see there are many important fixes.

    Btw, I tried creating the floating rules. It still not shaping accordingly.

    Pass on quick interface Lan
    Destination - Out
    Proto - TCP/UDP
    Source - any
    Port - any
    Destination - Lan net
    Port - any
    Gateway - default

    Advanced
    Diffserv Code Points - 0x30
    In/Out - 128kb/512kb (just for testing)

    My guess is what Derelict's concern was.

    With my limited understanding, the states are created prior to Squid, which means Squid is setting the DiffServ flag after the states are already established on the LAN.

    You need to figure out a way to get the DiffServ flag set prior to the states getting set, which you should be able to do for the WAN traffic because the WAN states are not created until after Squid. The firewall is the first line of defense, you can't modify packets after the states have been created.

    You do have port information at the time the packets hit the LAN interface. Can you not use that?



  • @Harvy66:

    My guess is what Derelict's concern was.

    With my limited understanding, the states are created prior to Squid, which means Squid is setting the DiffServ flag after the states are already established on the LAN.

    You need to figure out a way to get the DiffServ flag set prior to the states getting set, which you should be able to do for the WAN traffic because the WAN states are not created until after Squid. The firewall is the first line of defense, you can't modify packets after the states have been created.

    You do have port information at the time the packets hit the LAN interface. Can you not use that?

    Hi Harvy,

    I did try using the squid port, but I still cannot get it done. Could you please give me some idea? Thanks!



  • If squid is running in transparent mode, then you can't filter on IP, but something like this.

    TCP srcIP:Any srcPort:Any dstIP:Any dstPort:80      on your LAN port.



  • @Harvy66:

    If squid is running in transparent mode, then you can't filter on IP, but something like this.

    TCP srcIP:Any srcPort:Any dstIP:Any dstPort:80      on your LAN port.

    Thanks. Still testing this setting.



  • @Harvy66:

    If squid is running in transparent mode, then you can't filter on IP, but something like this.

    TCP srcIP:Any srcPort:Any dstIP:Any dstPort:80      on your LAN port.

    Putting this rule on LAN interface will affect any HTTP traffic, cached or not. How I wish specifying Diffserv Code Points together with this rule will work, but it won't. Using tcpdump I can see traffic flowing with the tos mark. Why is it the rule cannot "read" this mark and apply the necessary rule?



  • My understanding is that if you want Diffserv to be honored, it must be set before reaching the firewall. Traffic shaping is set at the time the connection is made. Because you have Squid running inside the firewall, the diffsrv is being set after reaching the firewall.



  • @Harvy66:

    My understanding is that if you want Diffserv to be honored, it must be set before reaching the firewall. Traffic shaping is set at the time the connection is made. Because you have Squid running inside the firewall, the diffsrv is being set after reaching the firewall.

    Ok thanks.

    So there is no way a rule on LAN can tell which traffic passing thru is from cache.