I don’t want to take too much credit for creating this. It’s based on what I learnt from the excellent Iptables tutorial<\/a>.<\/p>\n Now for the various bits and bobs:<\/p>\n This is used for just one thing – to set a mark on packets to say they should not be handled by the connection tracking system (i.e. don’t keep note of their state; don’t act as a stateful firewall on these packets). This is done using the NOTRACK target. The Raw table has only PREROUTING and OUTGOING chains as it’s only used just as a packet enters the host or is generated by the host to leave it.<\/p>\n This table is used to mangle (modify) packets. It is primarily used for changing these fields in a packet and is not to be used for filtering or any sort of NATing. <\/span>It has the following actions\/ targets: This table has chains everywhere. You can mangle during PREROUTING (as a packet enters the host), OUTPUT (or for a packet generated by the host), INPUT (a packet destined for this host), FORWARD (a packet being forwarded via this host), and POSTROUTING (as a packet leaves the host).<\/p>\n Example:<\/p>\n Note: There’s a CONNMARK action too, which is not limited<\/span> to the Mangle table. CONNMARK associates marks with the connection rather than a packet, and it sounds like when in doubt one should use CONNMARK<\/a>. CONMARK is available to all tables (including the Mangle table) and similar to the CONNSECMARK action it can set, save, restore marks between connections. An example from this blog post<\/a>:<\/p>\n I am not a 100% clear on the difference between MARK and CONNMARK. I think 1) the MARK action modifies the actual packet, while CONNMARK is an association within the kernel between a connection and its mark (which can be explictly set or set from its packets) and that’s why you’d use MARK to actually set a mark and 2) rather than then MARK each packet of a connection individually it is easier to MARK the first one and then use CONNMARK to set the same for all packets in the connection. I got this impression from this StackOverflow post<\/a>.<\/p>\n This table is only used to perform NAT operations. Only the first packet in a stream of packets hits this table, and al subsequent packets of that stream follow whatever is determined with the first packet. You can do the following:<\/p>\n Some examples might be useful (most of these are from the HOWTO <\/a>so it’s mainly for the reference of my future self):<\/p>\n Note that SNAT & MASQUERADE are always in the POSTROUTING chain. Because it happens as the packets are exiting the machine. It is the last step before the packets exit. <\/p>\n Note that DNAT & REDIRECT happen in the PREROUTING chain, before any filtering but after any actions by the Raw and Mangle tables. This is what you’d typically expect to do with a firewall – filter packets. ACCEPT, DROP, or REJECT them depending on our filters.<\/p>\n You can filter on the INPUT chain (packets destined for this host), OUTPUT chain (packets generated by this host), or FORWARD chain (packets being routed via this host).<\/p>\n Although I kept refering to the standard chains above, it is also possible to have user-defined chains. For example: Docker adds all its rules to a DOCKER chain (rules created by Docker) and a DOCKER-USER chain (Docker related rules a user can add).<\/p>\n We know what a table is from above. Here’s a list of the available commands:<\/p>\n Note: Some of these commands take options of their own which I am skipping here.<\/p>\n Am not going into the details of the matches or targets\/ jumps either as that’s a bucketful in itself. I would like to add though that with matches one has the usual suspects like matching based on a protocol (-p, –protocol), source address (-s, –src, –source), destination address (-d, –dst, –destination), incoming interface (-i, –in-interface), outgoing interface (-o, –out-interface), fragments (-f, –fragment); or matching based on various Iptables extensions<\/a> (this is a shorter<\/a> list). The latter makes Iptables very powerful, as for instance one can match all packets generated by a process run under a specific uid\/ guid:<\/p>\n Modules might not be well documented and have some not obvious limitations (e.g. for the owner module<\/a> above).<\/p>\n","protected":false},"excerpt":{"rendered":" I made a diagram of the packet flow through the various Iptables tables and chains. I keep Googling on what table to use as there’s so many of them and it’s a bit confusing to me so I figured it’s time I put it all down somewhere. You can find a “live” version of this … Continue reading Iptables packet flow (and various others bits and bobs)<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[76],"tags":[954,556,952,953,202],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/5176"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=5176"}],"version-history":[{"count":0,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/5176\/revisions"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=5176"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=5176"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=5176"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2020\/11\/Iptables-Flow.png?resize=660%2C427&ssl=1\")
<\/a><\/p>\nRaw table<\/h3>\n
![\"\"](\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2020\/11\/Screenshot-2020-11-16-at-11.20.13.png?resize=660%2C780&ssl=1\")
<\/a><\/p>\nMangle table<\/h3>\n
\n<\/span><\/p>\n\n
\n
## mark packets to port 22\r\niptables -t mangle -A PREROUTING -p tcp --dport 22 -j MARK --set-mark 2<\/pre>\n
## restore the packet's mark from that of the connection\r\niptables -A POSTROUTING -t mangle -j CONNMARK --restore-mark\r\n\r\n## if the packet's mark is not 0 accept it\r\niptables -A POSTROUTING -t mangle -m mark ! --mark 0 -j ACCEPT\r\n\r\n## once accepted, set a mark of 1 or 2 on the packet depending on the destination port\r\niptables -A POSTROUTING -p tcp --dport 21 -t mangle -j MARK --set-mark 1\r\niptables -A POSTROUTING -p tcp --dport 80 -t mangle -j MARK --set-mark 2\r\n\r\n## now save this mark to the connection itself\r\niptables -A POSTROUTING -t mangle -j CONNMARK --save-mark<\/pre>\n
NAT table<\/h3>\n
\n
\n
\n
SNAT & MASQUERADE<\/h4>\n
## Change source addresses to 1.2.3.4.\r\niptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4\r\n\r\n## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6\r\niptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6\r\n\r\n## Change source addresses to 1.2.3.4, ports 1-1023\r\niptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023\r\n\r\n## Masquerade everything out ppp0.\r\niptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE<\/pre>\n
![\"\"](\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2020\/11\/Screenshot-2020-11-16-at-11.08.37.png?resize=660%2C385&ssl=1\")
<\/a><\/p>\nDNAT & REDIRECT<\/h4>\n
## Change destination addresses to 5.6.7.8\r\niptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8\r\n\r\n## Change destination addresses to 5.6.7.8, 5.6.7.9 or 5.6.7.10.\r\niptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8-5.6.7.10\r\n\r\n## Change destination addresses of web traffic to 5.6.7.8, port 8080.\r\niptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 \\\r\n -j DNAT --to 5.6.7.8:8080\r\n\r\n## Send incoming port-80 web traffic to our squid (transparent) proxy\r\niptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \\\r\n -j REDIRECT --to-port 3128\r\n\r\n## Send incoming SSH traffic to a specific IP to a different port\r\niptables -t nat -A PREROUTING -p tcp -d 192.168.17.21 --dport 22 \\\r\n -j REDIRECT --to-port 2222<\/pre>\n
![\"\"](\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2020\/11\/Screenshot-2020-11-16-at-11.16.11.png?resize=660%2C227&ssl=1\")
<\/a><\/p>\nFilter table<\/h3>\n
User defined chains<\/h3>\n
Syntax of Iptables<\/h3>\n
iptables [-t table] command [match] [target\/jump]<\/pre>\n
\n
\n
-A INPUT<\/code>)<\/li>\n-I INPUT 1 --dport 80 -j ACCEPT<\/code>)<\/li>\n\n
## match packets \r\niptables -A OUTPUT -m owner --uid-owner 500<\/pre>\n