iptables.. Bit of guidance/oversight with my SNAT and DNAT stuff please?
 

Hi people! :)
For reference further down this thread: The machines involved..
MY LAN MACHINE: 1.8GHz x86, Slackware 11, eth0=192.168.0.30, dummy0=192.168.1.31, dummy1=192.168.2.32
FIREWALL MACHINE: 333MHz x86, Slackware 11, eth0=192.168.0.10, eth1=192.168.2.10, ppp0-dialup
OTHER LAN MACHINE:1.2GHz x86, Slack/WinXP......................eth0=192.168.2.30

OK, I have been working extensively on an iptables firewall for some time. I started with a pre-existing firewall script a long time ago and have improved and repaired a whack of it. And since actually setting up an old/spare computer with a modem and two ethernet cards, to be our LAN's "firewall/FTP/DNS/DHCP server machine", I have really been intensely going at this firewall script.
It's a bash script, which generates an iptables-restore script from the human-readable rules entered in the config file.
The firewall works great as far as NAT/Masquerading our dialup connection for our LAN machines to share, but I am at a point now where I am working on implementing/completing some areas of the firewall script which the original author did not implement or complete; specifically DNAT and SNAT.

I have loads of documentation (from netfilter.org and others) on networking, ethernet, iptables tutorials, NAT, etc., and by now, I am comfortable that I have a "reasonable working understanding" of iptables. What I am looking for in posting this post, is for someone who has a REALLY good understanding of iptables to have a look at some stuff here, and tell me if things look good, or if I am out to lunch! (p.s. - I'm not fully out to lunch, but partially maybe-- I also have Wireshark on both the firewall machine AND my main machine, and it has shown me that the actual SNATing of my packets is working; I just haven't yet tried actually some real traffic to see if a connection can be established & maintained-- read on..)

I have been doing testing and work on the script, on my main computer, which has one real NIC (eth0) and two dummy NICs (dummy0 and dummy1) but for obvious reasons, without REAL NICS and machines connected to them, only so much testing can be done. SO, before actually swapping my latest version of the firewall script onto the real firewall machine, which has three REAL NICS (ppp0, eth0, eth1) and machines connected to them, I would like to know that I am reasonably on track here with this SNAT situation; otherwise I spend a lot of time fiddling with and restarting the firewall on the real firewall machine, which annoys people and interrupts applications using the connection ;)

SCENARIO ONE (of four): a basic SNAT rule, with a single ip/port target:

Rule 192.168.1.222 internet http snat=176.111.1.111:8888

Intention: http traffic from 192.168.1.222 (a phony LAN machine on interface dummy0) to the internet, SNAT the source address to 176.111.1.111:8888

Here's the relevant snippets of my *filter and *nat iptables-restore script with the lines resulting from my processing of the TEST RULE above:
Now, some explanation:
1 - for the sake of this thread, 'TCP-ACCEPT-C' and 'TCP-ACCEPT-S' shall be interpreted as 'ACCEPT'
2 - for this testing, 'eth0' is the External Interface (to the internet) and 'dummy0' is where phony machine 192.168.1.222 is connected
3 - Let's ignore that I am SNATing to an address that is not an internet-allowed address (176.111.1.111); it could be anything.
4 - Why the DNAT line there? Well, I have read in MOST places that SNATted traffic is automatically UN-SNATted on its return trip, and many examples of one simple SNAT line doing the job are floating around the net. However, I have ALSO read that SNATted traffic needs accompanying rules, such as those in the *filter table above, and an implicit DNAT line to UN-SNAT the returning traffic and send it along to the right place. I don't know which is correct, or if both situations are correct sometimes... That's why I am here.
An example of a situation allegedly possibly needing an implicit DNAT to alter the returning SNAT traffic, is where a service is running ON the actual FIREWALL machine itself, such as in my case here where my firewall box runs the DNS/FTP/DHCP services. Is this right? Wrong? Maybe if the DNAT is not really needed, will it hurt to have it there?

