it’s kind of ‘best practice’: first rule should be ‘accept all established connections’. then you mark all new (unknown) connections. or drop them. increase of performance.
next step: TCP connection is two flows, requests from client to server and responses from server to client. so the easiest way is to mark a whole connection - and then you may mark all packets belonging to that connection
I’m a relative newbie to networking, so bear with me… From what I’ve seen so far, anywhere that you can do something based on a packet mark (NAT it, filter it, route it, queue it, etc), you can also do it via a connection mark on the connection that the packet belongs to. I’m sure there are features where this isn’t the case or where it wouldn’t work, but haven’t run into one yet.
So in the interest of effeciency I don’t see any reason to use the packet marks too. Am I missing something?
You seem to have some experience with mangle and QoS
I always setup my connection-mark mangle rules on the incoming interface in the prerouting chain. (and then the packet marker too off course)
But now after more and more reading I am starting to move on that idea. I can leave the mentioning of the incoming chain behind? (Saves me on two or three rules that I then combine in one. Lesser is better.)
And why are most mangle examples in both Wiki and forum made in the forward chain? Why not in pre-routing?
Pre-routing ´catches´ everything?
well, ‘forward’ chain is where routing decision and src-deNAT are already done, compared to ‘prerouting’, and it’s sometimes useful for you task. sometimes not =) you should select a chain by your needs, http://wiki.mikrotik.com/wiki/Packet_Flow helps a lot =)
"But now after more and more reading I am starting to move on that idea. I can leave the mentioning of the incoming chain behind? "
Should have red "But now after more and more reading I am starting to move on the idea that I can leave the mentioning of the incoming interface behind?
A tutor of mine told me to mangle with incoming interface as one of the arguments but after reading, reading and more reading I come to the idea that it could also be left behind…
It would save me some extra rules for ping and winbox to router itself etc.
It also makes it easier to copy one routers mangle into another routers config because some the interface are not all with the same function.
according the official wiki "Queue tree creates only one directional queue in one of the HTBs. It is also the only way how to add queue on the separate interface. This way it is possible to ease mangle configuration - you don’t need separate marks for download and upload - only upload will get to Public interface and only download will get to Private interface."
So I am a bit confused now and am looking for some funded advices here…
I find anyway that QoS with mangle and best practises still can have more and better explanations in both this forum and the wiki. I even find some user’s wiki adds not falling under the category ´best practise´. Its sad that MT not gives any comments on these adds. It only creates more confusion or put some lesser experiances at the wrong track…
well, if you mark connections, you should use ‘connection-state=new’ first, I believe. connection mark will stay here for the whole lifetime of the connection
what exactly you do with checking incoming interface?.. it can be useful, and it can be useless, subject to your setup
In my humble opinion ´connection-state=new´ means marking only packets that START a new connection. Marking of packets belonging to an existing connection should be done with the option ´connection-state=established´.
By leaving this option disabled ALL connections for that argument are marked. Thus the ones that start a connection and packets belonging to it. All in one rule. No ´connection-state=´ to be mentioned.
This is what most examples in manual and wiki also use…
It is connection tracker that takes care that packets (also reply/return) belonging to the first initiated connection get the same marker for as long as the connection stays alive…
connection tracker takes care for the marking as long as the connection is listed in the tracker table. So even if the connection is not alive any more but still registered, traffic as result of the same original connection still get the same markers as long as the connection is still listed.
Well, I was once troubleshooting and noticed that although I changed a connection mark for a certain data stream the stream just kept on with the old mark.
This is what MT wrote to me after a consult:
“As long as your connection will stays in connection tracking table it will have that mark, even if those rules are disabled.”
Same lately, to test connection marking and see what traffic really is in the conn.tracker I each time have to erase the whole list otherwise I just am looking at old markers mixed with new ones.
Some months ago I noticed that I could kill a P2P session only by erasing all connection tracker registers after I started to block some with a firewall filter. If I did not erase the connection in the tracker the connection came back each day, even if the client had its PC shut down or I shut his antenna down for him (disabled ether port). The next time he was switched back on the P2P stream started to run again because the http connection tracking time out was 24 hours or so. I set the timeout back to 1 hours and next day the client hang on the phone his P2P didn’t work anymore!
For me proof enough that as long as a connection is in the connection tracker it CAN (not will!) be used by the same application again.
Ehh, thanks for pointing me to the ´edit´ button. Never seen that one!
well, about p2p I’m not sure, it’s based on your setup. and I can’t see how new connection may be established over old one (with the same src-port, for example) and without noticing of ConnTrack…
but “As long as your connection will stays in connection tracking table it will have that mark, even if those rules are disabled.” - it’s fully true. established connection saves conn-mark, if you do not rewrite it with new one
