OT: IPTABLES TCP/IP ip_conntrack Record

Mark Sargent powderkeg at snow.email.ne.jp
Tue Aug 30 06:44:12 UTC 2005


Hi All,

am studying IPTABLES and am curious about this section,

****************************

As you can see, it is really quite simple, seen from the user's point of 
view. However, looking at the whole construction from the kernel's point 
of view, it's a little more difficult. Let's look at an example. 
Consider exactly how the connection states change in the 
/proc/net/ip_conntrack table. The first state is reported upon receipt 
of the first SYN packet in a connection.

tcp      6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
     dport=1031 use=1
   

As you can see from the above entry, we have a precise state in which a 
SYN packet has been sent, (the SYN_SENT flag is set), and to which as 
yet no reply has been sent (witness the [UNREPLIED] flag). The next 
internal state will be reached when we see another packet in the other 
direction.

tcp      6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
     use=1
   

Now we have received a corresponding SYN/ACK in return. As soon as this 
packet has been received, the state changes once again, this time to 
SYN_RECV. SYN_RECV tells us that the original SYN was delivered 
correctly and that the SYN/ACK return packet also got through the 
firewall properly. Moreover, this connection tracking entry has now seen 
traffic in both directions and is hence considered as having been 
replied to. This is not explicit, but rather assumed, as was the 
[UNREPLIED] flag above. The final step will be reached once we have seen 
the final ACK in the 3-way handshake.

tcp      6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
     sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
     sport=23 dport=1031 [ASSURED] use=1
   

*************************

In the 1st entry, the expected source ip and destination ip,

src=192.168.1.35 dst=192.168.1.5


are still the expected src dest ip in the 2nd entry, syn/ack entry. 
Shouldn't they be the other way round.? Perhaps I'm misunderstanding 
it.? My understanding, is, that the syn_sent packet orignates from 
192.168.1.5 and the syn_recv packet originates from 192.168.1.35, no.? 
Cheers.

Mark Sargent.




More information about the fedora-list mailing list