No worries @ the 'tardy' reply; I too have been keeping busy with some other stuff.
RE your replies above (and thanks):
SCENARIO ONE & TWO
- under 'normal' circumstances, there would indeed be a SNAT or MASQUERADE rule, which as you observed is not there; this is just because I made the scenarios as simple as possible, and as such there is not even any outgoing-traffic rule, only the incoming DNAT rule in question. And as you have guessed (correctly) any FORWARD rules are pre-established earlier in execution, which is why the port/dest/protocols are in the separate jump-target-- sort of like a subroutine I suppose, in that they can be reused by other chains.
SCENARIO TWO (also)
- you inadvertently answered another question I had in mind about the range of IPs: I did wonder about the practicality/functionality of specifying each IP in the range separately. I hadn't considered the ip_range module for this case, and am glad you suggested that. Though it's good to know that my way would have *worked* but yes, definitely (performance-wise) it is (somewhat obviously now, I see) not really practical to have so many successive rules to traverse for what theoretically might be traffic that only needs to traverse ONE of those rules. A single 'range-oriented' rule is much better an idea.
Q: Why would you want to SNAT to an IP within the same LAN?
A: Excellent question! In reality, one usually probably would not want to do this. For the sake of creating/displaying these scenarios, I could have picked any old IP out of the air to SNAT to. HOWEVER: to get my script to produce the configurations which specifically applied to the rules I am examining here, I needed to use IP addresses that the script could associate with a network connected to one of the internal NICs of the box (dummy0 in this case), ELSE the script concludes that since the IP in question is not part of any network to which it's internal NICs are connected, it must be EXTERNAL (0/0). This then does not produce the desired configuration that I wanted (us) to examine.
It's just the way the script parses the ruleset; ie, any srce/dest IP address in a rule is evaluated as being one of:
a) an IP (or NIC) of the firewall box itself... or
b) an IP of some LAN machine on an internal network connected to the firewall box... or
c) if not a or b, it must be external to the firewall box.
..and in the case of (c) the firewall would not have produced the desired configuration that I wanted.
The idea, regardless how un-practical the rules *look*
in scenarios 3/4/5, is just to determine if I am going the right way about producing the correct iptables configuration *for*
those rules. The SNAT rule in and of itself, is not a problem (it's pretty simple), and since we last communicated here I have done some further cross-comparing of SNAT implementations in other scripts. My main concern (as stated in my last paragraph in post #12), was **whether or not I should ever require a DNAT rule (PREROUTING) to go along with any SNAT rule**
, and I think you answered that question for me when you asked:
If scenarios three, four, and five deal with SNAT/MASQUERADE, why is there any need for PREROUTING in the first place?
to which I reply 'Precisely, thank you! There IS no need
..' because if all is working as it should, the traffic returning to the SNAT address should automatically
be routed (de-SNATed) appropriately, without
need of any 'helping' DNATs!
*Whew, need to re-read this post three or four times to see if I've talked myself in a circle*
You have answered my questions (despite their apparently obscure nature
) quite to my satisfaction, and when I have a bit of time I will be putting the newest version of this firewall script into service on my firewall box (where I actually don't use any SNAT or DNAT). I have a few more changes to do to it (some of minimal impact; things like maybe taking the HELP text out of the script proper and making it a separate file) including cleaning up the SNAT code, and at that point, I will post the entire thing on pastebin. And if anyone out there is feeling brave and wants to try/test/play with it and provide feedback, that'd be great.
FWIW: part of my confusion earlier in this thread (& partial inspiration
for this thread), was caused my this page:
which is the iptables-tutorial page for DNAT.
The stuff about mixing DNATs and SNATs to properly deal with traffic originating FROM and going TO sources/services on the same network, got me mixed up; here's why:
Whereas I have my LANs DHCP/DNS/FTP and other services running ON
my firewall box, I got to thinking that I might need some funky traffic rules in order for example to get my FTP working right. Because:
am seemingly unable to configure proFTPd to listen on a particular arbitrary IP (let's say 10.10.10.123 or 192.168.x.yy) and actually be able to GET TO
that IP from a LAN machine. Instead, I need to configure proFTPd to listen on the box's internal NICs (eth0 & eth1) and I FTP to those IP addresses from the LAN machines. While it *works* this way, I believe I should be able to give proFTPd its own IP address to listen on, right?
Anyhow, perhaps this is an issue for another thread..
Many thanks, win32sux. If you have anything further, I'm listening.