IPtables localhost redirect

[Daniele Orlando]

Hello guys,

on my Debian 5 I'm trying to redirect
the TCP traffic generated by my machine
towards 127.0.0.1:5432 (PostgreSQL)
to the new destination 192.168.1.113:5432.

I have tried with iptables many rules, but no one seams good for the task.

Any idea?

[Boyd Stephen Smith Jr.]

Post by Daniele Orlando
on my Debian 5 I'm trying to redirect
the TCP traffic generated by my machine
towards 127.0.0.1:5432 (PostgreSQL)
to the new destination 192.168.1.113:5432.
I have tried with iptables many rules, but no one seams good for the task.
Any idea?

What have you tried? It seems like you'd need to change this in a PREROUTING
chain, probably in the mangle table.

Also, depending on the application it my be using the "unix socket" instead of
TCP/IP to connect to PostgreSQL. In that case, iptables would not be
involved.

[Daniele Orlando]

On Fri, Jul 9, 2010 at 08:34, Boyd Stephen Smith Jr.

What have you tried?  It seems like you'd need to change this in a PREROUTING
chain, probably in the mangle table.
Also, depending on the application it my be using the "unix socket" instead of
TCP/IP to connect to PostgreSQL.  In that case, iptables would not be
involved.

I have tried any configuration of PREROUTING, POSTROUTING, OUTPUT over
nat table.
I have not tried the mangle table, but I know it is used to change the
packet headers,
and I think that is not our case.

I have done many attempt with other protocols and tools (netcat is one of this),
and the problem is note the unix socket because in every case I forced the use
of the 127.0.0.1 host (especially with the the postgres client).

The problem seams to reside in how netfilter process packets on the lo
device and the localhost ip family.

This is a related post in italian:
http://lists.debian.org/debian-italian/2010/07/msg00148.html

And this is the workaround we came:
http://lists.debian.org/debian-italian/2010/07/msg00170.html

[Daniele Orlando]

Here's the trick,
# Trick the kernel to route localhost ip (127.0.0.1) in prerouting
rule, and continue routing out through the valid network interface
(not the loopback interface).
ifconfig eth0:0 127.0.0.1
# Setup NAT Table to redirect traffic
iptables -t nat -A PREROUTING -p tcp --dport 5432 -j DNAT --to
192.168.1.113:5432
I haven't tried it yet, let me know if it works.

Thanks, but it doesn't work.

Someone said me on a forum:
"""
You cannot redirect loopback traffic with iptables.
"""
I'm investigating this statement.

reference:
http://www.linuxquestions.org/questions/showthread.php?p=4027927

[Boyd Stephen Smith Jr.]

Post by Daniele Orlando
On Fri, Jul 9, 2010 at 08:34, Boyd Stephen Smith Jr.

Post by Boyd Stephen Smith Jr.
What have you tried? It seems like you'd need to change this in a
PREROUTING chain, probably in the mangle table.

I have tried any configuration of PREROUTING, POSTROUTING, OUTPUT over
nat table.
I have not tried the mangle table, but I know it is used to change the
packet headers,
and I think that is not our case.

One of the packet headers is the destination IP, which you are changing. The
mangle table might be appropriate here. Since you want that change to affect
which interface is used for sending the packet, it must occur in PREROUTING.

That said, I would not be surprised if there is special handling for 127/8 on
lo* devices.

[Charles Kroeger]

Post by Daniele Orlando
Any idea?

My idea would be for you to install a package called 'arno-iptables-firewall'
Then join their list discussions, much good information proffered there to
assist with this problem.

firewall-***@rocky.eld.leidenuniv.nl?subject=subscribe

[Javier Barroso]

Post by Daniele Orlando
Hello guys,
on my Debian 5 I'm trying to redirect
the TCP traffic generated by my machine
towards 127.0.0.1:5432 (PostgreSQL)
to the new destination 192.168.1.113:5432.
I have tried with iptables many rules, but no one seams good for the task.
Any idea?

Hi, If you have ssh access to 192.168.1.113, you can try ssh port
forwarding, with -L 5432:192.168.1.113:5432 option

Regards,

[Daniele Orlando]

Post by Javier Barroso
Hi, If you have ssh access to 192.168.1.113, you can try ssh port
forwarding, with -L 5432:192.168.1.113:5432 option
Regards,

Hi Javier,

