Firewall and NAT Stats

RouterOS Scripting
1

Hi, I am a scripting newbie, so be nice.

I have a UDP video flow that I want to monitor the average incoming bitrate via comparing the byte counters between 2 periods. I am using Firewall NAT rule to set up a rule to route the incoming packets from the Internet to my device within the private address space.

NAT Rule

4 ;;; Video
chain=dstnat action=dst-nat to-addresses=192.168.1.180 to-ports=2020 protocol=udp src-address=1.1.1.0/25 in-interface-list=WAN dst-port=2020 log=no log-prefix=“”

(IP addresses changed for security)

This works and I see the video flow on my device. All good so far.

However, I do not see the byte or packet counters incrementing:

ip firewall nat print stats where comment=“Video”

Columns: CHAIN, ACTION, BYTES, PACKETS

CHAIN ACTION BYTES PACKETS

;;; Video
4 dstnat dst-nat 0 0

As a work around I added a Firewall Filter rule that accepts the video flow. This should not be required as the NAT rule should be processed first. The good thing is that stats are produced.

;;; Video
chain=forward action=accept protocol=udp src-address=1.1.1.0/25 dst-port=2020 log=no log-prefix=“”

When I run the following command, I get an output and I can see the counter incrementing:

ip firewall filter print stats where comment=“Video”

Columns: CHAIN, ACTION, BYTES, PACKETS

CHAIN ACTION BYTES PACKETS

;;; Video
3 forward accept 12 373 104 172 021

Any thoughts on this. Is this a bug?

Thanks

Pete

2

This is by design. The NAT rules are only consulted for the first packet of a new connection. The NAT transformations are then added to the conntrack entry and used from then on without repeatedly referring to the NAT tables. (There are some special cases where this is not exactly true, but this is the normal situation.)

So using filter/mangle rules is the correct approach. Also be aware that if fasttrack is used, only a limited (small) part of the traffic is processed by the firewall, so if you employ fasttrack, even this approach won’t work.

Just a tip: actually connection rates are available directly by querying the conntrack entries in /ip firewall connections… This is also not consistently updated for fasttrack connections.

3

Lurker888,

Many thanks for your response, I appreciate this. This makes sense now and I will add a filter rule as well as well as not to use fasttrack for this monitoring.

Pete

4

Glad it’s clear now.

Just FYI: if you don’t want to influence anything related to filtering, only count packets/bytes, action=passthrough may be just what you’re looking for.

5

Lurker888,

with my firewall filter rule of ‘accept’ I am measuring 20Mbps (calculated by reseting the counter, delaying for 5s, get the stats in bytes, bytes * 8 (for bits) / 5 for 5 seconds worth of bytes and then / 1000000 for Mbps) for my video stream which is correct, as verified by the source encoder and receive decoder.

However when I change firewall filter rule to ‘passthrough’ my script then reports the video stream as 40Mbps.

What is the reason for the bandwidth being reported as doubling as my script did not change.

Not super important, just curious.

Thanks

Pete

6

The obvious conclusion is that you are somehow counting your traffic twice. Depending on your exact rules (not just the one rule, but the whole “system” of rules) and the way you obtain your statistics in your script it can be a lot of things.

The difference between “passthrough” and “accept” is that the latter terminates the given stage of firewall processing (and thus any further rules are not consulted), while “passthrough” only records the match in its counters (and logging, if enabled) but then allows the packet to proceed further.

Also be very cautious when referring to firewall rules. The reference number of rules changes basically randomly. The correct way to refer to a given rule in a script is to assign a comment to a rule such as “mycounter” and then refer to it as

/ip/firewall/filter get [ find comment~"mycounter" ] bytes

Also, it’s nicer to store the initial value in a variable and use the difference than to reset the counters.

Otherwise what you’re doing seems fine.

7

Lurker888,

Thanks for your response. I was bitten by the firewall rule number changing! I do match using the comment field as this seems the safest way do this.

Thanks for the advice about storing the device and doing a delta between the 2 samples. I will use this going forward.

Thanks again.

Pete