Hello Trevor, I understand what you mean but this is only for a outgoing connection with keepstated incoming. If another completely different incoming connection gets established then since it did not orignate as a outgoing connection the keep state will not apply.
I mind have two seperate queue's for incoming/outgoing (one would be better tho) but i would like all the shaping to happen on one interface only without shaping on the interface the host is connected too. Regards Mark ---------------------------------------------------------------- I smell a rat. Did you bake it or fry it? ---------------------------------------------------------------- On Wed, 23 Jul 2003, Trevor Talbot wrote: >On Tuesday, Jul 22, 2003, at 23:46 US/Pacific, Mark Bojara wrote: > >> 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. > >
