Curiosity in pftop output
-
I have been watching pftop output for few minutes and noticed something that puzzled me. Here's a snapshot of a pftop screen.
pfTop: Up State 1-27/509, View: default, Order: rate, Cache: 10000 10:39:21
PR DIR SRC DEST STATE AGE EXP PKTS BYTES
tcp In 192.168.211.217:43442 141.30.87.128:51413 ESTABLISHED:ESTABLISHED 00:01:17 23:59:59 4317 4007848
tcp Out 192.168.211.217:43442 141.30.87.128:51413 ESTABLISHED:ESTABLISHED 00:01:17 23:59:59 4317 4007848
tcp In 192.168.211.217:60529 46.159.107.226:64640 ESTABLISHED:ESTABLISHED 00:05:04 23:59:59 8187 6861685
tcp Out 192.168.211.217:60529 46.159.107.226:64640 ESTABLISHED:ESTABLISHED 00:05:04 23:59:59 8187 6861685
tcp In 192.168.211.217:10344 147.102.1.22:45751 ESTABLISHED:ESTABLISHED 00:03:59 23:59:59 3786 3090594
tcp Out 192.168.211.217:10344 147.102.1.22:45751 ESTABLISHED:ESTABLISHED 00:03:59 23:59:59 3786 3090594
tcp In 192.168.211.217:14053 203.219.161.217:51413 ESTABLISHED:ESTABLISHED 00:01:16 23:59:59 154 100667
tcp Out 192.168.211.217:14053 203.219.161.217:51413 ESTABLISHED:ESTABLISHED 00:01:16 23:59:59 154 100667
udp Out 192.168.37.197:514 192.168.37.200:514 SINGLE:NO_TRAFFIC 02:59:15 00:00:29 227179 42984086
tcp In 192.168.211.217:21103 188.23.204.18:51413 ESTABLISHED:ESTABLISHED 00:05:30 23:59:59 2665 2081559
tcp Out 192.168.211.217:21103 188.23.204.18:51413 ESTABLISHED:ESTABLISHED 00:05:30 23:59:59 2665 2081559
tcp In 192.168.211.217:16744 186.134.159.62:55058 ESTABLISHED:ESTABLISHED 00:03:20 23:59:59 2721 2366236
tcp Out 192.168.211.217:16744 186.134.159.62:55058 ESTABLISHED:ESTABLISHED 00:03:20 23:59:59 2721 2366236
tcp In 192.168.211.217:64137 173.164.198.38:8173 ESTABLISHED:ESTABLISHED 00:01:21 24:00:00 209 125628
tcp Out 192.168.211.217:64137 173.164.198.38:8173 ESTABLISHED:ESTABLISHED 00:01:21 24:00:00 209 125628
tcp In 192.168.211.217:4381 190.74.245.108:51433 ESTABLISHED:ESTABLISHED 00:01:08 24:00:00 40 22871
tcp Out 192.168.211.217:4381 190.74.245.108:51433 ESTABLISHED:ESTABLISHED 00:01:08 24:00:00 40 22871
tcp In 192.168.211.217:27374 192.168.211.173:22 ESTABLISHED:ESTABLISHED 00:01:28 23:59:58 193 44123
udp Out 192.168.37.197:64987 192.168.37.200:5678 SINGLE:NO_TRAFFIC 00:04:33 00:00:28 318 73704
icmp In 192.168.211.217:0 192.168.211.173:57144 0:0 02:55:48 00:00:10 21076 1348864
tcp In 192.168.211.217:15732 41.132.58.102:44600 CLOSING:FIN_WAIT_2 00:00:10 00:00:45 11 1119
tcp Out 192.168.211.217:15732 41.132.58.102:44600 FIN_WAIT_2:CLOSING 00:00:10 00:00:45 11 1119
tcp In 192.168.211.217:42570 186.136.17.138:41208 ESTABLISHED:ESTABLISHED 00:00:10 23:59:59 8 989
tcp Out 192.168.211.217:42570 186.136.17.138:41208 ESTABLISHED:ESTABLISHED 00:00:10 23:59:59 8 989
tcp In 192.168.211.217:4986 82.254.77.199:51413 ESTABLISHED:ESTABLISHED 00:01:34 23:59:58 31 4016
tcp Out 192.168.211.217:4986 82.254.77.199:51413 ESTABLISHED:ESTABLISHED 00:01:34 23:59:58 31 4016
tcp In 192.168.211.217:59962 193.250.25.18:43611 ESTABLISHED:ESTABLISHED 00:01:35 23:59:59 32 4239Some of the puzzling entries are coloured red. I'm puzzled that there are apparently pairs of entries that appear to be duplicates EXCEPT for the direction.
The pfSense box displaying this has IP addresses 192.168.211.173 (LAN) and 192.168.37.197(OPTx).
What is the meaning of the Direction attribute?
Why aren't there duplicate entries for UDP and ICMP?
-
AFAIK every tcp connection uses two states, one for input and another one for output data. TCP is stateful so it always replies data.
UDP and ICMP are connectionless protocols so they use only one state.No idea about the red lines though…
-
This is interesting. Until I read your post it had never occurred to me that I didn't fully understand the output of pftop. There doesn't seem to any obvious page that details what all of this means. At least none that I could find briefly Googling, the official pftop page has almost nothing.
However here is how I read it. The reason for the pairs of entries is that the machine you are looking at is a router. You will notice that each of the entries that occur in pairs are for connections between machines on your internal network to machines on the internet. Hence the first entry is IN to the LAN interface and the second entry is OUT of the WAN. All the entries that occur singularly are either to or from the pfSense box directly.
The other possibility I considered is that TCP requires a two way connection where as UDP does not. However the amount of data is equal for IN and OUT entries which would not be the case for TCP.
Be nice to have this explained properly though.
Steve
-
AFAIK every tcp connection uses two states, one for input and another one for output data. TCP is stateful so it always replies data.
UDP and ICMP are connectionless protocols so they use only one state.Thanks for replying. The UDP and ICMP lines in the display are all for "flows" in which one end point is an IP address of the pfSense box. The apparently duplicate entries are for connections in which both endpoints are other than the pfSense box.
The apparently duplicate entries are for torrents which were predominantly downloads so the packet and byte counts should be different in the two entries if they were for the opposing direction of travel between the endpoints.
Unfortunately the online FreeBSD man page collection at http://www.freebsd.org/cgi/man.cgi doesn't have a man page for pftop.
-
Unfortunately the online FreeBSD man page collection at http://www.freebsd.org/cgi/man.cgi doesn't have a man page for pftop.
Perhaps because it hasn't been updated since 2007.
Or that:The pftop program has not kept up with PF changes – it produces incorrect output, in particular, byte counts.
Most of the functionality of pftop has been made available in the -current version of the systat program.That's an OpenBSD quote though and FreeBSD uses a much older version of pf and pfSense something in between.
There is a man page for it though:
http://www.eee.metu.edu.tr/~canacar/pftop/pftop.8.htmlSince it only displays the status of pf I guess you need to know how pf works to read it. :-\
Steve
-
The man page at http://www.eee.metu.edu.tr/~canacar/pftop/pftop.8.html seems to describe a different version of pftop than the one in pfSense. (The man page describes a filter option which is not reported in the output from pfsense shell command```
pftop -h
@stephenw10: > However here is how I read it. The reason for the pairs of entries is that the machine you are looking at is a router. You will notice that each of the entries that occur in pairs are for connections between machines on your internal network to machines on the internet. Hence the first entry is IN to the LAN interface and the second entry is OUT of the WAN. All the entries that occur singularly are either to or from the pfSense box directly. I'm leaning to a similar interpretation. However, I would have thought that the majority of states on a router would be for "through" traffic and so the attributes for the pair of the states for the same direction of end-to-end data travel would track one another very closely so there would be little use in displaying both members of the pair. @stephenw10: > Be nice to have this explained properly though. Agreed. The topic I started at [http://forum.pfsense.org/index.php/topic,47310.0.html](http://forum.pfsense.org/index.php/topic,47310.0.html) seems to be related to this. I get the impression that pfSense generally generates twice the flow state and flow records that are expected by some of the common tools. (pftop and flow-tools).
-
AFAIK every tcp connection uses two states, one for input and another one for output data. TCP is stateful so it always replies data.
UDP and ICMP are connectionless protocols so they use only one state.Thanks for replying. The UDP and ICMP lines in the display are all for "flows" in which one end point is an IP address of the pfSense box. The apparently duplicate entries are for connections in which both endpoints are other than the pfSense box.
The apparently duplicate entries are for torrents which were predominantly downloads so the packet and byte counts should be different in the two entries if they were for the opposing direction of travel between the endpoints.
Each line may be a firewall state, and the info displayed may be connection info. That would explain why the byte counts is the same: Because it's connection info and both states are part of the same connection.
Of course I may be mistaken :) -
Filtering appears to have been added in V0.7, the most recent version.
Steve