Iptables: POSTROUTING rule not matching with mark

iptablesnetworking

I have a host that sends packets to virtual machine say on 192.168.0.1/24 with either 192.168.0.11 or 192.168.0.12 as the destination IP. I'm trying to set up the virtual machine as a NAT. It routes the packets, changing the destination IP, depending on the original destination IP so I wasn't able to only use SNAT as the original IP was getting switched in PREROUTING. What I've been trying to use is the –set-mark flag to flag the packets with either 11 or 12 so the POSTROUTING rules will know what SNAT rule to use. Here are my rules:

iptables -t mangle -A PREROUTING --destination 192.168.0.11 -j MARK --set-mark 11
iptables -t nat -A PREROUTING -m mark --mark 11 -i eth0 -j DNAT --to 20.0.21.11
iptables -t nat -A POSTROUTING -m mark --mark 11 -o eth1 -j SNAT --to-source 20.0.1.1

and

iptables -t mangle -A PREROUTING --destination 192.168.0.12 -j MARK --set-mark 12
iptables -t nat -A PREROUTING -m mark --mark 12 -i eth0 -j DNAT --to 20.0.21.11
iptables -t nat -A POSTROUTING -m mark --mark 12 -o eth1 -j SNAT --to-source 20.0.1.2

My first two rules are being incremented if I watch iptables -t mangle/nat -nvL but the POSTROUTING rule never gets matched. Any ideas on why this would be?

I just thought of this while writing this. The first network is /24 subnet and I have then second network currently set up as a /8 subnet. Would this affect this in any way?

EDIT

To make things a little more clear.

This first step is the host sends either 192.168.0.11/24 or 192.168.0.12/24 from 192.168.0.1/24 to the virtual machine like so.

                     Destination IPs
     HOST           ================
===============  +--* 192.168.0.11 *--+  ======
* 192.168.0.1 *---  ================  ---* VM *
===============  +--* 192.168.0.12 *--+  ======
                    ================

I then want the virtual machine to forward these packets with both of the destination IP changed to 20.0.21.11/8. Then have the source IP change to either 20.0.21.1/8 or 20.0.21.2/8 depending on what the original destination IPs were. Like so.

            Source IPs w/ 20.0.21.11 as Destination IP 
           ==============
======  +--* 20.0.21.1 *--+   ============
* VM *---  ==============  ---* Test rig *
======  +--* 20.0.21.2 *--+   ============
           ==============

Also to be clear this is a NAT on a private network. There is no internet connection here. Just Host <--> VM <--> Test rig

EDIT 2

One more drawing to make it a little more clear.

                  Destination IPs     Source IPs
     HOST         ==============    ===============        Test rig
=============  +--*192.168.0.11*-+  |   20.0.21.1 *--+  ==============
*192.168.0.1*---  ============== +--* VM          |  +--* 20.0.21.11 *
=============  +--*192.168.0.12*-+  |   20.0.21.2 *--+  ==============
                  ==============    ===============

Best Answer

Your rules look right, check if you have bridges setup, these can make packet's in/out interfaces to be messed up. You can also add -j LOG rules to watch what gets matched in your logs.

Related Solutions

Linux – Forward HTTP Traffic to Another IP Address with iptables

There are three potential problems I see (contary to the other answer I don't see anything that would cause a "loop" even in the unedited version of your question).

IP forwarding must be enabled.
After being natted and placed back on the network the packet may fall victim to source address filtering as it looks very much like a spoofed packet.
Responses to packets that go through a NAT must go through the same NAT so the reverse translation can be performed. Otherwise the client will get a response with the wrong source IP/port which it is likely to drop (if it has not already been dropped by reverse path filtering).

You can work arround points 2 and 3 by using a SNAT or MASQURADE rule in addition to the DNAT but if you do that then you lose the original source IP of the traffic. That will make abuse control very difficult.

Another soloution to points 2 and 3 would be to set up a VPN between the two servers. Then use DNAT to forward traffic over the VPN and source IP based routing to bring the replies back to the NAT.

IPTABLES nat maintaining source IP address with CSF

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 ACCEPTed.

Best Answer

Related Solutions

Linux – Forward HTTP Traffic to Another IP Address with iptables

IPTABLES nat maintaining source IP address with CSF

Related Topic