Implicit Inverses for iptables NAT RulesDifference between SNAT and MasqueradeIptables: matching outgoing...
Plausibility of Ice Eaters in the Arctic
Author changing name
If a Contingency spell has been cast on a creature, does the Simulacrum spell transfer the contingent spell to its duplicate?
Why does Intel's Haswell chip allow FP multiplication to be twice as fast as addition?
Non-OR journals which regularly publish OR research
What are these two charactes marked red
How many different ways are there to checkmate in the early game?
Buffering in WGS 84 / Pseudo-Mercator 3857 using QGIS?
changing number of arguments to a function in secondary evaluation
Ex-contractor published company source code and secrets online
Is TA-ing worth the opportunity cost?
Was this a rapid SCHEDULED disassembly? How was it done?
Which ability applies to cooking meals with Cook's Utensils?
Optimal way to extract "positive part" of a multivariate polynomial
Could one become a successful researcher by writing some really good papers while being outside academia?
Why did the RAAF procure the F/A-18 despite being purpose-built for carriers?
Why aren’t emergency services using callsigns?
Does this Foo machine halt?
Word or idiom defining something barely functional
What are good ways to improve as a writer other than writing courses?
show stdout containing n with line breaks
Dropdowns & Chevrons for Right to Left languages
Was the 2019 Lion King film made through motion capture?
English - Acceptable use of parentheses in an author's name
Implicit Inverses for iptables NAT Rules
Difference between SNAT and MasqueradeIptables: matching outgoing traffic with conntrack and owner. Works with strange dropsiptables will match the following ICMP request packet as ESTABLISHED state after the first reply packet is sentHow does iptables MASQUERADE work on the incoming side?iptables redirect traffic from VPN interface to next interfaceWhat order are mangle dscp rules applied with iptables?How does NAT reflection (NAT loopback) work?Foward ports with iptables NAT rules?OUTPUT chain rules in iptablesChanging iptables NAT rules on the flyDROP or REJECT packets from PREROUTING NAT table in iptables
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?
Typically, assuming a DROP policy, for each INPUT rule in the filter table there is a corresponding OUTPUT rule which accepts related or established traffic (and vice versa). For example, to enable inbound SSH to pass through an iptables firewall there would be an INPUT rule to allow incoming connections to be established:
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
But there would also be a corresponding OUTPUT rule allowing return traffic:
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
While this kind of explicit reverse-traffic rule is necessary in the filter table, it seems that this is not the case for the NAT table.
Consider the following excerpts from various unofficial references:
- Digital Ocean: A Deep Dive into Iptables and Netfilter Architecture
Certain events will cause a table's chain to be skipped during processing. For instance, only the first packet in a connection will be evaluated against the NAT rules. Any nat decisions made for the first packet will be applied to all subsequent packets in the connection without additional evaluation. Responses to NAT'ed connections will automatically have the reverse NAT rules applied to route correctly.
- SuperUser: Internal working of rules in forward chain for NAT
But netfilter (i.e., the packet filtering/mangling framework that's the 'engine' of iptables) is smart enough. Whenever an incoming [NAT] packet is received, it's matched with netfilter's conntrack table. If the packet is a reply to an existing outgoing connection (ACK flag set, matching IP:port, matching TCP sequence number, etc), netfilter automatically performs DNAT. No need for additional rules.
- Karl Rupp: NAT Tutorial
Fortunately the netfilter framework automatically adds to each rule its inverse rule, therefore we only have to set one explicit rule. Usually the decision for one of these two rules is made by taking the one with the lower level of undetermination. For example, the rule 'Replace the sender's address for all packets from the local subnet' is much easier than 'if a client has sent something to a server, then replace the receipient in the server's response by something'. As a rule of thumb can be used that the rule that is executed first is the one that is set explicitly in the kernel.
I've perused the official netfilter documentation but I haven't managed to find this behavior mentioned anywhere. Is there an official reference that corroborates the preceding claims?
networking iptables nat
asked Nov 15 '17 at 22:05
igaligal
6,46918 silver badges40 bronze badges
bumped to the homepage by Community♦ 29 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
|
show 3 more comments
Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?
Typically, assuming a DROP policy, for each INPUT rule in the filter table there is a corresponding OUTPUT rule which accepts related or established traffic (and vice versa). For example, to enable inbound SSH to pass through an iptables firewall there would be an INPUT rule to allow incoming connections to be established:
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
But there would also be a corresponding OUTPUT rule allowing return traffic:
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
While this kind of explicit reverse-traffic rule is necessary in the filter table, it seems that this is not the case for the NAT table.
Consider the following excerpts from various unofficial references:
- Digital Ocean: A Deep Dive into Iptables and Netfilter Architecture
Certain events will cause a table's chain to be skipped during processing. For instance, only the first packet in a connection will be evaluated against the NAT rules. Any nat decisions made for the first packet will be applied to all subsequent packets in the connection without additional evaluation. Responses to NAT'ed connections will automatically have the reverse NAT rules applied to route correctly.
- SuperUser: Internal working of rules in forward chain for NAT
But netfilter (i.e., the packet filtering/mangling framework that's the 'engine' of iptables) is smart enough. Whenever an incoming [NAT] packet is received, it's matched with netfilter's conntrack table. If the packet is a reply to an existing outgoing connection (ACK flag set, matching IP:port, matching TCP sequence number, etc), netfilter automatically performs DNAT. No need for additional rules.
- Karl Rupp: NAT Tutorial
Fortunately the netfilter framework automatically adds to each rule its inverse rule, therefore we only have to set one explicit rule. Usually the decision for one of these two rules is made by taking the one with the lower level of undetermination. For example, the rule 'Replace the sender's address for all packets from the local subnet' is much easier than 'if a client has sent something to a server, then replace the receipient in the server's response by something'. As a rule of thumb can be used that the rule that is executed first is the one that is set explicitly in the kernel.
I've perused the official netfilter documentation but I haven't managed to find this behavior mentioned anywhere. Is there an official reference that corroborates the preceding claims?
networking iptables nat
asked Nov 15 '17 at 22:05
igaligal
6,46918 silver badges40 bronze badges
bumped to the homepage by Community♦ 29 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
The important keyword is conntrack. And iptables doesn't "add any implicit rules", it's just that established connections get special treatment. I have no idea about official references (kernel source code?), but the effect is easy to test.
– dirkt
Nov 15 '17 at 22:56
@dirkt From the perspective of the filter table it seems like there are implicit rules here, no? Established connections aren't automatically allowed through there, right? Or am I really missing something?
– igal
Nov 15 '17 at 23:37
Well, something additional happens, but I'm not even sure if you can express this something correctly with ipfilter rules, so I'm not sure why you insist on thinking of this something as "additional implicit rules". Think "established connections are tracked, and when the kernel code detects packets belonging to such a connection, they get additional treatment based on the existing rules. This may include evaluating existing rules for the 'reverse' case".
– dirkt
Nov 16 '17 at 7:17
1
@daisy I'm pretty sure that's not what masquerading is. Masquerading is similar to (or a type of) SNAT. The SNAT target requires the rule to specify an IP address whereas the MASQUERADE target accepts an interface (see Difference between SNAT and Masquerade). But what I'm asking about applies to DNAT as well, and there's definitely no masquerading going on there (see SNAT vs. DNAT vs. Masquerading).
– igal
Nov 16 '17 at 7:45
2
Note, you can see the currently tracked connections withsudo conntrack -L(package conntrack-tools).
– meuh
Nov 16 '17 at 14:08
|
show 3 more comments
Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?
Typically, assuming a DROP policy, for each INPUT rule in the filter table there is a corresponding OUTPUT rule which accepts related or established traffic (and vice versa). For example, to enable inbound SSH to pass through an iptables firewall there would be an INPUT rule to allow incoming connections to be established:
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
But there would also be a corresponding OUTPUT rule allowing return traffic:
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
While this kind of explicit reverse-traffic rule is necessary in the filter table, it seems that this is not the case for the NAT table.
Consider the following excerpts from various unofficial references:
- Digital Ocean: A Deep Dive into Iptables and Netfilter Architecture
Certain events will cause a table's chain to be skipped during processing. For instance, only the first packet in a connection will be evaluated against the NAT rules. Any nat decisions made for the first packet will be applied to all subsequent packets in the connection without additional evaluation. Responses to NAT'ed connections will automatically have the reverse NAT rules applied to route correctly.
- SuperUser: Internal working of rules in forward chain for NAT
But netfilter (i.e., the packet filtering/mangling framework that's the 'engine' of iptables) is smart enough. Whenever an incoming [NAT] packet is received, it's matched with netfilter's conntrack table. If the packet is a reply to an existing outgoing connection (ACK flag set, matching IP:port, matching TCP sequence number, etc), netfilter automatically performs DNAT. No need for additional rules.
- Karl Rupp: NAT Tutorial
Fortunately the netfilter framework automatically adds to each rule its inverse rule, therefore we only have to set one explicit rule. Usually the decision for one of these two rules is made by taking the one with the lower level of undetermination. For example, the rule 'Replace the sender's address for all packets from the local subnet' is much easier than 'if a client has sent something to a server, then replace the receipient in the server's response by something'. As a rule of thumb can be used that the rule that is executed first is the one that is set explicitly in the kernel.
I've perused the official netfilter documentation but I haven't managed to find this behavior mentioned anywhere. Is there an official reference that corroborates the preceding claims?
networking iptables nat
asked Nov 15 '17 at 22:05
igaligal
6,46918 silver badges40 bronze badges
Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?
Typically, assuming a DROP policy, for each INPUT rule in the filter table there is a corresponding OUTPUT rule which accepts related or established traffic (and vice versa). For example, to enable inbound SSH to pass through an iptables firewall there would be an INPUT rule to allow incoming connections to be established:
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
But there would also be a corresponding OUTPUT rule allowing return traffic:
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
While this kind of explicit reverse-traffic rule is necessary in the filter table, it seems that this is not the case for the NAT table.
Consider the following excerpts from various unofficial references:
- Digital Ocean: A Deep Dive into Iptables and Netfilter Architecture
Certain events will cause a table's chain to be skipped during processing. For instance, only the first packet in a connection will be evaluated against the NAT rules. Any nat decisions made for the first packet will be applied to all subsequent packets in the connection without additional evaluation. Responses to NAT'ed connections will automatically have the reverse NAT rules applied to route correctly.
- SuperUser: Internal working of rules in forward chain for NAT
But netfilter (i.e., the packet filtering/mangling framework that's the 'engine' of iptables) is smart enough. Whenever an incoming [NAT] packet is received, it's matched with netfilter's conntrack table. If the packet is a reply to an existing outgoing connection (ACK flag set, matching IP:port, matching TCP sequence number, etc), netfilter automatically performs DNAT. No need for additional rules.
- Karl Rupp: NAT Tutorial
Fortunately the netfilter framework automatically adds to each rule its inverse rule, therefore we only have to set one explicit rule. Usually the decision for one of these two rules is made by taking the one with the lower level of undetermination. For example, the rule 'Replace the sender's address for all packets from the local subnet' is much easier than 'if a client has sent something to a server, then replace the receipient in the server's response by something'. As a rule of thumb can be used that the rule that is executed first is the one that is set explicitly in the kernel.
I've perused the official netfilter documentation but I haven't managed to find this behavior mentioned anywhere. Is there an official reference that corroborates the preceding claims?
networking iptables nat
networking iptables nat
asked Nov 15 '17 at 22:05
igaligal
6,46918 silver badges40 bronze badges
asked Nov 15 '17 at 22:05
igaligal
6,46918 silver badges40 bronze badges
edited Nov 16 '17 at 7:32
igal
asked Nov 15 '17 at 22:05
igaligal
6,46918 silver badges40 bronze badges
asked Nov 15 '17 at 22:05
igaligal
6,46918 silver badges40 bronze badges
asked Nov 15 '17 at 22:05
igaligal
6,46918 silver badges40 bronze badges
6,46918 silver badges40 bronze badges
bumped to the homepage by Community♦ 29 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 29 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 29 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
The important keyword is conntrack. And iptables doesn't "add any implicit rules", it's just that established connections get special treatment. I have no idea about official references (kernel source code?), but the effect is easy to test.
– dirkt
Nov 15 '17 at 22:56
@dirkt From the perspective of the filter table it seems like there are implicit rules here, no? Established connections aren't automatically allowed through there, right? Or am I really missing something?
– igal
Nov 15 '17 at 23:37
Well, something additional happens, but I'm not even sure if you can express this something correctly with ipfilter rules, so I'm not sure why you insist on thinking of this something as "additional implicit rules". Think "established connections are tracked, and when the kernel code detects packets belonging to such a connection, they get additional treatment based on the existing rules. This may include evaluating existing rules for the 'reverse' case".
– dirkt
Nov 16 '17 at 7:17
1
@daisy I'm pretty sure that's not what masquerading is. Masquerading is similar to (or a type of) SNAT. The SNAT target requires the rule to specify an IP address whereas the MASQUERADE target accepts an interface (see Difference between SNAT and Masquerade). But what I'm asking about applies to DNAT as well, and there's definitely no masquerading going on there (see SNAT vs. DNAT vs. Masquerading).
– igal
Nov 16 '17 at 7:45
2
Note, you can see the currently tracked connections withsudo conntrack -L(package conntrack-tools).
– meuh
Nov 16 '17 at 14:08
|
show 3 more comments
The important keyword is conntrack. And iptables doesn't "add any implicit rules", it's just that established connections get special treatment. I have no idea about official references (kernel source code?), but the effect is easy to test.
– dirkt
Nov 15 '17 at 22:56
@dirkt From the perspective of the filter table it seems like there are implicit rules here, no? Established connections aren't automatically allowed through there, right? Or am I really missing something?
– igal
Nov 15 '17 at 23:37
Well, something additional happens, but I'm not even sure if you can express this something correctly with ipfilter rules, so I'm not sure why you insist on thinking of this something as "additional implicit rules". Think "established connections are tracked, and when the kernel code detects packets belonging to such a connection, they get additional treatment based on the existing rules. This may include evaluating existing rules for the 'reverse' case".
– dirkt
Nov 16 '17 at 7:17
1
@daisy I'm pretty sure that's not what masquerading is. Masquerading is similar to (or a type of) SNAT. The SNAT target requires the rule to specify an IP address whereas the MASQUERADE target accepts an interface (see Difference between SNAT and Masquerade). But what I'm asking about applies to DNAT as well, and there's definitely no masquerading going on there (see SNAT vs. DNAT vs. Masquerading).
– igal
Nov 16 '17 at 7:45
2
Note, you can see the currently tracked connections withsudo conntrack -L(package conntrack-tools).
– meuh
Nov 16 '17 at 14:08
The important keyword is conntrack. And iptables doesn't "add any implicit rules", it's just that established connections get special treatment. I have no idea about official references (kernel source code?), but the effect is easy to test.
– dirkt
Nov 15 '17 at 22:56
The important keyword is conntrack. And iptables doesn't "add any implicit rules", it's just that established connections get special treatment. I have no idea about official references (kernel source code?), but the effect is easy to test.
– dirkt
Nov 15 '17 at 22:56
@dirkt From the perspective of the filter table it seems like there are implicit rules here, no? Established connections aren't automatically allowed through there, right? Or am I really missing something?
– igal
Nov 15 '17 at 23:37
@dirkt From the perspective of the filter table it seems like there are implicit rules here, no? Established connections aren't automatically allowed through there, right? Or am I really missing something?
– igal
Nov 15 '17 at 23:37
Well, something additional happens, but I'm not even sure if you can express this something correctly with ipfilter rules, so I'm not sure why you insist on thinking of this something as "additional implicit rules". Think "established connections are tracked, and when the kernel code detects packets belonging to such a connection, they get additional treatment based on the existing rules. This may include evaluating existing rules for the 'reverse' case".
– dirkt
Nov 16 '17 at 7:17
Well, something additional happens, but I'm not even sure if you can express this something correctly with ipfilter rules, so I'm not sure why you insist on thinking of this something as "additional implicit rules". Think "established connections are tracked, and when the kernel code detects packets belonging to such a connection, they get additional treatment based on the existing rules. This may include evaluating existing rules for the 'reverse' case".
– dirkt
Nov 16 '17 at 7:17
1
1
@daisy I'm pretty sure that's not what masquerading is. Masquerading is similar to (or a type of) SNAT. The SNAT target requires the rule to specify an IP address whereas the MASQUERADE target accepts an interface (see Difference between SNAT and Masquerade). But what I'm asking about applies to DNAT as well, and there's definitely no masquerading going on there (see SNAT vs. DNAT vs. Masquerading).
– igal
Nov 16 '17 at 7:45
@daisy I'm pretty sure that's not what masquerading is. Masquerading is similar to (or a type of) SNAT. The SNAT target requires the rule to specify an IP address whereas the MASQUERADE target accepts an interface (see Difference between SNAT and Masquerade). But what I'm asking about applies to DNAT as well, and there's definitely no masquerading going on there (see SNAT vs. DNAT vs. Masquerading).
– igal
Nov 16 '17 at 7:45
2
2
Note, you can see the currently tracked connections with
sudo conntrack -L (package conntrack-tools).– meuh
Nov 16 '17 at 14:08
Note, you can see the currently tracked connections with
sudo conntrack -L (package conntrack-tools).– meuh
Nov 16 '17 at 14:08
|
show 3 more comments
1 Answer
1
active
oldest
votes
Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?
Not exactly
Your first two quotes are correct, the third is confused ramblings of someone who doesn't understand how the system works.
iptables nat (unlike iptables filtering) works on connections. The first packet of the connection passes through the nat tables and is translated according to it. Later packets belonging to the same connection do not pass through the nat tables they are simply translated accoridng to the rules established when the first packet was translated.
The iptables man page https://linux.die.net/man/8/iptables documents that the nat table is consulted for "the first packet of a connection" and the man page section for the DNAT and SNAT target say "(and all future packets in this connection will also be mangled)".
Unfortunately I haven't seen any official documentation which goes into more depth than that. My go-to reference for iptables is the frozentux iptables tutorial but I don't think it's official.
answered Mar 6 '18 at 21:32
plugwashplugwash
2,0098 silver badges20 bronze badges
It sounds to me like you're just repeating a statement that's already in the body of the question. What I was asking for was a reference to where this is explained in the official documentation. Am I missing something here?
– igal
Mar 6 '18 at 21:52
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f404869%2fimplicit-inverses-for-iptables-nat-rules%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?
Not exactly
Your first two quotes are correct, the third is confused ramblings of someone who doesn't understand how the system works.
iptables nat (unlike iptables filtering) works on connections. The first packet of the connection passes through the nat tables and is translated according to it. Later packets belonging to the same connection do not pass through the nat tables they are simply translated accoridng to the rules established when the first packet was translated.
The iptables man page https://linux.die.net/man/8/iptables documents that the nat table is consulted for "the first packet of a connection" and the man page section for the DNAT and SNAT target say "(and all future packets in this connection will also be mangled)".
Unfortunately I haven't seen any official documentation which goes into more depth than that. My go-to reference for iptables is the frozentux iptables tutorial but I don't think it's official.
answered Mar 6 '18 at 21:32
plugwashplugwash
2,0098 silver badges20 bronze badges
It sounds to me like you're just repeating a statement that's already in the body of the question. What I was asking for was a reference to where this is explained in the official documentation. Am I missing something here?
– igal
Mar 6 '18 at 21:52
add a comment |
Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?
Not exactly
Your first two quotes are correct, the third is confused ramblings of someone who doesn't understand how the system works.
iptables nat (unlike iptables filtering) works on connections. The first packet of the connection passes through the nat tables and is translated according to it. Later packets belonging to the same connection do not pass through the nat tables they are simply translated accoridng to the rules established when the first packet was translated.
The iptables man page https://linux.die.net/man/8/iptables documents that the nat table is consulted for "the first packet of a connection" and the man page section for the DNAT and SNAT target say "(and all future packets in this connection will also be mangled)".
Unfortunately I haven't seen any official documentation which goes into more depth than that. My go-to reference for iptables is the frozentux iptables tutorial but I don't think it's official.
answered Mar 6 '18 at 21:32
plugwashplugwash
2,0098 silver badges20 bronze badges
It sounds to me like you're just repeating a statement that's already in the body of the question. What I was asking for was a reference to where this is explained in the official documentation. Am I missing something here?
– igal
Mar 6 '18 at 21:52
add a comment |
Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?
Not exactly
Your first two quotes are correct, the third is confused ramblings of someone who doesn't understand how the system works.
iptables nat (unlike iptables filtering) works on connections. The first packet of the connection passes through the nat tables and is translated according to it. Later packets belonging to the same connection do not pass through the nat tables they are simply translated accoridng to the rules established when the first packet was translated.
The iptables man page https://linux.die.net/man/8/iptables documents that the nat table is consulted for "the first packet of a connection" and the man page section for the DNAT and SNAT target say "(and all future packets in this connection will also be mangled)".
Unfortunately I haven't seen any official documentation which goes into more depth than that. My go-to reference for iptables is the frozentux iptables tutorial but I don't think it's official.
answered Mar 6 '18 at 21:32
plugwashplugwash
2,0098 silver badges20 bronze badges
Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?
Not exactly
Your first two quotes are correct, the third is confused ramblings of someone who doesn't understand how the system works.
iptables nat (unlike iptables filtering) works on connections. The first packet of the connection passes through the nat tables and is translated according to it. Later packets belonging to the same connection do not pass through the nat tables they are simply translated accoridng to the rules established when the first packet was translated.
The iptables man page https://linux.die.net/man/8/iptables documents that the nat table is consulted for "the first packet of a connection" and the man page section for the DNAT and SNAT target say "(and all future packets in this connection will also be mangled)".
Unfortunately I haven't seen any official documentation which goes into more depth than that. My go-to reference for iptables is the frozentux iptables tutorial but I don't think it's official.
answered Mar 6 '18 at 21:32
plugwashplugwash
2,0098 silver badges20 bronze badges
edited Mar 8 '18 at 20:53
answered Mar 6 '18 at 21:32
plugwashplugwash
2,0098 silver badges20 bronze badges
answered Mar 6 '18 at 21:32
plugwashplugwash
2,0098 silver badges20 bronze badges
answered Mar 6 '18 at 21:32
plugwashplugwash
2,0098 silver badges20 bronze badges
2,0098 silver badges20 bronze badges
It sounds to me like you're just repeating a statement that's already in the body of the question. What I was asking for was a reference to where this is explained in the official documentation. Am I missing something here?
– igal
Mar 6 '18 at 21:52
add a comment |
It sounds to me like you're just repeating a statement that's already in the body of the question. What I was asking for was a reference to where this is explained in the official documentation. Am I missing something here?
– igal
Mar 6 '18 at 21:52
It sounds to me like you're just repeating a statement that's already in the body of the question. What I was asking for was a reference to where this is explained in the official documentation. Am I missing something here?
– igal
Mar 6 '18 at 21:52
It sounds to me like you're just repeating a statement that's already in the body of the question. What I was asking for was a reference to where this is explained in the official documentation. Am I missing something here?
– igal
Mar 6 '18 at 21:52
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f404869%2fimplicit-inverses-for-iptables-nat-rules%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The important keyword is conntrack. And iptables doesn't "add any implicit rules", it's just that established connections get special treatment. I have no idea about official references (kernel source code?), but the effect is easy to test.
– dirkt
Nov 15 '17 at 22:56
@dirkt From the perspective of the filter table it seems like there are implicit rules here, no? Established connections aren't automatically allowed through there, right? Or am I really missing something?
– igal
Nov 15 '17 at 23:37
Well, something additional happens, but I'm not even sure if you can express this something correctly with ipfilter rules, so I'm not sure why you insist on thinking of this something as "additional implicit rules". Think "established connections are tracked, and when the kernel code detects packets belonging to such a connection, they get additional treatment based on the existing rules. This may include evaluating existing rules for the 'reverse' case".
– dirkt
Nov 16 '17 at 7:17
1
@daisy I'm pretty sure that's not what masquerading is. Masquerading is similar to (or a type of) SNAT. The SNAT target requires the rule to specify an IP address whereas the MASQUERADE target accepts an interface (see Difference between SNAT and Masquerade). But what I'm asking about applies to DNAT as well, and there's definitely no masquerading going on there (see SNAT vs. DNAT vs. Masquerading).
– igal
Nov 16 '17 at 7:45
2
Note, you can see the currently tracked connections with
sudo conntrack -L(package conntrack-tools).– meuh
Nov 16 '17 at 14:08