thanks for the tip.
Your solution is one of the possible workarounds we came.
Another one (I'm using it) can be done with "socat":
socat TCP4-LISTEN:${local_port},fork,reuseaddr
TCP4:${remote_host}:${remote_port}

Credits to the guys of #Netfilter and #debian channels.

Thanks Javier.

References:
http://lists.debian.org/debian-italian/2010/07/msg00148.html
http://lists.debian.org/debian-italian/2010/07/msg00170.html
http://www.linuxquestions.org/questions/showthread.php?p=4027927
freenode.#Netfilter
#debian

[Mart Frauenlob]

Post by Daniele Orlando
Hello guys,
on my Debian 5 I'm trying to redirect
the TCP traffic generated by my machine
towards 127.0.0.1:5432 (PostgreSQL)
to the new destination 192.168.1.113:5432.
I have tried with iptables many rules, but no one seams good for the task.
Any idea?

This picture shows the netfilter traffic flow:
Loading Image...

Source address selection is done before the OUTPUT path.
Locally generated packets NEVER hit the PREROUTING chain in mangle or
nat table.
There is a routing decision after the mangle table OUTPUT chain.
But you cannot do address translation there (like in nat OUTPUT).
What you can do, is MARK packets in the mangle table, and refer to this
mark with iproute2 (ip rule add fwmark 0x1 lookup table custom_table) -
this is called "policy based routing".


So from looking at the picture and from the theory I know, theoretically
something like this could work:

echo "101 custom_table" >> /etc/iproute2/rt_tables

fill the table with appropriate routes:
ip route add table custom_table ...
...

mark in mangle table:
iptables -t mangle -A OUTPUT -d 127.0.0.1 -p tcp --dport 5432 -j MARK
--set-mark 0x1

dnat in nat table:
iptables -t nat -A OUTPUT -m mark --mark 0x1 -j DNAT --to-destination
192.168.1.113

snat in nat table:
iptables -t nat -A POSTROUTING -m mark --mark 0x1 -j SNAT --to-source
192.168.1.1?

add iproute rule:
ip rule add fwmark 0x1 lookup custom_table


I've done all this for testing and I did not succeed.
I also did:
echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter
not sure if that interacts.
I then put a trace rule:
iptables -t raw -A OUTPUT -d 127.0.0.1 -p tcp --dport 5432 -j TRACE

The resulting log always ended in the nat table's OUTPUT chain.
I don't know why acutally, from the picture (which is from a developer)
it should hit nat POSTROUTING.
I'm telling you this, so you could eventually try and maybe you have
more luck than me, or maybe the information is otherwise useful.
However maybe it's not possible, I can't tell for sure.
I would have done some ssh tunneling myself in the first place.
But I know there are people at the netfilter mailing list, who do know
for sure. It's in general the best place to ask netfilter related questions.

Best regards

Mart

[Daniele Orlando]

Post by Mart Frauenlob
http://jengelh.medozas.de/images/nf-packet-flow.png
Source address selection is done before the OUTPUT path.
Locally generated packets NEVER hit the PREROUTING chain in mangle or nat
table.
There is a routing decision after the mangle table OUTPUT chain.
But you cannot do address translation there (like in nat OUTPUT).
What you can do, is MARK packets in the mangle table, and refer to this mark
with iproute2 (ip rule add fwmark 0x1 lookup table custom_table) - this is
called "policy based routing".
So from looking at the picture and from the theory I know, theoretically
echo "101 custom_table" >> /etc/iproute2/rt_tables
ip route add table custom_table ...
...
iptables -t mangle -A OUTPUT -d 127.0.0.1 -p tcp --dport 5432 -j MARK
--set-mark 0x1
iptables -t nat -A OUTPUT -m mark --mark 0x1 -j DNAT --to-destination
192.168.1.113
iptables -t nat -A POSTROUTING -m mark --mark 0x1 -j SNAT --to-source
192.168.1.1?
ip rule add fwmark 0x1 lookup custom_table
I've done all this for testing and I did not succeed.
echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter
not sure if that interacts.
iptables -t raw -A OUTPUT -d 127.0.0.1 -p tcp --dport 5432 -j TRACE
The resulting log always ended in the nat table's OUTPUT chain.
I don't know why acutally, from the picture (which is from a developer) it
should hit nat POSTROUTING.
I'm telling you this, so you could eventually try and maybe you have more
luck than me, or maybe the information is otherwise useful.
However maybe it's not possible, I can't tell for sure.
I would have done some ssh tunneling myself in the first place.
But I know there are people at the netfilter mailing list, who do know for
sure. It's in general the best place to ask netfilter related questions.
Best regards
Mart

Thanks Mart,
your experiment will not be lost.

At the moment I have not a lot of time to spend extending your work,
but it is a good starting point for further enhancement.
As you are suggesting, I'll integrate it with the infos coming from the
netfilter mailing list and #Netfilter irc channel.

At the moment, the good news is that, together with the ssh,
netcat, and socat animals, we have a new friend:
xinetd

service postgresql
{
socket_type = stream
wait = no
user = root
redirect = 192.168.1.113 5432
bind = 127.0.0.1
}

Thanks again for the time spent answering me.

Daniele

p.s.:
The xinetd tip comes from SuperJediWombat! of linuxquestions.org.
http://www.linuxquestions.org/questions/linux-networking-3/iptables-redirect-127-0-0-1-to-192-168-1-113-a-818817/

[Daniele Orlando]

http://marc.info/?l=netfilter&m=127377479932181&w=2
http://marc.info/?l=netfilter&m=126950781622980&w=2

Loading Image...
Loading Image...

Nothing new, just some further details.