Shape Traffic Marked with tcp_outgoing_tos Directive
-
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.
-
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.
-
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. :(
-
Sorry. You have a separate squid node?
-
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.
-
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:
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.
-
"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 - defaultAdvanced
Diffserv Code Points - 0x30
In/Out - 128kb/512kb (just for testing) -
@dpa:
"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 - defaultAdvanced
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?
-
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.
-
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.
-
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.
-
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.
