In simple words, iptables is linux basic firewall software. Just like a mini version of firewall , it does packet filtering whether to allows, blocks or forward packets.<\/p>\n\n\n\n
- \n
- Iptables contains multiple tables to manage the rules. Based on the type of rules and its applicability , user has to create and add rules to a particular table to make the rules work correctly. For example, if a rule is required for network translation, it will be put in nat table. If the rules is to allow or to discard packets , then it will be put in filter table.<\/li>\n\n\n\n
- Inside each iptables table, rules are further organized into separate chains. Chains are mapped to kernel netfilters hooks which decide when the rules will be triggers. We can have a single chain or cascading chains based of requirement. A chain can be empty also.<\/li>\n\n\n\n
- At the end, we have rules which are the last mile resource, which decides the fate of the packets. Rules can accept, block, forward packets. Rules can accept, block, forward packets coming from certain subnets, for a particular port etc. The outcome of a rule is called Policy. The policy decides whether to drop, accept or reject the traffic.<\/li>\n<\/ul>\n\n\n\n
Successor of iptables is nftables<\/a>, in modern day system, it has been seen that nftables are getting used, however still iptables are used in the background in order to support legacy network softwares.<\/p>\n\n\n\n
Iptables table and their applicable chains:<\/strong><\/h2>\n\n\n\n
![\"\"](\"https:\/\/aiinfrahub.com\/wp-content\/uploads\/2025\/03\/image-5.png\")
<\/figure>\n\n\n\nTables and their usage:<\/strong><\/h2>\n\n\n\n
![\"\"](\"https:\/\/aiinfrahub.com\/wp-content\/uploads\/2025\/03\/image-4.png\")
<\/figure>\n\n\n\nBuilt-in Chains (default chains provided by Netfilter):<\/strong><\/h2>\n\n\n\n
![\"\"](\"https:\/\/aiinfrahub.com\/wp-content\/uploads\/2025\/03\/image-6.png\")
<\/figure>\n\n\n\nDemo:<\/h2>\n\n\n\n
As we understood the theory and concepts of iptables, lets get our hand dirty.<\/p>\n\n\n\n
In this demo, we will deploy simple Kubernetes application with two replicas and exposed it using a NodePort service. After then we will analyze
iptables<\/code> rules to uncover how Kubernetes routes and load-balances traffic at the network level.<\/p>\n\n\n\nFilename: hello-app-deployment.yaml <\/p>\n\n\n\n
apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: hello-app\nspec:\n replicas: 2\n selector:\n matchLabels:\n app: hello-app\n template:\n metadata:\n labels:\n app: hello-app\n spec:\n containers:\n - name: hello-app\n image: gcr.io\/google-samples\/hello-app:1.0\n ports:\n - containerPort: 8080\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: hello-app-service\nspec:\n type: NodePort\n selector:\n app: hello-app\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080<\/code><\/pre>\n\n\n\n\n\nhost1$kubectl apply -f hello-app-deployment.yaml \nhost1$kubectl get svc\n<\/strong>NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE\nhello-app-service NodePort 10.104.81.240 <none> 80:30811\/TCP 2m57s\nkubernetes ClusterIP 10.96.0.1 <none> 443\/TCP 20d\nhost1$kubectl get pods -o wide\n<\/strong>NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES\nhello-app-58d97c88d4-h7s2n 1\/1 Running 0 3m14s 172.16.166.130 host1 <none> <none>\nhello-app-58d97c88d4-pkh8c 1\/1 Running 0 3m14s 172.16.192.89 host2 <none> <none><\/code><\/pre>\n<\/div>\n<\/div>\n\n\n\nObservation<\/strong>: We can see that after the deployment, we have 2 pods running. In services, apart from NodePort, note that ClusterIP service is assigned by default.<\/p>\n\n\n\n
Now suppose, a user fires a curl command “curl http:\/\/<NodeIP>:30811”<\/strong>. Lets trace how this command will reach the end mile resource ie pods behind the NodePort service with the help of iptables.<\/p>\n\n\n\n
Lets check the iptables rules.<\/p>\n\n\n\n
host1$sudo iptables -n -t nat -L KUBE-SERVICES\nChain KUBE-SERVICES (2 references)\ntarget prot opt source destination\nKUBE-SVC-NGVTFAARHANBXKRK tcp -- 0.0.0.0\/0 10.104.148.121 \/* \nKUBE-SVC-YG6ZEOBCLVGD3AJB tcp -- 0.0.0.0\/0 10.104.81.240 \/* default\/hello-app-service cluster IP *\/\n<\/strong>KUBE-NODEPORTS all -- 0.0.0.0\/0 0.0.0.0\/0 \/* kubernetes service nodeports; NOTE: this must be the last rule in this chain *\/ ADDRTYPE match dst-type LOCAL<\/code><\/pre>\n\n\n\nObservation<\/strong>: In NAT table, KUBE-SVC-XXXX chain handles that any incoming tcp traffic or curl request coming from any source will get directed to NodePort IP ie 10.104.81.240<\/strong>. Internally KUBE-SVC-XXXX chain does the load balancing means direct the traffic to one of the 2 pods managed by the service. Lets see how ?<\/p>\n\n\n\n
host1$sudo iptables -n -t nat -L KUBE-SVC-YG6ZEOBCLVGD3AJB\nChain KUBE-SVC-YG6ZEOBCLVGD3AJB (2 references)\ntarget prot opt source destination\nKUBE-MARK-MASQ tcp -- !172.16.0.0\/16 10.104.81.240 \/* default\/hello-app-service cluster IP *\/\nKUBE-SEP-7I3URQ2O437FVP5U all -- 0.0.0.0\/0 0.0.0.0\/0 \/* default\/hello-app-service -> 172.16.166.130:8080 *\/ statistic mode random probability 0.50000000000\nKUBE-SEP-PSPHHDAXPY5YRT7B all -- 0.0.0.0\/0 0.0.0.0\/0 \/* default\/hello-app-service -> 172.16.192.89:8080 *\/<\/strong><\/code><\/pre>\n\n\n\nObservation<\/strong>: In NAT table, deep dive inside KUBE-SVC-YG6ZEOBCLVGD3AJB chain reveals that service will load balance the request between two pods randomly with 0.5 % probability.<\/p>\n\n\n\n
host1$sudo iptables -n -t nat -L KUBE-SEP-PSPHHDAXPY5YRT7B\nChain KUBE-SEP-PSPHHDAXPY5YRT7B (1 references)\ntarget prot opt source destination\nKUBE-MARK-MASQ all -- 172.16.192.89 0.0.0.0\/0 \/* default\/hello-app-service *\/\nDNAT tcp -- 0.0.0.0\/0 0.0.0.0\/0 \/* default\/hello-app-service *\/ tcp to:172.16.192.89:8080<\/code><\/pre>\n\n\n\nObservation<\/strong>: Ultimately the leaf chain where the request is landing ie one of the pod IP.<\/p>\n\n\n\n
By breaking down the iptables rules, we\u2019ve gained basic insights of Kubernetes cluster networking uncovering how traffic seamlessly flows from external users to application pods.<\/p>\n\n\n\n
In this article, we have covered “iptables” tables dealing with ipv4 traffic, however same concept applies to “ip6tables” for ipv6 traffic.<\/p>\n\n\n\n
In next article, we will be covering Kubernetes services focusing on the networking aspects.<\/p>\n\n\n\n
Good Bye for now. Stay tuned.<\/p>\n\n\n\n
References:<\/h2>\n\n\n\n
https:\/\/en.wikipedia.org\/wiki\/Iptables<\/a><\/p>\n\n\n\n
https:\/\/man7.org\/linux\/man-pages\/man8\/iptables.8.html<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
As per Wiki definition, \u201ciptables is a user-space utility program that allows a system administrator to configure the IP packet filter rules of the Linux kernel firewall, implemented as different Netfilter modules\u201d. In simple words, iptables is linux basic firewall software. Just like a mini version of firewall , it does packet filtering whether to allows, blocks or forward packets. Successor of iptables is nftables, in modern … Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":84,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,4],"tags":[2],"class_list":["post-82","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-kubernetes","category-networking","tag-networking"],"_links":{"self":[{"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/posts\/82","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/comments?post=82"}],"version-history":[{"count":8,"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/posts\/82\/revisions"}],"predecessor-version":[{"id":105,"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/posts\/82\/revisions\/105"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/media\/84"}],"wp:attachment":[{"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/media?parent=82"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/categories?post=82"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/aiinfrahub.com\/about-us\/wp-json\/wp\/v2\/tags?post=82"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}