SO, I think that's enough info for now.. Maybe.. If you have some constructive input, I would be very happy to hear it, because it seems many of the examples and tutorials I have been reading are verbatim copies of each other, and/or describe only very basic networks without using combinations of functionality, i.e. NAT only, or DNAT only, etc.
I'm not asking for anyone to hold my hand; rather just maybe if this looks right, somewhat wrong, or totally wrong, (and if wrong, where), and if you want to give me link(s) to where I can learn for myself more complex iptables, more tutorials, etc, please do.
Thanks very much everyone!
Once I get this basic SNAT thing figured, the next 'SCENARIO' will be SNATting to a range of IPs. Wheeee!

Sasha
EDIT #1 - before I even post this, I see this thread:
http://www.linuxquestions.org/questi...rading-264649/
.. where the user in post#4 states that SNAT does NOT in fact need a DNAT statement on any returning traffic. Is this correct? is it ALWAYS correct?
And then, what about my forwarding chains? Are they still needed? The traffic IS after all being forwarded, is it not?

From the requirements you've described, you don't need DNAT. Connection tracking will take care of the returning packets with no problem. As for SNAT/MASQUERADE, you should pick one method instead of using both, unless you have a particular need for that, which AFAICT you don't. I'll use MASQUERADE in my examples. It sounds like you basically will have one GNU/Linux firewall with three interfaces, one for Internet (ppp0) and two for LANs (eth0 and eth1). You wish for the hosts on these LANs to enjoy Internet access via this firewall. Is this correct? If so, this sort of thing could be done like:The first FORWARD rule takes care of the returning packets. The second and third rules allow for outbound connections to be initiated. If you wish to clamp down further on the packets, you just need to use more specific matches in the FORWARD rules. For example, let's say that you don't want the clients on the second LAN (connected to eth1) to be able to start connections other than to TCP ports 443 and 80. You could enforce that like:Then lets say you wish to deny the first LAN the ability to ping hosts on the Internet (while not disturbing their current freedom any further than that). You could do that like:Now you've got a setup where the first LAN can do anything except ping, and the second LAN can only connect to TCP ports 443 and 80. I hope these examples help you out. Good luck.

Hi win32sux,

Thank you very much for your input!

I must clarify/reiterate though: as I mentioned in my first para above, the firewall is and has been doing the masquerading for our LAN for some time. It uses MASQUERADE to allow our lan machines to use the ppp0 connection, and is in use as we speak, working very nicely.

My intention (hence my request for help) here is not to do something that *I* need here for sharing our ppp0 connection, rather my intention is to make all possible iptables functionality available to a user of this firewall script, should I make it available for download to other people, and/or forward it to the original author of the script, should he be interested.

As an example: The firewall script when I first got it, claimed to offer DNAT functionality. However, the DNAT functionality did not actually work (i.e. if I made a DNAT rule in the config file, I would either get errors from iptables when it executed the iptables-restore script, or the DNAT functionality plain did not work).
As example #2: SNAT was not built into the script at ALL when I got it. I have since incorporated it, but want to be reasonably confident that I have the SNAT rule-parsing and chain-building properly coded before I begin testing some SNAT routings on my actual firewall machine.
Example #3: Originally the firewall did not allow for DNAT/SNAT to address-ranges nor port-ranges, but it does now, as well as supporting the --random switch with DNAT (randomly chooses a source-port if none is specified), and also it now supports comma-separated lists of source and destination addresses in rules, AND does resolving of domain-names in rules.

My goal is to just implement as much useful functionality as possible, not for myself necessarily, but for anyone who might end up using this sometime :)

For the record, the MASQUERADE target in my [code] tags in my first post is for masquerading the ppp0 dynamic connection for the LAN. Also for the record, state-matching, TOS, ICMP-limiting, SYNcookies, and all that good stuff is dealt with in the TCP-ACCEPT-S and TCP-ACCEPT-C targets.

Sasha

Okay, it sounds like you've got a script and you want some feedback on it, right?

If so, you should probably post it. :)

EDIT: Please accept my apologies if I still don't properly understand what exactly you are asking.

:) ..apology accepted but unnecessary, I really appreciate your interest.

I don't directly want feedback on the bash script itself, but rather on the iptables-restore script I am generating with it. I want to know if I have/am coding the sections of the firewall in question correctly, so that the proper iptables-restore code is coming out. The sections in question being the SNAT and DNAT pieces.

