Thanks for the advice, Ive tried to have one rule to catch both directions but if it is outgoing traffic then the keepstate will automatically allocate the incoming packets that are comming back to the same queue. But if the request originated from a incoming request there is no way possible that the same outgoing queue will work for that traffic.
When a state entry is created, it saves an internal queue ID tag. Every packet that matches the state gets tagged with that queue ID, no matter which direction it's going. Later, when the packet is about to physically travel out of an interface, ALTQ retrieves the tag and looks for a matching queue on that interface. If it finds one, the packet goes there; if not, it goes in the default queue. The last tag applied is the one ALTQ sees.
So, for a given packet, it has two potential tag points: --> [IN tag] >---[ forward ]---> [OUT tag] >--[ altq ]-->
If it's tagged in the OUT slot, that's the one ALTQ sees, whether it was tagged on the IN slot or not. In your setup, this is what you want to happen every time. It's also possible to tag it on the IN slot, for a queue that actually resides on the OUT interface. You don't do this (and don't need to, from what I see), but it's possible.
Anyway, the tagging in the state entry happens no matter which direction the packet is traveling. Thus, when you create a state on an inbound packet, the queue tag will only matter for reply packets (going back out on that interface). The inbound packets will still be tagged, but the tags don't match any queue on the interface they go out on, so nothing happens. Meanwhile, you also have a rule to create state out on that other interface, and that queue tag does apply.
You should keep the one-rule-per-interface setup, i.e. "pass in on $i01", "pass out on $i03". You should also set each rule to use the appropriate queue on that same interface, no matter which direction the rule is for.
Does that make sense?
On Tue, 22 Jul 2003, Trevor Talbot wrote:
On Tuesday, Jul 22, 2003, at 06:43 US/Pacific, Henning Brauer wrote:
On Tue, Jul 22, 2003 at 02:55:47AM -0700, Trevor Talbot wrote:Also note that most of your rules are a bit "loose" as far as TCP goes. The upside is that they'll pick up existing connections when you reboot/reconfigure the firewall, but you may want to get more control over which direction connections are initiated from by using "flags S/SA" with all of them. It depends on your situation; this is just a heads up.
I consider this flags filtering stupid.
Well true, if you aren't using modulate state, there isn't much point. Mark's situation could be handled with just rule reorganization. He currently has rules that catch both directions, and my impression is that he didn't really want connections being initiated in both directions. So I ended up suggesting that, instead of realizing both rules aren't necessary now that keep state is present.
