2

I understand that iptables --set-mark does not add mark "on" the packets. The MARK target is for associating a mark with the packet in the kernel data structures. The packet itself is not modified. But is there any way to view the packet with its associated mark?

We can see ctmark (connection marks which are set using CONNMARK target) from /proc/net/nf_conntrack. I am looking for something similar for viewing nfmark (packet marks).

This is how we can view ctmark.

iptables -I OUTPUT 1 -t mangle -j CONNMARK --restore-mark
iptables -I OUTPUT 2 -t mangle -m conntrack --ctorigdst 172.30.138.151 -m mark --mark 0 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark

Then we can see the connection mark in the /proc/net/nf_conntrack file. mark=2

ipv4     2 icmp     1 18 src=157.43.150.253 dst=172.30.138.151 type=8 code=0 id=54809 packets=4 bytes=336 src=172.30.138.151 dst=157.43.150.253 type=0 code=0 id=54809 packets=4 bytes=336 mark=2 zone=0 use=2

Another question about the /proc/net/nf_conntrack output. What is the meaning of the field use? I have seen use=1, use=2 etc. This website says it is "Use count of this connection structure".

3
  • 1
    iptables' LOG target will write the packet's mark at the end of the log line if it's non zero. Commented Mar 16, 2019 at 23:59
  • @A.B Yes, you are right. Now, I can see the nfmarks. kern.debug kernel: [11007.886926] IPTables-Marks: IN=wlan0 OUT= MAC=e4:xx:xx:xx:97:32:28:xx:xx:xx:fb:60:08:00 SRC=192.168.8.10 DST=192.168.8.1 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=23698 DF PROTO=TCP SPT=36764 DPT=22 WINDOW=254 RES=0x00 ACK URGP=0 MARK=0x2 Thank you. You can add your comment as a detailed answer, if you want. Commented Mar 18, 2019 at 7:55
  • turned it into a proper answer Commented Mar 18, 2019 at 16:28

1 Answer 1

6

The question is about the fwmark or just mark (historically named nfmark but renamed to just mark at the same time it didn't depend anymore on netfilter. The word nfmark is now a bit misleading, but still present in a few places which weren't or couldn't be updated). This mark is done on the packet's skbuff, while the conntrack mark (aka ctmark etc.) is done on a conntrack entry.

The easiest way to get a packet's mark is to log it via iptables' LOG target. Something like this (with a limit to avoid flood):

iptables -A INPUT -m mark ! --mark 0 -m limit --limit 8/min --limit-burst 12 -j LOG --log-prefix "IPTables-Marks: "

should log packets with a mark. The mark (when non-zero, which is the case with the match chosen above) is displayed at the end of the log line. (From OP's comment) example:

kern.debug kernel: [11007.886926] IPTables-Marks: IN=wlan0 OUT= MAC=e4:xx:xx:xx:97:32:28:xx:xx:xx:fb:60:08:00 SRC=192.168.8.10 DST=192.168.8.1 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=23698 DF PROTO=TCP SPT=36764 DPT=22 WINDOW=254 RES=0x00 ACK URGP=0 MARK=0x2

There are other methods, better suited for automatization but harder to implement, like iptables' NFLOG target intended to "send" the whole packet to a logging program listening on a netlink socket, which could retrieve the mark with nflog_get_nfmark() (old naming...). tcpdump can listen to the nflog facility (try tcpdump --list-interfaces) and display selected packets, which can sometimes be handier than logs to debug, but I don't know of a way to have it also display the mark (it doesn't know about nflog_get_nfmark() or how to ask libpcap about it).

1
  • Just looked around and did a few tests for use=. One way to get a value above 1 is when a conntrack protocol helper (eg: nf_conntrack_ftp) associated a related connection (for ftp that would be during data transfer): it keeps a reference on the master connection which increases the use count. Then when the related connection disappears completely (eg: after the TIME_WAIT state disappeared and the entry is destroyed), use will decrement again by one. Commented Mar 23, 2022 at 20:55

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.