I have firewall running with “special dummy rule to show fasttrack counter”, I have seen it is showing 500G Bytes pass from this rules but i check other rules understand they are just below 100MB and even deny any any also few MB so i don’t know why fasttrack is 500G, what traffic it is counting?
This is the majority of your traffic. When you stream videos from youtube, all of the packets in the stream are going to be matched by the fasttrack rule (hopefully), and only the first few packets are going to hit other rules.
Any rules after the fasttrack and the “accept any established/related” rule will only count bytes and packets for new connection attempts.
Here’s a “super slow-motion” replay of a new connection forming through your firewall:
Think of your computer connecting to youtube. (assuming the DNS lookup has already been completed) The first packet is going to be a TCP/SYN handshake packet with dst-port=443 coming from your computer, going to youtube.
At this point, this will be a NEW connection, so it won’t match fasttrack, and it won’t match the “accept existing stuff that can’t be fasttracked” rule.
So somewhere further down the forward chain, you may have a rule that allows connections going out the WAN interface - if you don’t have any other rules that specifically match this outgoing youtube connection request, then this “accept out-interface=wan” rule will be the one that matches. It will get +1 in the packets counter and roughly +52 bytes (not sure if it counts the ethernet header or not - probably doesn’t)
On the other hand, if your forward chain has a default accept policy (why???) and if no rules match this packet, it will just “get accepted by default” so no counter will account for this packet’s existence.
Okay - that’s packet #1 in the connection. A few milliseconds later…
Youtube’s server will respond with a TCP/SYN+ACK message (acknowledging the request to create a TCP connection to port 443) - the source port will be 443, and the destination will be whatever src port your outbound request got mapped to… and the connection tracking will now convert this to an ESTABLISHED state, as a reply packet has now been seen. (TCP itself is not quite yet established, but the connection tracking is now happy)
This packet should get matched by the fasttrack-connection rule- bumping that counter by +1 and be another roughly 52 bytes for that byte counter.
At this point, the connection is now active in fasttracking, and packet #2 has been normal-forwarded to your computer from Youtube.
Packet #3 will be sent by your computer- the final packet of the three-way TCP handshake. (another ACK, but without the SYN flag anymore) This packet is even smaller - but anyway, it’s not going to get run through the firewall filter chain anymore because the connection is now in the fasttrack table. The dummy rule will count this packet (and any other that have gotten this far) so it should get a +1 packet count for this packet and +40 bytes of data for this final handshake packet.
After this, the TLS negotion will begin, and your browser will eventually request some piece of the video data, etc etc. all packets carrying this traffic will be getting counted by the dummy rule. (If I’m recalling all of this correctly)