Here after a simple ping from 192.0.2.2, the reply is expected to have an ICMP type 0 (echo reply) instead of the initial type 8 (echo request): icmp 1 12 src=192.0.2.2 dst=8.8.8.8 type=8 code=0 id=26387 src=8.8.8.8 dst=192.0.2.2 type=0 code=0 id=26387 mark=0 use=1Īn active (instead of passive) FTP session (tracked with conntrack -E) from an host 10.1.2.3 behind a NAT router with public IP 198.51.100.32 to a FTP server 203.0.113.47. It will also when relevant, verify that the state transitions are respected (eg: for TCP) Some examples: This happens for example when NAT is in use, or just when the reverse isn't exactly the same. It's most useful when the expected IPs and port aren't just inverted in the reverse direction. It's useful to track current and expected states.
Is keeping this information some kind of optimization or am I missing some use case in which this is the only way to achieve something? When a packet arrives, the lookup can just be done using one pair of IPs and Ports, and if not found it can be done with the same fields but reversed. I can't understand why it should be useful to keep track of the expected IPs and ports if they are just inverted. The same thing goes for the source port and destination port of the connection The information details the source IP address and destination IP address (which are both inverted, since the packet is to be directed back to us). Lastly, we see what we expect of return packets. Next, the same value in normal decimal coding. First of all, we have a protocol, which in this case is tcp. This example contains all the information that the conntrack module maintains to know which state a specific connection is in. I amreading the documentation of Iptables about the connection tracking here and I have troubles figuring the following part, highlited by me: tcp 6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \ĭport=22 src=192.168.1.9 dst=192.168.1.6 sport=22 \
0 kommentar(er)
