Tcpdump/tshark: view only outgoing TCP connections requests

networkingtcpdump

I would like to view TCP requests (syn packets) initiated by my PC/server to other hosts. More specifically, I would like to view the outgoing connection requests. How can I accomplish this?

Also, I don't want to see any connection attempts that are coming to my PC/server.

The following iptables command works but it's clunky to use as it logs everything while I just want to see everything on the screen:

iptables -I OUTPUT 1 -o eth0 -p tcp -m state --state NEW -j LOG

Best Answer

If you want to see outgoing TCP connections originating from your host you can use the switch src host <ip> as an argument to tcpdump:

$ tcpdump -i any -nn src host 10.0.2.15 and port 80

Example

Simulated outgoing traffic:

$ curl -vv telnet://www.google.com:80
* About to connect() to www.google.com port 80 (#0)
*   Trying 172.217.15.100...
* Connected to www.google.com (172.217.15.100) port 80 (#0)
^C

Watching with tcpdump:

$ tcpdump -i any -nn src host 10.0.2.15 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
11:04:19.585773 IP 10.0.2.15.50642 > 216.58.218.4.80: Flags [S], seq 315169574, win 29200, options [mss 1460,sackOK,TS val 38358006 ecr 0,nop,wscale 7], length 0
11:04:19.623676 IP 10.0.2.15.50642 > 216.58.218.4.80: Flags [.], ack 470600706, win 29200, length 0

Filtering on syn packets

To capture just the outgoing syn packets you'll need to analyze the tcpflags, specifically looking for the tcp-syn flag. Again using the same curl command from above, but now invoking tcpdump like so:

$ tcpdump -i any -nn src host 10.0.2.15 and "tcp[tcpflags] == tcp-syn"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
11:13:39.962475 IP 10.0.2.15.44810 > 64.233.185.103.80: Flags [S], seq 3710429425, win 29200, options [mss 1460,sackOK,TS val 38918382 ecr 0,nop,wscale 7], length 0

tcpflags

From the tcpdump man page:

The general format of a TCP protocol line is:

src > dst: Flags [tcpflags], seq data-seqno, ack ackno, win window, urg urgent, options [opts], length len

Src and dst are the source and destination IP addresses and ports. 
Tcpflags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), U 
(URG), W (ECN CWR), E (ECN-Echo) or `.' (ACK), or `none' if no flags are 
set. Data-seqno describes the portion of sequence space covered by the 
data in this packet (see example below). Ackno is sequence number of the 
next data expected the other direction on this connection. Window is the 
number of bytes of receive buffer space available the other direction on 
this connection. Urg indicates there is `urgent' data in the packet. Opts 
are TCP options (e.g., mss 1024). Len is the length of payload data.

References

Related Solutions

IPTables and transparent proxies

Both parts of your question are linked.

Part (1) captures a SYN packet and redirects it as you suggest. From this point conntrack (2) takes over and recognises that each subsequent packet in that stream is part of the same connection and redirects it in the same way as the original SYN packet.

An overview of Connection Tracking can be found at http://en.wikipedia.org/wiki/Netfilter#Connection_Tracking

Linux – Why are incoming packets on a TAP interface seen with tcpdump but not with iptables

Here is further guesswork. Hope this is helpful, but it may as well be embarassingly wrong.

tap0 has two ends, the kernel network stack end and the program interface. It seems to me if you supply 'nicserver' with tap0, it won't attach to it the way it is intended with tap devices, using the program interface. Instead, nicserver will simply write to it from the network stack end, and with no application reading from the program interface end, you will end up overflowing the device queue. This explains the dropped packets. Also, no packets will be delivered, which might explain the iptables result.

I guess if you let tcpdump capture on tap0 it actually attaches to the program interface end of tap0 and, voila, you see the packets. I searched the internet but found no source to confirm such behaviour. To falsify this theory, capture tap0 and see how it affects packet drops and the iptables log.

Finally, an advice that addresses your original problem: what about using the loopback device, instead? Like so:

nicserver -p 7801 -a lo