I had thought of posting it (the firewall script), but it is VERY long (90 KB currently), and from experience, it is too long to post -- LQ (the site) has refused in the past to accept posts above *some large length* when I have tried to paste giant posts in.. Plus, (and don't get me wrong here) a person, any person, regardless of BASH abilities, would prolly want to examine the whole script for days/weeks to really understand what's going on; there are many functions, gawk's everywhere, and more variables and arrays than one can shake a bag of sticks at ;) it's too big to look for a minute and say 'ahh there's the problem'. I am not an expert at anything (ie BASH) by any stretch, but I have been staring at and editing this thing for months now, and I have a pretty good grip on it; however the original author was evidently a VERY crafty BASH programmer, far more so than I am, and has used a lot of really interesting, confusing, convoluted, methods of doing stuff. It has been educational to say the least. I could email it to you if you'd like to see.

What I COULD do, which is probably more appropriate, is post the iptables-restore scripts generated by the individual rules I would like feedback on!
Like, I would put one single rule into the config file, such as the SNAT rule I posted above, and then post here the iptables-restore script (the *filter and *nat scripts-- *mangle works fine).. Then repeat for the other rule (DNAT) that I would like your opinions on.

If I am slow to reply tonight, it's because we are now watching a movie; I'll check in later though :)
Let me know what you think; and thanks again.
Sasha

<cough>Pastebin</cough> :)

Yeah, I was thinking about the same type of cough, XavierP. :)

@GrapefruiTgirl: It's up to you but personally I find it much easier to read iptables scripts (instead of iptables configurations). Maybe it's just me, though. Of course, I'll try and pitch in regardless of what state you decide to show us. That said, your description makes this script sound really complicated, and it begs the question: Why would you want to use such a script in the first place? I've always thought of firewalls scripts as "the simpler the better".

;) Thanks for the [cough]pastebin[/cough] idea! Believe it or not I have never pasted anything there or elsewhere, but I will look into it. Prolly tomorrow as it is rather late here now and it has been a long day.

@win32sux -- please clarify for me which is which of your post #7 above RE: iptables 'scripts' vs. iptables 'configurations'. As in, do you mean the format I posted in my first post, or would you prefer the BASH? Hopefully you prefer the iptables 'script', not the bash script; I'm not kidding when I say this BASH thing is complicated :D but I will post whichever you like, or both.
I think the easiest thing for all of us is for me to describe what traffic I want, like "I want http traffic from the internet to be DNATed to xxx.yyy.xxx.zzz" and then show you the iptables-restore script that my BASH thing produces and ask "Does this look right?", but again, whatever is best, or both.

Why would I want to use such a complicated script? Well, the script itself *is* huge and perhaps unwieldy by some opinions/standards, BUT: once it is completely done (if ever) it does make it SO simple to add or remove or change traffic rules really precisely, using simple rules written in english. And, there are already a lot of different things incorporated into it (via config file), including a large variety of protocols supported, TOS, stateful match/conntracking, limit match, source/destination as 'lan|hostname|ip|ip-MAC|internet|etc..', automatic download of and DROPping of IANA reserved/unallocated addresses list, multiple configuration files support, rule appending (temporary or written into config file), multiple interfaces, enable/disable tables independently, script output to screen or file, iptables counters output.... It really is quite feature-packed. And it is far quicker to enter or adjust a few rules like so:
than it would be (IMHO) to be always editing the BASH equivalent of the above when a change in rules or a new service is needed.
Finally, and most importantly (lol) it keeps me BUSY and exercises my brain :D!!

