If the changes are not visible with iptables -L
after a restart, it suggests that either:
The rules aren't being saved
- You suggest that they are, but at the same time say 'completed timestamps' - plural. This might imply that you have more than one copy of the rules in the same file, and only the first set is being applied.
The rules are being saved to the wrong file
- Your configuration may be setup to load a different file than the one you are saving to - ensure that the file being loaded matches the file you save to.
There is an error with the rules
- This is usually not an issue - iptables typically just ignores erroneous rules; and you are not writing them by hand (you are saving a presumably working ruleset).
iptables is not started on boot
You should be able to test your setup by just restarting iptables (as opposed to restarting the machine):
service iptables restart
Standard iptables disclaimer: just in case something goes wrong...
Question:
We are unsure if with IPTABLES SNAT and/or DNAT it is possible to pass the "real" source IP to the destination.
Answer:
Yes, it is possible, and here's how to do it if you're using CSF. Don't rely on CSF's redirect feature, i.e. having a line similar to the following in /etc/csf/csf.redirect
:
XXX.XXX.XXX.184|2222|10.0.0.100|22|tcp
Instead, put the following iptables
commands in /etc/csf/csfpost.sh
:
/sbin/iptables -I FORWARD -i vmbr0 -o vmbr10 -d 10.0.0.0/24 -j ACCEPT
/sbin/iptables -I FORWARD -i vmbr0 -o vmbr10 -d 10.0.0.0/24 -j LOCALINPUT
/sbin/iptables -t nat -A PREROUTING -i vmbr0 -p tcp -m tcp --dport 2222 -j DNAT --to-destination 10.0.0.100:22
Test:
$ ssh xxx.xxx.xxx.184 -p 2222 'netstat -tn'
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 72 10.0.0.100:22 xxx.xxx.xxx.199:55812 ESTABLISHED
Explanation:
/sbin/iptables --table nat --append PREROUTING --in-interface vmbr0 --protocol tcp --match tcp --dport 2222 --jump DNAT --to-destination 10.0.0.100:22
This line redirects TCP traffic coming in on the external interface on port 2222
to the internal address 10.0.0.100
on port 22
.
/sbin/iptables
the full iptables
executable is required.
--table nat
working on the nat (Network Address Translation) table.
--append PREROUTING
append this rule after all existing rules in the PREROUTING
chain.
--in-interface vmbr0
catch all traffic comin in on the vmbr0
interface.
--protocol tcp
catch only tcp traffic.
--match tcp
use the tcp module.
--dport 2222
catch only traffic directed to port 2222
.
--jump DNAT
perform a Destination Network Address Translation.
--to-destination 10.0.0.100:22
change the destination address to 10.0.0.100
and the destination port to 22
.
/sbin/iptables --insert FORWARD --in-interface vmbr0 --out-interface vmbr10 --destination 10.0.0.0/24 --jump LOCALINPUT
This line allows to not skip all of CSF's filtering just because we are redirecting.
/sbin/iptables
the full iptables
executable is required.
--insert FORWARD
insert this rule before existing rules in the FORWARD
chain. This is where redirected packets are going, as opposed e.g. to the INPUT
chain.
--in-interface vmbr0
match traffic coming in on the vmbr0
interface.
--out-interface vmbr10
match traffic going out from the vmbr0
interface as an effect of redirection.
--destination 10.0.0.0/24
match only traffic destined to (redirected to) the internal network.
--jump LOCALINPUT
go through the LOCALINPUT
chain. This is where CSF performs all the good filtering it is known for, keeping banned and blacklisted IPs from reaching the system. With this rule, we extend CSF's filtering to all hosts on the internal network (as opposed to just traffic destined for the host where CSF is running).
/sbin/iptables --insert FORWARD --in-interface vmbr0 --out-interface vmbr10 --destination 10.0.0.0/24 --jump ACCEPT
This line passes all remaining forwarded traffic to the internal hosts.
/sbin/iptables
the full iptables
executable is required.
--insert FORWARD
insert this rule before existing rules in the FORWARD
chain. This rule will be evaluated after all the filering is performed in the LOCALINPUT
chain.
--in-interface vmbr0
match traffic coming in on the vmbr0
interface.
--out-interface vmbr10
match traffic going out from the vmbr0
interface as an effect of redirection.
--destination 10.0.0.0/24
match only traffic destined to (redirected to) the internal network.
--jump ACCEPT
after CSF has performed all its filtering (in the LOCALINPUT
chain), we want remaining packets to be ACCEPT
ed.
Best Answer
If memory serves,
/etc/sysconfig/iptables-config
is the file that describes what options are used when the rhel iptables init script is brought up. It does not have explicit rules in it. the/etc/sysconfig/iptables
file on the other hand does have these rules in it. It is formatted per the output of theiptables-save
command; in fact, when you runservice iptables save
that's exactly how it creates the file.The short version to your other question is "whichever one is started last has priority".
For the purpose of clarity, I'm going to make a language abstraction in the context of this answer which is not "industry accepted" as follows:
Both the rhel-iptables and CSF scripts utilize the netfilter framework and commands to put firewall rules in kernel space. Both of them(*) reset the kernel rules tables to empty when started. Thus if CSF is started or restarted after rhel-iptables, its rules and configuration will take precedence. The reverse is true for rhel-iptables started or restarted after CSF; the CSF rules will be wiped clean and rhel-iptables rules take over.
As silly as that seems, this is probably OK, so long as you only work on the rule set you want running and you've verified that the one you want running (probably CSF, since you took the time to install it) runs last and you make sure you restart it if you accidentally restart the iptables service. You can check the order they are started by looking at
ls -1 /etc/rc.d/rc3.d
assuming your default runlevel is 3, which on rhel/centos without graphical, is usually the case (graphical is 5). If the number after the S is higher, it starts later.Why would you want to run both? Well, if your
/etc/sysconfig/iptables
rules are functional, it's pretty much guaranteed to come up before any networked services, which means firewall protection begins before the network is up and any services are exposed. Rules listed in that file are very resilient to system changes that CSF might respond poorly to, for example, your script interpreter or kernel version gets updated marginally, breaking the script syntax or module names or, more likely, you try to update CSF from its home website and it breaks itself. If CSF fails before flushing your rules out, your rhel-iptables rules are still in place, protecting your potentially vulnerable services as a fallback ruleset.If you wish to disable the rhel-iptables script, you can do so by running this command:
(*) flushing the kernel rules tables is the default for both scripts; I believe both can be configured to not do this and append only.