Timeline for Implicit Inverses for iptables NAT Rules
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 2, 2021 at 15:19 | answer | added | Sancho Pancho | timeline score: 1 | |
| May 25, 2021 at 6:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jan 22, 2021 at 11:06 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Aug 11, 2019 at 13:18 | comment | added | Cliff Armstrong | Apologies. I meant SNAT. And I stand corrected on them not being one and the same. I've never seen a case where they weren't used interchangeably. | |
| Aug 11, 2019 at 12:51 | comment | added | igal | @CliffArmstrong In this context, DNAT stands for Destination NAT (see en.wikipedia.org/wiki/Network_address_translation#DNAT). It doesn't seem like DNAT and masquerading are two names for the same thing. For a general discussion, see the link in my previous comment - or this one: serverfault.com/questions/119365/…. Also see the Netfilter documentation: There is a specialized case of Source NAT called masquerading | |
| Aug 11, 2019 at 4:47 | comment | added | Cliff Armstrong | Oh, and DNAT and Masquerading are two names for the same thing. | |
| Aug 11, 2019 at 4:40 | comment | added | Cliff Armstrong | And @daisy was not wrong. Your #2 example is exactly describing SNAT. Done in the other direction, it's DNAT (Destination Network Address Translation). Neither create rules in netfilter tables... they use the conntrack table that's part of the kernel. | |
| Aug 11, 2019 at 4:38 | comment | added | Cliff Armstrong | What says there needs to be an accept rule for outbound (return) packets just cause there is a reject or drop rule for inbound packets? I think the problem here is you've reached the point where the firewall analogy breaks down. It's not a wall. In fact, there's no "real" structure that's analogous. Unless you explicitly block outbound packets they are all accepted. And that has no relationship to the rules governing inbound packets in any way. Like a wall that (ideally) is solid and impermeable when walking through it in one direction... but no more solid than morning fog in the other. | |
| Aug 11, 2019 at 4:04 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Mar 6, 2018 at 21:32 | answer | added | plugwash | timeline score: 3 | |
| Nov 16, 2017 at 14:18 | comment | added | igal | @meuh Thank you for the suggestion. I did not know that. I'll try it out and see if that sheds any light on the situation. | |
| Nov 16, 2017 at 14:08 | comment | added | meuh | Note, you can see the currently tracked connections with sudo conntrack -L (package conntrack-tools). | |
| Nov 16, 2017 at 7:45 | comment | added | igal | @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). | |
| Nov 16, 2017 at 7:40 | comment | added | daisy | It's called masquerading | |
| Nov 16, 2017 at 7:34 | comment | added | igal | @dirkt I'm not insisting on anything. I'm using the language which was used in the articles I referenced (where they talk about "automatically added inverse rules"). This is in part what motivated my question. I've updated my question to clarify why I find this somewhat confusing. Does my question make more sense now? | |
| Nov 16, 2017 at 7:32 | history | edited | igal | CC BY-SA 3.0 | added 787 characters in body |
| Nov 16, 2017 at 7:17 | comment | added | dirkt | 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". | |
| Nov 15, 2017 at 23:37 | comment | added | igal | @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? | |
| Nov 15, 2017 at 22:56 | comment | added | dirkt | 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. | |
| Nov 15, 2017 at 22:05 | history | asked | igal | CC BY-SA 3.0 |