I meant Bash, which is what iptables scripts are usually written in. What you posted originally wasn't a script, it was the partial contents of an iptables configuration file (which is what the iptables-save binary generates). But yeah, the optimal thing would most certainly be to post both the script you have and the configuration it currently gives you. That way members can inspect whichever they feel more comfortable doing. I personally believe that for viewing configurations it's more effective to use the iptables listing commands (iptables -nvL, etc). This way you see what really is active, instead of what you intend to be active (this is especially important if you've edited the iptables configuration file by hand, since that can be quite error-prone).

Good point RE: listing the active stuff rather than looking at the configuration file.
Here's what I am starting to do now:
I'll disable all extra config options of the firewall, as well as setting it up with only ONE external and ONE internal interface, thereby reducing/removing extra configuration lines that are irrelevant to what I'm trying to show here; so, the output of `iptables -nL` will give us pretty much *just* the stuff pertaining to the traffic-rule we're examining.
Once I have assembled the various desired traffic rules we are examining, and their respective `iptables -nL` outputs, I will go to pastebin and stick it all up there.

Meanwhile, on a related subject, if someone would care to enlighten me a little on something:

I don't think I understand how a bitmask works with regards to IP addresses. I DO understand binary no problem, ie 8 bits to a byte, value of each bit, converting binary to decimal, etc., but for example I don't understand the exact meaning of:

192.168.0.0/255.255.255.0 or
192.168.0.10/24 or
192.168.0.10/8

except to say that for example in "192.168.0.10/8" I believe the /8 refers to the 4th of the quad (the .10) correct? But what does the /8 signify? How does it affect the ".10" and by extension what range of IPs does /8 imply?

Thanks! I'll post again when I have the pastebin stuff set up.

Sasha

Sounds like a plan. Make sure you use -nvL, though, not just -nL.

About your other question, Wikipedia has got a pretty decent article on the subject.

@win32sux: Thanks for the pointer to the wikipedia page on subnetting; it was indeed a 'pretty decent article' and I understand what it said. It confirmed what I suspected (that I had no idea at all how the /suffix affected an IP address :)) and it also un-confirmed something I had hoped (that the /suffix could be used to specify a small range of IPs, such as for example 1.2.3.10-1.2.3.20).

So... That pastebin thing couldn't be any simpler! I have pasted two scenarios (the DNAT scenarios) at the pastebin link below, each with a description of the intended traffic, and the output of `iptables -nvL` for consideration by anyone interested. I basically just want to know if it appears that the necessary routes are in place for the desired traffic to occur properly; kindly disregard any LOG targets or whatever that do not pertain directly to the traffic in question.


UPDATE 2:
Scenario ONE and TWO (DNAT situations) are now here: http://pastebin.com/m73a66944

UPDATE 3:
Here's SCENARIO THREE and FOUR, which are identical SNAT situations except that in the first scenario, the external interface is STATIC IP, so 'masquerading' for the LAN is done with SNAT also. The second listing on that page, scenario FOUR, is configured as a DYNAMIC IP for external interface, and so MASQUERADE is used for masquerading for the LAN.
http://pastebin.com/m1088762f

UPDATE 4:
Scenario FIVE: a SNAT situation involving SNATing to a range of IPs.
Posted here:http://pastebin.com/m3bd21884

My main concern with the SNAT and DNAT situations, is what if anything is required for the returning traffic to properly get back to its source. Particularly, in the case of the SNATs, when if ever (maybe never?) do we need to use explicit DNATs to help the SNATed traffic return?

Thanks win32sux and any other folks who care to comment, for your feedback.

Since this is about DNAT, you should show us the NAT table too.

Oops!
 

Sheesh! I KNEW something was missing ;)

The default is 'filter' only, of course.

After supper I will append the nat output.

Sorry for the late reply. School had limited my LQ participation for the last week to quick posts and janitorial activities. I've taken a look at the scenarios you posted, and here is my feedback. I do hope someone else provides feedback also, because the more eyes on your configuration, the better. Also, because as you will see, I don't comprehend all of it.

SCENARIO ONE

You seem to be missing a POSTROUTING rule for SNAT/MASQUERADE. Other than that, I would recommend you specify the protocol, port, and destination address right in the FORWARD rule for simplicity. This is probably required by the script you are using, though.


SCENARIO TWO

Same observations as with previous scenario. Additionally, I would recommend you use a single iptables rule for the ranges (by way of the iprange module), in order to avoid unnecessary packet traversals. Right now you are using one rule per IP. This is just a performance issue (and even so, only under heavy load), not a functionality one.


SCENARIO THREE AND FOUR

I'm not sure I'm following these scenarios. Why would you want to SNAT to an IP within the same LAN? From the WAN, the only IP visible will be that of the external interface. If the intention is to do SNAT/MASQUERADE for TCP port 80 from IP 10.10.10.50, it would go like:
SCENARIO FIVE

Again, I don't understand the idea behind changing the IP address to that of another box within the LAN. I can't provide any feedback on this, since I honestly can't grasp what you are trying to do. If scenarios three, four, and five deal with SNAT/MASQUERADE, why is there any need for PREROUTING in the first place?